Created attachment 50342 [details] [review] Completely disable HDMI detect in intel i915 driver Hello! I have Thinkpad X220 on Sandy Bridge, ArchLinux x64, libdrm 2.4.26, xf86-video-intel 2.15.0, mesa 7.11 and kernel 3.0.2. I have the following issue: When I start any of wine applications(even native, like winecfg) i915 driver begin to call intel_hdmi_detect -> drm_get_edid -> drm_do_probe_ddc_edid and mouse shutters very bad. In applications like winecfg drm_do_probe_ddc_edid is called while the program loads only, but if you run 3D game(I've tested on OSU!) drm_do_probe_ddc_edid would be called constantly and the game become unplayable. I've patched intel_hdmi_detect and intel_hdmi_get_modes in intel_hdmi.c just to return 0 and everything is fine now,but(of course) HDMI is not working now and the game performance is much better but still not playable. I thought it's my OS only, installed ubuntu 11.04 x64 on USB flash - still the same, installed ubuntu 11.04 x86 - much better, but mouse still shutters sometimes. The game is playable on ubuntu, but that might be new version issue. Here is a bugreport on winehq.org http://bugs.winehq.org/show_bug.cgi?id=28107 Waiting for proper fix.
Here is wine in ArchLinux x64 with i915 patch (wine version 1.3.26) http://www.youtube.com/watch?v=8KHYjI8Se00 Here is in ubuntu 10.04 x86 without patch (wine version 1.3.15) http://www.youtube.com/watch?v=5-n9Qt5TrHk In ArchLinux osu is choppy and freezes every second with patch, and without patch is very choppy and freezed almost all the time. In Ubuntu you can see mouse freezes but osu is very playable. I think that's because Ubuntu is x86. I've downgraded wine down to 1.3.15 in ArchLinux but everything is still the same. On ArchLinux libdrm 2.4.26, xf86-video-intel 2.15.0, mesa 7.11 and kernel 3.0.2 On Ubuntu xserver-xorg-video-intel 2.14.0, libdrm 2.4.23, mesa 7.10.2, kernel 2.6.38-8.
This is very annoying bug, I hope somebody'll fix it.
Still here.
The primary cause is that wine should not be probing the outputs on every vblank (or at whatever high frequency). There is small room for improvement on the secondary issues (length of time it takes to detect outputs and lock contention) but probing will always take a finite amount of time during which X won't be processing other requests.
By the way I found a workaround Section "Monitor" Identifier "HDMI1" Option "Ignore" "True" EndSection Section "Monitor" Identifier "HDMI2" Option "Ignore" "True" EndSection Section "Monitor" Identifier "HDMI3" Option "Ignore" "True" EndSection
Patch fixing this should appear in drm-next for the next merge window, so it should enter 3.4 kernel.
Thanks! I will try as soon, as I can.
In airlied/drm-next: commit 9292f37e1f5c79400254dca46f83313488093825 Author: Eugeni Dodonov <eugeni.dodonov@intel.com> Date: Thu Jan 5 09:34:28 2012 -0200 drm: give up on edid retries when i2c bus is not responding This allows to avoid talking to a non-responding bus repeatedly until we finally timeout after 15 attempts. We can do this by catching the -ENXIO error, provided by i2c_algo_bit:bit_doAddress call. Within the bit_doAddress we already try 3 times to get the edid data, so if the routine tells us that bus is not responding, it is mostly pointless to keep re-trying those attempts over and over again until we reach final number of retries. This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059 and improve overall edid detection timing by 10-30% in most cases, and by a much larger margin in case of phantom outputs (up to 30x in one worst case). Timing results for i915-powered machines for 'time xrandr' command: Machine 1: from 0.840s to 0.290s Machine 2: from 0.315s to 0.280s Machine 3: from +/- 4s to 0.184s Timing results for HD5770 with 'time xrandr' command: Machine 4: from 3.210s to 1.060s Reviewed-by: Chris Wilson <chris@hchris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Tested-by: Sean Finney <seanius@seanius.net> Tested-by: Soren Hansen <soren@linux2go.dk> Tested-by: Hernando Torque <sirius@sonnenkinder.org> Tested-by: Mike Lothian <mike@fireburn.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059 Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Please test and report if this does not resolve the problem for you. In some instances we may need to teach the application to use RRGetScreenResourcesCurrent rather than RRGetScreenResources.
The faster edid handling commit is now available in 3.4-rc1, so closing. If the issue still happens, feel free to reopen so we could investigate it further.
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.