[PATCH 2/6] drm: Allow render nodes to query display objects

[Daniel Vetter]

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 at keithp.com>
> 
> 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