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@gmail.com wrote:
On Mon, 20 May 2019 18:11:07 +0200 Daniel Vetter daniel@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?