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@xxxxxxxxx> wrote: > > > > On Mon, 20 May 2019 18:11:07 +0200 > > > > Daniel Vetter <daniel@xxxxxxxx> 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? _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
