Hello, I'd like to assist in fixing an issue that is quite nagging concerning the i915 driver. I wasn't sure whether to classify this as a bug, but it's something worth considering. Let me explain. When I first used the i915 driver on my Lenovo X220 laptop, I noticed that every time I run xrandr, or when any X client tries to query the display modes, the X server hangs for a second or so. Using systemtap, I was able to track the hang to the Intel DRM driver, around the area in which it talks over i2C in order to query the modes from display controller. More specifically, drm_mode_getconnector() is calling i915's ->fill_modes() and it waits there for awhile. Now you might ask why it is annoying. Well, for instance, say you are debugging an SDL application. Those type of applications usually result in the GET_CONTROLLERS ioctl() being called by the X server, and re-running the same application in a development cycle makes this issue quite noticeable. To make my work bearable, I came as far as adding a sysfs kernel module parameter to DRM for the purpose of force-disabling the condition of the call to fill_mode(). Now imagine, I do 'echo 1 > /sys/module/drm/parameters/dont_fill_modes', and voila, xrandr works like charm, SDL apps don't get stuck on init. Good until I disconnect my laptop from the display port, or until it suspends. YUCK. Of course we don't want this approach, it's an ugly hack. I am hoping that DRM/Intel developers might be able to come with a fix. I'd be happy to leverage my kernel hacking skills for this. My setup is a Linux 3.2.11 vanilla, xserver-xorg 1:7.6+4ubuntu3.2, x86_64 on Lenovo X220, PCI_ID 8086:0126 (rev 09). Problem is 100% reproducible, and happens whether I'm directly connected without a docking station via DisplayPort, or whether I'm using a docking station with a display connected to it by DVI. Thanks. - Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120416/4a27f692/attachment.htm>
