<div dir="ltr"><div class="gmail_quote">On Mon, Apr 16, 2012 at 7:37 PM, Adam Jackson <span dir="ltr"><<a href="mailto:ajax@redhat.com">ajax@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, 2012-04-16 at 18:54 +0300, Dan Aloni wrote:<br>
<br>
> Okay, with 3.4-rc3 I can confirm that it works much better. For the<br>
> xrandr test case, I've timed each ioctl to about 60 milli-secs with 9<br>
> calls spanning over half a second. Any further suggestions? Isn't it<br>
> possible to tell that nothing is connected and then not try to probe<br>
> those ports at all?<br>
<br>
</div>There could be such detection, but there is not.  We have hotplug<br>
interrupts, but we don't trust them to actually tell us whether<br>
something is connected.  (We don't trust them because we think they're<br>
unreliable, and then they remain unreliable because we don't fix the<br>
implementation to be trustworthy.)  We just turn the interrupts into<br>
uevents and then rely on userspace to compensate for the kernel not<br>
doing a good enough job.<br></blockquote><div><br></div><div>Seems reasonable. Thought the hardware interfaces were better, though.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Since we don't do that, the only way to tell that nothing is connected<br>
is to probe.  We could make probing a bit faster by caching previous<br>
EDID and memcmp'ing the first 16 bytes (which include the<br>
vendor/model/serial tuple, which should be unique enough) instead of<br>
retrying the whole EDID fetch unconditionally.<br></blockquote><div><br></div><div>That would only accelerate the query on the ports that are connected, no? </div><div>A full probe on an unconnected port would still take time I assume.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But, as Chris said: You probably want to fix SDL to use<br>
GetScreenResourcesCurrent since GetScreenResources is really only meant<br>
for the session's configuration manager; and if you're running xrandr by<br>
hand, use xrandr --current.<br><br></blockquote><div> </div></div><div>About SDL - I don't see any call to GetScreenResources in SDL's code.</div><div>Could it be another function causing those probes?</div><div>
<br></div><div>BTW, gnome-display-properties also seems to be causing the probe, do </div><div>you think it needs to be modified as well?<div><br></div><div></div></div></div>