Bug 1155784 - Xawtv does not scale video since kernel 3.16.x introduced
Summary: Xawtv does not scale video since kernel 3.16.x introduced
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xawtv
Version: 21
Hardware: i686
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Dmitry Butskoy
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1173952 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-22 19:44 UTC by Miroslav Jurkas
Modified: 2015-01-13 00:01 UTC (History)
8 users (show)

Fixed In Version: xawtv-3.103-5.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-13 00:00:30 UTC
Type: Bug


Attachments (Terms of Use)
fix (1.54 KB, patch)
2014-12-27 19:09 UTC, Stas Sergeev
no flags Details | Diff
Spec file to build updated xawtv rpm (14.79 KB, text/plain)
2015-01-04 12:58 UTC, Miroslav Jurkas
no flags Details

Description Miroslav Jurkas 2014-10-22 19:44:24 UTC
Description of problem:
Xawtv when started displays the window with last station tunned. When I try anything from:
 - change the station
 - scale the window
 - or try to enter full screen
Video stops to show no be reproduced no matter which opoption I try to start xawtv with. Sound is reproduced at all times.
Used to work and it still does with kernel-3.15.10-201.fc20.i686. I suppose some change in kernel is the root cause.

Version-Release number of selected component (if applicable):
xawtv-3.103-2.fc20.i686
kernel-3.16.6-200.fc20.i686

How reproducible:
Install latest Fedora and upgrade all modules to latest version...

Steps to Reproduce:
1. Start xawtv (video should be displayed)
2. Change the windows size (drag lower right corner)

Actual results:
Video is no longer shown. Picture either frozen or black

Expected results:
Xawtv reproduces sound & video, all controls work as expected.


Additional info:
I have an antient "Terratec Cinergy 600 TV", a "saa7134" based card.

When I start xawtv:

[me@myoldbox ~]$ xawtv
This is xawtv-3.103, running on Linux/i686 (3.16.6-200.fc20.i686+PAE)
xinerama 0: 1920x1080+0+0
vid-open-auto: using analog TV device /dev/video0
WARNING: No DGA direct video mode for this display.
WARNING: keeping fbuf pitch at: 7680, as no base addr was detected
WARNING: couldn't find framebuffer base address, try manual
         configuration ("v4l-conf -a <addr>")
v4l2: WARNING: framebuffer base address mismatch
v4l2: me=(nil) v4l=(nil)
Alsa devices: cap: hw:2,0 (/dev/video0), out: default
Warning: Missing charsets in String to FontSet conversion
Warning: Missing charsets in String to FontSet conversion
invalid value for fullscreen: true
open /dev/mixer: No such file or directory

after I resize the window:

ioctl: VIDIOC_REQBUFS(count=2;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
ioctl: VIDIOC_REQBUFS(count=0;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
v4l2: read: Invalid argument
ioctl: VIDIOC_REQBUFS(count=2;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
ioctl: VIDIOC_REQBUFS(count=0;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
v4l2: read: Invalid argument
ioctl: VIDIOC_REQBUFS(count=2;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
ioctl: VIDIOC_REQBUFS(count=0;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
v4l2: read: Invalid argument
ioctl: VIDIOC_REQBUFS(count=2;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
ioctl: VIDIOC_REQBUFS(count=0;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
v4l2: read: Invalid argument
ioctl: VIDIOC_REQBUFS(count=2;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
ioctl: VIDIOC_REQBUFS(count=0;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
v4l2: read: Invalid argument
ioctl: VIDIOC_REQBUFS(count=2;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
ioctl: VIDIOC_REQBUFS(count=0;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
v4l2: read: Invalid argument
ioctl: VIDIOC_REQBUFS(count=2;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
ioctl: VIDIOC_REQBUFS(count=0;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
v4l2: read: Invalid argument
ioctl: VIDIOC_REQBUFS(count=2;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy
ioctl: VIDIOC_QBUF(index=0;type=VIDEO_CAPTURE;bytesused=221184;flags=0x2003 [MAPPED,QUEUED,(null)];field=BOTTOM;;timecode.type=0;timecode.flags=0;timecode.frames=0;timecode.seconds=0;timecode.minutes=0;timecode.hours=0;timecode.userbits="";sequence=0;memory=MMAP): Device or resource busy
v4l2: oops: select timeout
ioctl: VIDIOC_REQBUFS(count=0;type=VIDEO_CAPTURE;memory=MMAP): Device or resource busy

Comment 1 Dmitry Butskoy 2014-10-22 23:11:14 UTC
AFAIK new kernel should not degrade the work of previously working applications...
Reassign to kernel.

Comment 2 Stas Sergeev 2014-12-20 12:16:32 UTC
Same problem here.
But I am not sure its a kernel bug.
At least, tvtime still works correctly.

Comment 3 Eydee 2014-12-21 13:31:56 UTC
It must be a kernel bug. If you change nothing else in the system, only downgrade the kernel, xawtv starts working fine. Tvtime is a different animal, it doesn't use V4L as far as I know. And it's almost impossible to get sound working with it, so it's a very bad alternative.

Comment 4 Stas Sergeev 2014-12-21 14:36:27 UTC
Yes, I am not suggesting tvtime as alternative,
exactly because it doesn't support sound. But its
a good test-case, and I believe it uses v4l2 too.
The more interesting thing is that, for instance,
while xawtv freezes video upon channel switch or
any othre operation, it is still possible to
restart xawtv and watch the channel to which you
switched before restart. This means, even if there
is a kernel bug, the work-around on xawtv side is
possible, because even the simple restart gets it
back to work.

Comment 5 Stas Sergeev 2014-12-27 19:09:09 UTC
Created attachment 973586 [details]
fix

This is a xawtv bug, and here's the fix.

Comment 6 Dmitry Butskoy 2014-12-27 23:25:24 UTC
*** Bug 1173952 has been marked as a duplicate of this bug. ***

Comment 7 Miroslav Jurkas 2015-01-04 12:58:02 UTC
Created attachment 975956 [details]
Spec file to build updated xawtv rpm

I can confirm that fix provided by Stas works well on my Fedora 20 running kernel-3.17.7-200.fc20.i686. Unfortunately I do not have anymore several different fedora versions running with appropriate hardware, to test it broadly.

I have integrated fix into xawtv package based on xawtv-3.103-2.fc20.src.rpm.
Only added patch 0001-v4l2_getimage-prefer-CAP_STREAMING-over-CAP_READWRIT.patch abd rised version to 3.103-2.1. I'll attach spec file, in case somebody has access and time to integrate it to fedora repository, probably rising version to 3.103-3.

Comment 8 Fedora Update System 2015-01-04 18:10:22 UTC
xawtv-3.103-5.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/xawtv-3.103-5.fc21

Comment 9 Fedora Update System 2015-01-04 18:11:18 UTC
xawtv-3.103-5.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/xawtv-3.103-5.fc20

Comment 10 Fedora Update System 2015-01-05 07:38:43 UTC
Package xawtv-3.103-5.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xawtv-3.103-5.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-0149/xawtv-3.103-5.fc20
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2015-01-13 00:00:30 UTC
xawtv-3.103-5.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Fedora Update System 2015-01-13 00:01:58 UTC
xawtv-3.103-5.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.