On Thu, Oct 12, 2017 at 08:41:17PM +0200, Daniel Vetter wrote: > Hi Keith, > > On Tue, Oct 10, 2017 at 05:48:27PM -0700, Keith Packard wrote: > > This allows an application to discover what display resources are > > available before requesting a lease from the X server. > > > > Signed-off-by: Keith Packard <keithp@xxxxxxxxxx> > > For reasons I've kidna stopped reviewing these patches. I don't really > agree with the details of the lease uapi as implemented. But that's > nothing that can't be fixed with a few flags, and leases always need an > explicit opt-in from the compositor now, so still possible to do > reasonable architecture on top in the future. Worst case we fake just the > parts that X needs from this version of leases, we've done that kind of > stuff in the past. > > This here otoh is an uapi change that we can't ever undo or contain, > because as soon as we allow anyone to read kms state they will do so. And > do so in lots of very interesting and abusive ways. E.g. there's already > apps who try to second-guess the vblank timings with the vblank ioctl > (which accidentally works everywhere, not just on the master), and ofc get > it wrong, except for the case the developer tested on. Or without > uevent/udev events you can't do efficient output probing, which means > we'll see endless amounts of polling (we had to stop giving accurate data > in the sysfs interface already, for exactly this reasons, because someone > thought polling outputs once per second was a smart idea). > > So given the huge possibilities of abuse, do we really, really need all > this, and is there not any way to create a bit of protocol to pass the > relevant data from X to clients? From your presentation is sounded like > current xrandr is (almost) there ... One more that came up on irc after discussion why this is needed: The userspace side using this won't work on split gpus where the render node has 0 displays, and hence where you really need to query the compositor anyway. Like I predicted, we expose this, everyone will abuse it in slightly broken ways :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
