On Wed, Jun 5, 2013 at 5:50 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx > Cc: Jakob Bornecrantz <jakob@xxxxxxxxxx> > Cc: Inki Dae <inki.dae@xxxxxxxxxxx> > Cc: Adam Jackson <ajax@xxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
