On Mon, Apr 16, 2012 at 7:37 PM, Adam Jackson <ajax at redhat.com> wrote: > On Mon, 2012-04-16 at 18:54 +0300, Dan Aloni wrote: > > > Okay, with 3.4-rc3 I can confirm that it works much better. For the > > xrandr test case, I've timed each ioctl to about 60 milli-secs with 9 > > calls spanning over half a second. Any further suggestions? Isn't it > > possible to tell that nothing is connected and then not try to probe > > those ports at all? > > There could be such detection, but there is not. We have hotplug > interrupts, but we don't trust them to actually tell us whether > something is connected. (We don't trust them because we think they're > unreliable, and then they remain unreliable because we don't fix the > implementation to be trustworthy.) We just turn the interrupts into > uevents and then rely on userspace to compensate for the kernel not > doing a good enough job. > Seems reasonable. Thought the hardware interfaces were better, though. > > Since we don't do that, the only way to tell that nothing is connected > is to probe. We could make probing a bit faster by caching previous > EDID and memcmp'ing the first 16 bytes (which include the > vendor/model/serial tuple, which should be unique enough) instead of > retrying the whole EDID fetch unconditionally. > That would only accelerate the query on the ports that are connected, no? A full probe on an unconnected port would still take time I assume. > > But, as Chris said: You probably want to fix SDL to use > GetScreenResourcesCurrent since GetScreenResources is really only meant > for the session's configuration manager; and if you're running xrandr by > hand, use xrandr --current. > > About SDL - I don't see any call to GetScreenResources in SDL's code. Could it be another function causing those probes? BTW, gnome-display-properties also seems to be causing the probe, do you think it needs to be modified as well? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120416/e401c151/attachment-0001.htm>
