linux-kernel - Re: [PATCH] drm: Reduce the number of retries whilst reading EDIDs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 24 Feb 2012 10:17:35 -0500
From:	Adam Jackson <ajax@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Chris Wilson <chris@...is-wilson.co.uk>,
	Dave Airlie <airlied@...hat.com>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org,
	Eugeni Dodonov <eugeni.dodonov@...el.com>
Subject: Re: [PATCH] drm: Reduce the number of retries whilst reading EDIDs

On Thu, 2012-02-23 at 12:15 -0800, Linus Torvalds wrote:

> 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).

RANDR exposes two requests here for a reason.  We used to only have
RRGetScreenResources which always pulled data afresh.  We added
RRGetScreenResourcesCurrent to get the cached version.  If you want
xrandr(1) to use the latter say xrandr --current.  Arguably xrandr
should do things the other way around and require you to say --reprobe
or something.

Even then, the kernel should cache if it can.  And any competent
hardware has plug interrupts on DP and DVI, so we really should get this
right.

- ajax

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)