[PATCH v7 09/11] drm: uevent for connector status change

[Ser, Simon]

On Mon, 2019-06-03 at 17:08 +0200, Daniel Vetter wrote:
> On Mon, Jun 03, 2019 at 11:50:53AM +0200, Michel Dänzer wrote:
> > On 2019-05-21 9:52 a.m., Daniel Vetter wrote:
> > > On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > > > On Mon, 20 May 2019 18:11:07 +0200
> > > > Daniel Vetter <daniel at ffwll.ch> wrote:
> > > > 
> > > > > There's also a fairly easy fix for that -modesetting issue: We don't
> > > > > expose atomic if the compositor has a process name of "Xserver". Brutal,
> > > > > but gets the job done. Once X is fixed, we can give a new "I'm not totally
> > > > > broken anymore" interface to get back at atomic.
> > > > 
> > > > You mean "Xorg". Or maybe "X". Or maybe the setuid helper? Wait, do you
> > > > check against the process issuing ioctl by ioctl, or the process that
> > > > opened the device? Which would be logind? What about DRM leasing? ...
> > > 
> > > In the Get/SetCaps ioctl we can do the check, which is called from X,
> > > not logind. We just need some way to tell -modesetting apart from
> > > everything else, and luckily there's not any other atomic X drivers.
> > 
> > Not yet...
> > 
> > As for a "I'm not totally broken anymore" interface, we did something
> > like that (though kind of in the other direction) with
> > RADEON_INFO_ACCEL_WORKING, but later RADEON_INFO_ACCEL_WORKING2 had to
> > be added, because the former claimed acceleration was "working" in cases
> > where it really wasn't... That kind of thing could become ugly in the
> > long run if other Xorg driver start using atomic, and they'll inevitably
> > be broken in different ways.
> 
> It's definitely a very suboptimal situation. Not sure there's a good way
> out. The trouble here is that i915 ended up configuring crtc/connectors
> differently than -modesetting (to allow fastboot, which I think is still
> i915 exclusive). This then highlighted that modesetting can't do atomic
> modesets if you try to reassign connectors.
> 
> One idea I have is that vgms would help compositors to play out a bunch of

Just so people aren't confused: I think Daniel meant "vkms" here :P

> standard scenarios, even automated. But that's not there yet, and every
> compositor project needs to care beyond "boots on my laptop, ship it". No
> idea that's even possible.

Having documentation for userspace is also important IMHO.

Regarding automated compositor testing, it's probably not possible to
have a single place where all compositors are tested: vkms should
probably be included as part of their CI. Thoughts?

Anyway, we could start a discussion to see if compositor people are
interested. Or have you already talked to some compositor maintainers?