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

2017-04-12 Thread Manasi Navare
On Wed, Apr 12, 2017 at 11:00:18AM -0700, Eric Anholt wrote:
> Martin Peres  writes:
> 
> > On 11/04/17 04:47, Eric Anholt wrote:
> >> Martin Peres  writes:
> >>
> >>> 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.
> >>>
> >>> Upon receiving a hot-plug event, we iterate through the connectors to
> >>> re-apply the currently-set mode on all the connectors that have a
> >>> link-status property set to BAD. This modeset may fail immediatly if
> >>> the kernel has already pruned the mode we are trying to set but it
> >>> does not matter as -modesetting has no business picking another
> >>> mode if the modeset did fail. To make users aware of this problem
> >>
> >> I think I'd like to replace the "This modeset" sentence with "The kernel
> >> may be able to get the link to work by dropping to using a lower link
> >> bpp (with the same display bpp).  However, the modeset may fail if the
> >> kernel has pruned the mode, so to make users aware..."  Does that sound
> >> good to you?
> >
> > Yep, nice improvement. Thanks!
> 
> Pushed.  Thanks, and sorry this took *so* long.

Thanks Eric for your review and for pushing the patch.
Thanks Martin for the patch. 

Do you know which Xserver release would this be part of?
Which Xserver version would be required for the entire end to end
testing with this feature?

Regards
Manasi



> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

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

2017-04-12 Thread Eric Anholt
Martin Peres  writes:

> On 11/04/17 04:47, Eric Anholt wrote:
>> Martin Peres  writes:
>>
>>> 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.
>>>
>>> Upon receiving a hot-plug event, we iterate through the connectors to
>>> re-apply the currently-set mode on all the connectors that have a
>>> link-status property set to BAD. This modeset may fail immediatly if
>>> the kernel has already pruned the mode we are trying to set but it
>>> does not matter as -modesetting has no business picking another
>>> mode if the modeset did fail. To make users aware of this problem
>>
>> I think I'd like to replace the "This modeset" sentence with "The kernel
>> may be able to get the link to work by dropping to using a lower link
>> bpp (with the same display bpp).  However, the modeset may fail if the
>> kernel has pruned the mode, so to make users aware..."  Does that sound
>> good to you?
>
> Yep, nice improvement. Thanks!

Pushed.  Thanks, and sorry this took *so* long.


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

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

2017-04-12 Thread Martin Peres

On 11/04/17 04:47, Eric Anholt wrote:

Martin Peres  writes:


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.

Upon receiving a hot-plug event, we iterate through the connectors to
re-apply the currently-set mode on all the connectors that have a
link-status property set to BAD. This modeset may fail immediatly if
the kernel has already pruned the mode we are trying to set but it
does not matter as -modesetting has no business picking another
mode if the modeset did fail. To make users aware of this problem


I think I'd like to replace the "This modeset" sentence with "The kernel
may be able to get the link to work by dropping to using a lower link
bpp (with the same display bpp).  However, the modeset may fail if the
kernel has pruned the mode, so to make users aware..."  Does that sound
good to you?


Yep, nice improvement. Thanks!



I'll give this patch a day or two for anyone else to complain, then I'll
push.


a warning is outputed in the logs to warn about having a
potentially-black display.

This patch does not modify the current behaviour of always propagating
the events to the randr clients. This allows desktop environments to
re-probe the connectors and select a new resolution based on the new
(currated) mode list if a mode disapeared. This behaviour is expected in
order to pass the Display Port compliance tests.

Signed-off-by: Martin Peres 




___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel


___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

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

2017-04-10 Thread Eric Anholt
Martin Peres  writes:

> 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.
>
> Upon receiving a hot-plug event, we iterate through the connectors to
> re-apply the currently-set mode on all the connectors that have a
> link-status property set to BAD. This modeset may fail immediatly if
> the kernel has already pruned the mode we are trying to set but it
> does not matter as -modesetting has no business picking another
> mode if the modeset did fail. To make users aware of this problem

I think I'd like to replace the "This modeset" sentence with "The kernel
may be able to get the link to work by dropping to using a lower link
bpp (with the same display bpp).  However, the modeset may fail if the
kernel has pruned the mode, so to make users aware..."  Does that sound
good to you?

I'll give this patch a day or two for anyone else to complain, then I'll
push.

> a warning is outputed in the logs to warn about having a
> potentially-black display.
>
> This patch does not modify the current behaviour of always propagating
> the events to the randr clients. This allows desktop environments to
> re-probe the connectors and select a new resolution based on the new
> (currated) mode list if a mode disapeared. This behaviour is expected in
> order to pass the Display Port compliance tests.
>
> Signed-off-by: Martin Peres 



signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel