On 11/04/17 04:47, Eric Anholt wrote:
Martin Peres <[email protected]> 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 <[email protected]>



_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to