On Wed, Oct 26, 2016 at 02:17:16PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 26, 2016 at 12:51:41PM +0300, Jani Nikula wrote:
> > On Wed, 26 Oct 2016, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> > > On Wed, Oct 26, 2016 at 07:52:26AM +0200, Daniel Vetter wrote:
> > >> I'd go further and just always create this as one of the standard
> > >> properties (and always attach it to the connector, like edid), and only
> > >> expose helpers to set the link status to good or bad.
> > >
> > > One of the sketches for this idea was that this could serve as the
> > > failure notification path for nonblocking modesets (well modesets in
> > > general since it appears returning the error is not going to happen).
> > 
> > In nonblocking modesets, when should we change the status from bad to
> > good? If the setcrtc returns and userspace looks at link status and sees
> > it's still bad (because the kernel hasn't gotten around to enabling the
> > link yet, or whatever), userspace might think it would have to try
> > again. Do we set it to good immediately on setcrtc ioctl, or add a
> > "pending" status? Or something better?
> 
> I was thinking it'd start out as "good" and only change to something
> else when things actually go south.
> 
> Not sure if we should also want "off" as one of the values, for when
> it's really off at the request of the user.

That's something the user knows. At least, if the ddx has output->crtc
set and sees that link-status=off the response is to say "that can't be
me!" and reapply the desired mode, i.e. same response as if the
link-status was bad. Maybe useful for someone else to differentiate?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to