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 buggy. 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 this.
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 hand. Anyways, I'll attacha new patch fixing this typo. This works for me (tm)
Created attachment 2718 [details] better hack
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 understand. 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: http://people.redhat.com/notting/dga/libXxf86dga.a 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? p.s. 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 from XFree86-4.0.1-0.44. Should i rebuilt it again ?
Not yet; X is still rebuilding.
rebuilt with new DGA.