Re: [PATCH 2/5] drm: Set DRM connector link status property

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

 



On Tue, Nov 15, 2016 at 03:56:09PM -0800, Manasi Navare wrote:
> On Tue, Nov 15, 2016 at 08:49:21AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote:
> > > + * If userspace is not aware of this property, the user experience is the same
> > > + * as it currently is. If the userspace is aware of the property, it has a chance
> > > + * to improve user experience by handling link training failures, avoiding black
> > > + * screens. The DRM driver can chose to not modify property and keep link status
> > > + * as "GOOD" always to keep the user experience same as it currently is.
> > 
> > Imo this paragraph isn't needed. Maybe just mention that old userspace
> > exists:
> >
> 
> I think keeping this paragraph is important to give the readers good idea of how this
> will affect the user experience.

Well generally the kernel is _really_ far away from the user experience. I
guess that's what makes this paragraph look strange to me, and why I
reworded it. Generally the next thing that matters from the kernel pov is
the compositor and it's display driver, hence why I used "userspace"
instead of "user experience". What userspace (the code) is supposed to do
is imo really important for new uabi, what the user experience ends up
being, that depends upon the entire stack (of which we control very
little, e.g. on Xorg we'll only send a hotplug event over Xrandr and let
some desktop thing handle the real mode change), and it's also fairly
abstract.
  
> > "Note that a lot of existing userspace doesn't handle this property.
> > Drivers can therefore not rely on userspace to fix up everything and
> > should try to handle issues (like just re-training a link) without
> > userspace's intervention. This should only be used when the current mode
> > doesn't work any more, and userspace must select a different display
> > mode."
> >
> 
> But atleast the way i915 uses this is in both cases where current mode
> does not get pruned but need sto be retried and also when current mode
> is no longer valid and gets pruned and modeset is done at a lower mode.
> But in either case if link training fails, this property is set to BAD.

Yeah, hence "should" and not "must", and even i915 does handle some
situations itself: E.g. if just retraining works out with different
training settings, then we don't need to involve userspace, despite that
the link went bad for a bit.
-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]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux