Summary: | input does not work for games (quake4/ut2004) when unredirect_fullscreen_windows is set | ||
---|---|---|---|
Product: | xorg | Reporter: | drago01 |
Component: | App/compiz | Assignee: | Kristian Lyngstøl <kristian> |
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
Severity: | normal | ||
Priority: | high | CC: | alleykat, jajones, kristian |
Version: | git | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
URL: | http://lists.freedesktop.org/archives/compiz/2006-December/001092.html | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
drago01
2006-12-29 04:03:34 UTC
keyboard input works fine but mouse does not work. tested with ppracer and nexuiz same issue. Tried ppracer but I couldn't reproduce this issue. I'm using Xgl, though. can you try without XGL? last time I tested with Xgl (was before FC6 was released) it was working. so it might be a AIGLX issue. I would like to expand on this as I'm having a similar problem. I'm using a Gentoo system with Xorg 7.1, Nvidia drivers 9742. I'm NOT using a Xgl server. Like the original poster, with unredirect_fullscreen_windows set SOME games won't accept input. The game itself is working fine, I just can't control it. CTRL-ALT-Backspace is required (and still works) to reset the server. Strangely enough, some games accept input and work fine if started from the console, but won't work if started from the panel. Enemy Territory: Works fine when started from the console and the panel. Doom3: No input when started from either the console or the panel. Quake4: Works fine when started from the console but receives no input when started from the panel. Darwinia: Receives keyboard but not mouse input when started from either the console or the panel. Tribal Trouble: No input when started from either the console or the panel. Also disables xserver reset CTRL-ALT-Backspace. :( All games work perfectly with Metacity. All games receive input when when unredirect_fullscreen_windows is not set, but they perform badly. Oh, ppracer works fine. (In reply to comment #5) > Oh, ppracer works fine. using the keyboard its ok but can you use the mouse? (in the menu to select things) Yes. I can use the mouse and keyboard with ppracer in everything. No problems at all with that program. UT2004: No input when started from either the console or the panel. Unfortunately, I can't seem to find a free game that tickles this bug. (In reply to comment #7) > Yes. I can use the mouse and keyboard with ppracer in everything. No problems > at all with that program. > ok weird... > UT2004: No input when started from either the console or the panel. > > Unfortunately, I can't seem to find a free game that tickles this bug. have you tryed nexuiz? David: any idea whats happening? Nexuiz: Works fine when started from the console and the panel. Here's a weird one, though. Nexuiz worked fine, but one time when I quit the game I lost the keyboard input in Gnome! The mouse worked fine, but I couldn't type anything in any of the windows. I had to open a virtual console (CTRL-ALT-F2) to kill and restart compiz to get the keyboard back. Unfortunately, I can't repeat this problem. :((( I tyred to fix this but I have no idea what could be causing it. I tryed to call moveInputFocusToWindow(w) after the call to XCompositeUnredirectWindow but the only thing it did was that the cow was shown and I had to press a button to get to the app. (but input was still broken). its seems not to be a focus problem (else keyboard would'nt work) so what else could be causing it? XSetInputFocus did not help too... could this be a xorg bug? Douglas: which xorg version are you using? Sorry for the delay... I thought this bug was forgotten about. I'm using Xorg 7.1, the default, stable version in Gentoo. It's somewhat annoying that I couldn't find a open source game to trigger this bug. Between this bug and another bug where the desktop is corrupted (Nvidia?) when returning from a fullscreen game is enough to keep me in Metacity for now. While it's not as much fun, at least everything works perfectly in Metacity. If you think it would help, I could _maybe_ try Xorg 7.2 as it's in unstable now. I'll see how much trouble that would cause me to upgrade. if you can please try xorg-7.2, but dunno if anything related is fixed there. xmoto triggers this bug with xorg 7.2 and the 9742 nvidia drivers Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future. I finally found the cause of this problem: The nvidia drivers has this to improve the speed of gl apps when running with composite: ----- Option "DamageEvents" "boolean" Use OS-level events to efficiently notify X when a client has performed direct rendering to a window that needs to be composited. This will significantly improve performance and interactivity when using GLX applications with a composite manager running. It will also affect applications using GLX when rotation is enabled. This option is currently incompatible with SLI and MultiGPU modes and will be disabled if either are used. Enabled by default. ----- When I set it to false unredirect_fullscreen_windows works !! But then non fullscreen gl apps are much slower. Is it possible to make unredirect_fullscreen_windows to work with this option enabled? it seems that on nvidia hardware the unredirect_fullscreen is not needed. I did some benchmarks: )glxgears default + no unredirect => ~8000fps glxgears DamageEvents false + no unredirect => ~2200fps glxgears on metacity => ~ 15000fps glxgears is not really a benchmark so I tested doom3: doom3 default + no unredirect => 80.4fps doom3 DamageEvents false + no unredirect => 56fps doom3 DamageEvents false + no unredirect => 81fps doom3 on metacity => 80.6fps so 1,3 and 4 are almost the same perfomance. that means that nvidia managed to eliminate the overhead almost completly. glxgears seems to notice the overhead because it renders to many frames. the test where performed on a dual core opteron box with a 7800GTX. it seems that on nvidia hardware the unredirect_fullscreen is not needed. I did some benchmarks: )glxgears default + no unredirect => ~8000fps glxgears DamageEvents false + no unredirect => ~2200fps glxgears on metacity => ~ 15000fps glxgears is not really a benchmark so I tested doom3: doom3 default + no unredirect => 80.4fps doom3 DamageEvents false + no unredirect => 56fps doom3 DamageEvents false + no unredirect => 81fps doom3 on metacity => 80.6fps so 1,3 and 4 are almost the same perfomance. that means that nvidia managed to eliminate the overhead almost completly. glxgears seems to notice the overhead because it renders to many frames. the test where performed on a dual core opteron box with a 7800GTX.
> doom3 DamageEvents false + no unredirect => 81fps
this should be
doom3 DamageEvents true + no unredirect => 81fps (sorry for the typo)
Just noticed this bug in a post to the compiz list. drago01: Are you certain this only reproduces when DamageEvents are enabled? For me the, results looks like this: With Unreal Tournament 2004, with or without DamageEvents enabled, mouse input doesn't work. Keyboard input is fine. With quake 4/doom 3, mouse and keyboard input work fine. This is all with unredirect_fullscreen_windows enabled, using the composite overlay window and compiz version 3.6. I verified the unredirect_fullscreen windows path was being used with gdb. I tried testing with compiz 0.5, but found it has a few bugs in the unredirect_fullscreen_windows path. In the past, I have found this issue to be intermittent, and sometimes restaring X caused it to go away or reappear. Could you check a little more thoroughly whether DamageEvents are really causing this, and if they are, generate and attach an nvidia bug report to this bug (run nvidia-bug-report.sh)? (In reply to comment #19) > Just noticed this bug in a post to the compiz list. > > drago01: Are you certain this only reproduces when DamageEvents are enabled? for now yes, last time when I tryed this it was like this: DamageEvents off-> unredirect works DamageEvents on -> no input when using unredirect > For me the, results looks like this: > > With Unreal Tournament 2004, with or without DamageEvents enabled, mouse input > doesn't work. Keyboard input is fine. > > With quake 4/doom 3, mouse and keyboard input work fine. > ok thats different from what I saw... > This is all with unredirect_fullscreen_windows enabled, using the composite > overlay window and compiz version 3.6. I verified the unredirect_fullscreen > windows path was being used with gdb. I tried testing with compiz 0.5, but > found it has a few bugs in the unredirect_fullscreen_windows path. > > In the past, I have found this issue to be intermittent, and sometimes > restaring X caused it to go away or reappear. Could you check a little more > thoroughly whether DamageEvents are really causing this, and if they are, > generate and attach an nvidia bug report to this bug (run > nvidia-bug-report.sh)? ok I will do more testing this weekend with compit head+ your unredirect fix patch (if its not in head until then) and the new beta drivers. I will report the results here, thx for helping with this issue. James, I tested again with the lastest drivers and it seems that you are correct, this is not directly connected to the DamageEvents option. do you still need the bugreport logs? Thanks for retesting. That's interesting that changing drivers affected the bug in your case, but I'm fairly certain this is not an NVIDIA bug, so I'm going to unassign Andy Ritger. I may look at this further since the bug bothers me as well, but it will have to be in my free time. And no, I don't need the logs now :-) (In reply to comment #22) > Thanks for retesting. That's interesting that changing drivers affected the > bug in your case, but I'm fairly certain this is not an NVIDIA bug, so I'm > going to unassign Andy Ritger. I may look at this further since the bug > bothers me as well, but it will have to be in my free time. And no, I don't > need the logs now :-) > ok, but I didn't only change drivers but also the compiz version. Is this still an issue? I admit not reading the entire log as I'm triaging 122 bugs from 2006 to 2009, but I can't seem to reproduce the gist of it... If nobody confirms this bug within a reasonable time, I'm going to close it off... (In reply to comment #24) > Is this still an issue? I admit not reading the entire log as I'm triaging 122 > bugs from 2006 to 2009, but I can't seem to reproduce the gist of it... > > If nobody confirms this bug within a reasonable time, I'm going to close it > off... > No, it seems to work fine with 0.7.8 and current nvidia drivers. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.