[PATCH] drm: Avoid forcing a detection cycle following a hotplug event

[Daniel Vetter]

On Wed, Jun 5, 2013 at 5:50 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> The typical procedure after a hotplug event is then to enumerate all the
> new modes. In the existing code, this is achieved by performing a forced
> detection cycle over all connectors. Ideally, we should just be able to
> use the current detection status and only enumerate the modes on the
> connectors that changed. This is a step in that direction by teaching
> the hotplug path to only use the known detection status rather than
> performing a second *forced* detection on every connector. As it
> currently stands, the first thing userspace does upon receipt of a
> hotplug uevent is call DRM_IOCTL_MODE_GETCONNECTOR on each connector,
> which of course, performs another full detection cycle.
>
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: dri-devel at lists.freedesktop.org
> Cc: Jakob Bornecrantz <jakob at vmware.com>
> Cc: Inki Dae <inki.dae at samsung.com>
> Cc: Adam Jackson <ajax at redhat.com>

I've dumped a bit a longer blabla text onto the i915 patch in this
series (and cc'ed dri-devel on it), so just the gist: I'm a bit
unhappy that we add a force parameter here essentially just for the
fbdev helper. Imo userspace and legacy fbdev should use the same api,
if that's not good enough the interface is probably not fully
suitable. The end result is a pretty convoluted sequence:
- hpd/poll work calls ->detect
- fbdev calls into ->fill_modes, but avoids ->detect with the
force=false parameter, so this is the part which calls ->get_modes
- userspace avoids calling ->fill_modes with a special trick

I prefer things more explicit ;-)

Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch