> Date: Sun, 13 Sep 2015 12:14:57 +0100 > From: Chris Wilson <[email protected]> > > On Sun, Sep 13, 2015 at 01:08:11PM +0200, Mark Kettenis wrote: > > > From: Chris Wilson <[email protected]> > > > Date: Sun, 13 Sep 2015 11:40:37 +0100 > > > > > > Before we change the state (e.g. adding a mode or applying one to an > > > output), we query the screen resources for the right identifiers. This > > > should only use the current information rather than force a reprobe on > > > all hardware - not only can that reprobe be very slow (e.g. EDID > > > timeouts on the order of seconds), but it may perturb the setup that the > > > user is trying to configure. > > > > How do you guarantee that that cached information isn't stale? > > There is no issue in that, since the user parameters are against the > output from a previous run. If the configuration is stale then so are > the xrandr parameters.
I bet tons of people have a script that runs xrandr to configure a projector connected to the VGA port on their laptop. Yes there is no guarantee that the parameters I give to xrandr match the current configuration. But if I connect the same projector (or even a different one) to the same VGA port I expect this script to work and make the display of my laptop appear on the projector. I expect this to work even when I connected the VGA cable after I started X. > > Seems you already can get the behaviour you want by specifying > > --current. Whereas there is no convenient way to force a probe, other > > than an explicit query? > > And there should not be. On KMS platforms regeneration of the RR > information is driven by hotplug events (either generated by the hw > itself or by a kernel worker emulating the notifications otherwise). An > explicit probe by the user should be the means of last resort not the > default. Well, that only works on KMS with udev. And only if the specific driver you're using has udev support. To me it seems that you're trying to solve this at the wrong level. If a driver (kernel or Xorg) has reliable hotplug support, shouldn't it be able to decide whether it needs to reread the EDID information of some monitor or not? _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
