Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

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

 



Manasi Navare <manasi.d.navare@xxxxxxxxx> writes:

> On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote:
>> Manasi Navare <manasi.d.navare@xxxxxxxxx> writes:
>> 
>> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote:
>> >> Martin Peres <martin.peres@xxxxxxxxxxxxxxx> writes:
>> >> 
>> >> > On 26/01/17 14:37, Martin Peres wrote:
>> >> >> Despite all the careful planing of the kernel, a link may become
>> >> >> insufficient to handle the currently-set mode. At this point, the
>> >> >> kernel should mark this particular configuration as being broken
>> >> >> and potentially prune the mode before setting the offending connector's
>> >> >> link-status to BAD and send the userspace a hotplug event. This may
>> >> >> happen right after a modeset or later on.
>> >> >>
>> >> >> When available, we should use the link-status information to reset
>> >> >> the wanted mode.
>> >> >>
>> >> >> Signed-off-by: Martin Peres <martin.peres@xxxxxxxxxxxxxxx>
>> >> >
>> >> > The relevant kernel patches have landed in drm-tip about a month ago.
>> >> >
>> >> > Eric, would you mind providing feedback on or merging this patch?
>> >> 
>> >> The later discussion has sounded like the kernel will (always) prune the
>> >> mode when we re-query, meaning that it doesn't make any sense to try to
>> >> re-set to the old mode.  Is this not the case?
>> >
>> >
>> > No the kernel will simply send a hotplug with link status as bad
>> > and then after that point its userspace driver's responsibility
>> > to check if link status is BAD, retry the same mode and if it fails
>> > then re probe.
>> 
>> So the kernel will sometimes allow the same mode to be re-set with the
>> same bpp?
>
> So when userspace driver re-sets the same mode, the kernel will call the
> mode valid function where it will see it can allow the sam mode perhaps
> at a lower bpp now since the link parameters are lowered.
> So the mode which failed at 30 bpp, might still work at 18bpp and is
> better going to a lower resolution.

The question was whether the kernel will ever allow the same mode at the
same bpp, since that's what this patch tries to do.

Attachment: signature.asc
Description: PGP signature

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux