On Thu, Feb 23, 2012 at 11:52 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
>
> i2c retries if sees an EGAIN, drm_do_probe_ddc_edid retries until it
> gets a result and *then* drm_do_get_edid retries until it gets a result
> it is happy with. All in all, that is a lot of processor intensive
> looping in cases where we do not expect and cannot get valid data - for
> example on Intel with disconnected hardware we will busy-spin until we
> hit the i2c timeout. This is then repeated for every connector when
> querying the current status of outputs.
Sadly, this doesn't seem to make any difference to my case. My xrandr
stays at 0.555s even with this patch.
So apparently the Apple Mac Mini issue is not about retries. But maybe
this fixes the problem Stephan Bärwolf reported? The Apple Mac Mini
is known for doing things oddly, so ..
You didn't include Stephan on the cc for that patch, though.
Btw, clearly X does *not* cache the EDID results, at least not for
this case. So the explicit xrandr example is probably pretty close to
what wine does. Maybe the proper fix is to just make X.org force
caching when clients do this (because it's definitely X that does the
drm_mode_getconnector() thing - xrandr itself spends zero time on
this, it just does an X request and waits for the result).
The fact that EDID takes half a second to get is not a problem per se.
It's a problem only when X does it over and over again because some
client does something unexpected.
Linus
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
