Red Hat Bugzilla – Bug 16577
xawtv doesn't accept any mouse input
Last modified: 2014-03-16 22:15:58 EDT
Quoting from bug 15702:
Almost -- it now does not crash in keyboard and/or mouse input, but I
cannot change values in the drop-down menus, nor can I remove the menus
with the mouse once they are displayed. It is as though it is not
accepting further mouse input.
Keyboard input has worked somewhat when tested -- using "r" to bring up the
recording window seemed to work consistantly, but using "r" again to close
the window worked maybe 10-20% of the time.
Bug 15702 was about xawtv crashing on 3.3 servers that is now indeed fixed.
But xawtv still doesn't work properly. As said above, it doesn't seem to
reaxt to input, keyboard input works most of the time mouse input works
almost never, try for example too change the volume from the right click
pop-up menu. This is always a no go.
I haven't tried this under a 40 server but I don't believe it is X server
related. The xawtv from 6.2 powertools works fine.
I've also managed to build a fine working xawtv from the RC1 srpm by
rebuilding it under 6.2. The bigest change by rebuilding it under 6.2 is
that it now uses Xaw3d.so.6 not .7. As said before it seems Xaw3d.so.7 is
I've also tried rebuilding the srpm under rc1 without Xaw3d (add
--disable-xaw3d to the configure flags) but that doesn't fix the problem.
So I believe this is an Xaw 7.0 bug, which has been inhereted by Xaw3d-7.0
and which bites xawtv. I'm however still filing it under xawtv, since that
is the way to reproduce it.
As said the srpm rebuild under 6.2 works fine.
It's not Xaw, it's *still* DGA.
Hmm, you mean that DGA causes mouse not clicking problems and stuff? And that
only with one app. To be clear I mean with only one of the apps runnign at that
moment, that is not how DGA works. I'll see if I can verify your assumption
though. Hold on.
Your right, compiling xawtv with --disable-xfree-ext fixes this, I'll look
further into it. I'll try to comeup with a workaround, if you think you can fix
this for real in time for RC2 lett me know and I won't waste anymore time on
Okay, ugly hack mode enabled. Qucik (and nasty) fix:
disable DGA when compiling xawtv itself, but not for v4l-conf which needs it to
detect the framebuffer address and width.
Dunno what DGA does in xawtv in the first place, but it seems to mess up xaw
I'll attach the patch I use to just disable DGA in xawtv.
The problem is that the DGA2 in XFree4 sets up input event
handling. For DGA1 apps, this is really bad....
Created attachment 2716 [details]
quick hack patch to fix the symptoms, not the problem.
Hmm. seems that patch isn't so great, it seems to also disable vm switching, so
full screen is gone. Don't know why though, still investigating.
Ah, there is a type in the original code using the DGA define for the vidmode
too by accident I guess this normally isn't a problem since they go hand in
Anyways, I'll attacha new patch fixing this typo. This works for me (tm)
Created attachment 2718 [details]
must fix, even though it is a hack. We'll get a better solution post-Winston.
Pbrown could you please repeat that last comment as an english sentence, I don't
Must fix yes, my quick hack does that, actually I've been testing it and it does
a pretty good job at it, and in a pretty clean way for a hack. This only fixes
xawtv however, not the generic problem.
But afaik the XFree86 people concider DGA1 dead, and wish they never invented
it. So its probably better to fix the few DGA1 using apps then to try to get
full DGA1 compatibility, I've got some quote's from XFree devleopers that that
aint going to happen in their lifetime.
This defect is considered MUST-FIX for Winston Gold release
please try xawtv-3.18. again. To disable DGA for using XFree86-3.3.6 Xserver
you must start xawtv with option -nodga.
It works fine with XFree86-3.3.6 Xserver on my local machine at home.
I have tested it.
With XFree86 4.01 works with or without DGA too.
Yes, -nodga helps, strange I tried this before and then it didn't help ?! maybe
I made a type and did --nodga, or something like that.
Reopening. This just papers over the problem.
My I make a suggestion (just tell me if it is stupid)
Since DGA1 apps seem to work fine if compiled against XFree-3.3 libs, and
specifically 3.3 libxf86dga.a I suggest including the DGA headers and libs from
3.3, and include those from 4.0 named libxf86dga2.a and the headers also
something endign in 2.h, since there are currently no apps using DGA2 afaik,
that should not hurt any apps, I dunno however if xawtv for exmaple compiled in
this fashion still works under XF-4.0, but that is supposed to work (it doesn't
for xmame, but maybe it does for simpeler apps like xawtv)
SDL links against DGA2. :(
OK, can you download:
put it in /usr/X11R6/lib, and then rebuild xawtv (which
works here for us with this) and xmame, and confirm
that they both work OK?
Will do so tomorrow morning CET (8 hours from now) I hope that is fast enough.
Yes, this works fine, actually it seems to have fixed xmame in DGA modes under
XF40 as well (as long as the card driver is ok, before that it didn't work at
all), good job.
Here's a small test report, card Matrox G200 8Mb.
App Xf30 XF40-XFdriver XF40-matrox binary driver
xawtv ok ok ok
xmame ok ok ok
xmame-DGA ok fail ok
Ehm I guess this bug can be closed then?
Don't forget to make sure xawtv is rebuild (and uped in revision), since the dga
lib is static.
Bill, the http://people.redhat.com/notting/dga/libXxf86dga.a is not the same
XFree86-4.0.1-0.44. Should i rebuilt it again ?
Not yet; X is still rebuilding.
rebuilt with new DGA.