Bug 9474 - input does not work for games (quake4/ut2004) when unredirect_fullscreen_windows is set
Summary: input does not work for games (quake4/ut2004) when unredirect_fullscreen_wind...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: App/compiz (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Kristian Lyngstøl
QA Contact: Xorg Project Team
URL: http://lists.freedesktop.org/archives...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-29 04:03 UTC by drago01
Modified: 2009-02-03 12:38 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description drago01 2006-12-29 04:03:34 UTC
When I enable the unredirect_fullscreen_windows option I am unable to give an
input to fullscreen games like ut2004 and quake4.
I tested with and without cow. (same problem)
xorg version: 7.1.1
nvidia drivers: 1.0-9746 (7800 GTX)
FC6 x86_64
Comment 1 drago01 2006-12-29 06:56:20 UTC
keyboard input works fine but mouse does not work.
tested with ppracer and nexuiz same issue.
Comment 2 David Reveman 2006-12-29 11:29:09 UTC
Tried ppracer but I couldn't reproduce this issue. I'm using Xgl, though.
Comment 3 drago01 2006-12-30 01:51:10 UTC
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.
Comment 4 Douglas Bollinger 2007-01-08 14:17:35 UTC
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.
Comment 5 Douglas Bollinger 2007-01-08 14:41:54 UTC
Oh, ppracer works fine.
Comment 6 drago01 2007-01-09 11:30:30 UTC
(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)
Comment 7 Douglas Bollinger 2007-01-09 15:39:18 UTC
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.
Comment 8 drago01 2007-01-10 22:01:41 UTC
(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?
Comment 9 Douglas Bollinger 2007-01-11 16:56:31 UTC
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. :(((
Comment 10 drago01 2007-01-18 11:56:35 UTC
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?
Comment 11 Douglas Bollinger 2007-01-28 09:32:23 UTC
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.
Comment 12 drago01 2007-02-04 01:12:52 UTC
if you can please try xorg-7.2, but dunno if anything related is fixed there.
Comment 13 Travis Watkins 2007-02-18 03:58:23 UTC
xmoto triggers this bug with xorg 7.2 and the 9742 nvidia drivers
Comment 14 Daniel Stone 2007-02-27 01:35:21 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 15 drago01 2007-03-03 01:36:21 UTC
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?
Comment 16 drago01 2007-03-04 06:00:02 UTC
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.
Comment 17 drago01 2007-03-04 06:00:12 UTC
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.
Comment 18 drago01 2007-04-23 09:45:22 UTC
> doom3 DamageEvents false + no unredirect => 81fps

this should be

doom3 DamageEvents true + no unredirect => 81fps (sorry for the typo)

Comment 19 James Jones 2007-04-23 15:42:05 UTC
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)?
Comment 20 drago01 2007-04-24 12:20:52 UTC
(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.

Comment 21 drago01 2007-04-27 09:48:17 UTC
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?
Comment 22 James Jones 2007-04-27 11:04:35 UTC
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 :-)
Comment 23 drago01 2007-04-28 00:34:21 UTC
(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.
Comment 24 Kristian Lyngstøl 2009-02-03 12:34:26 UTC
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...
Comment 25 drago01 2009-02-03 12:38:58 UTC
(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.