On Wed, Oct 26, 2016 at 04:15:39PM +0300, Ville Syrjälä wrote: > On Wed, Oct 26, 2016 at 02:11:00PM +0100, Chris Wilson wrote: > > 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 <chris@xxxxxxxxxxxxxxxxxx> 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? > > Dunno really. If we don't add it we have to define what the link status > will indicate when the thing is really off though. With "good" and "bad" > the only options I guess "good" would be the right answer? Fair point. bad = -1, (any specific error can then be -value) ok = 0, suspend, standy, off, [looking suspiciously like dpms modes :] ? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
