System Environment: -------------------------- Arch: x86-64 Platform: G45 Libdrm: (master)67e4172394a88d4922fb8d9c7c3d96ce7e02c5a6 Mesa: (mesa_7_6_branch)796c96de808790826d9c9077d159390ebee62888 Xserver: (server-1.6-branch)3044711412d0a08ba65a491bd2441c0c8980f5e2 Xf86_video_intel:(master)efbcf29dd1a1ca058b7a2a93f0685102c06c9369 Kernel: (master)74fca6a42863ffacaf7ba6f1936a9f228950f657 Bug detailed description: ------------------------- Start X, mouse and keyboard works well. Then run ut2004, while entering the game option interface, mouse does not work, some keyboard keys also do not work("Enter" and "Esc" key work fine), so we can not choice the game type to play. After exiting the game, mouse and keyboard works well on X. This issue also happens on 945GME and 945GM. Reproduce steps: ---------------- 1. xinit& 2. ./ut2004
Created attachment 29406 [details] Xorg log
Created attachment 29407 [details] Dmesg file
I think this is the same problem I reported in bug 23861
Bisect and find following commit is first bad commit: commit fe7693c94a396b9d17bb66a000178750a432ce3a Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Wed Sep 2 22:57:33 2009 +0800 Make DGA optional As DGA is optional in xserver, we should check this too instead of always trying to init DGA. Found when update xserver to 6fffcd5825454a7fe58ffbcfb219f007cf38e731, but not update xf86dgaproto, which caused X fails to start. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Does unreal require DGA?
*** Bug 23861 has been marked as a duplicate of this bug. ***
ok, so disable DGA in KMS seems relate to this issue. Have you tried the environ value SDL_VIDEO_X11_DGAMOUSE=0? I'm not quite sure how to enable DGA in KMS case, as we'll map front buffer on the fly when needs to access it, what would also need to update DGA mem address. I'll ping keithp on how this should be resolved. Note that even in KMS we exposed DGA support before, that actually doesn't work properly, maybe unreal just has some check on DGA proto existence, then wrongly work in somehow when the probe failed?...
It's not just UT2004, a lot of other games broke with this change. This should probably be a blocker for the 2.9.0 release?
Yes, this is the biggest blocker for 2.9. I see Keithp is working on a related xserver fix. Keith, what's the estimated fix date?
the device-independent DGA code in xf86DiDGA.c doesn't accept drivers that cannot expose the root pixmap as an offset in /dev/mem. If we initialize this with a bogus offset, then the server will happily mmap it and potentially corrupt the system. My plan is to simply eliminate all direct rendering from DGA in this X server code, but until then, I'm not sure what we can do in the driver -- initializing DGA leaves us open to potentially catastrophic bugs.
Fixed by Keithp both in xserver and xf86-video-intel. xserver commit: commit 0b7c6c728c2e2d8433a188315cc591308a89cd85 Author: Keith Packard <keithp@keithp.com> Date: Fri Sep 18 21:12:17 2009 -0700 xfree86/modes: Remove all framebuffer support from DGA This removes all rendering and mapping code from xf86DiDGA, leaving just mode setting and raw input device access. The mapping code didn't have the offset within /dev/mem for the frame buffer and the pixmap support assumed that the framebuffer was never reallocated. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> xf86-video-intel commit: commit 5e80297d088e8cdbf66d765f7d252dab66c8df86 Author: Keith Packard <keithp@keithp.com> Date: Fri Sep 18 21:05:23 2009 -0700 Remove DGA support from the driver. ....
Does server 1.6 needs the fix?
Works well with these commits on server master branch. Verified.
Reopening as server-1.6 is not fixed yet.
Keith can you commit the fix to server-1.6-branch, and better make 1.6.4 release before end of this week?
I've pushed the X server patch to server-1.6-branch in preparation for 1.6.4
Keith, thanks for the quick action. So I'm closing this bug. Xun to verify with server-1.6-branch
Verified with server-1.6-branch.
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.