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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux