[Intel-gfx] [PATCH 0/2] drm: link status property and DP link training failure handling
martin.peres at linux.intel.com
Fri Jan 20 16:29:45 UTC 2017
On 19/01/17 11:18, Jani Nikula wrote:
> On Wed, 18 Jan 2017, Martin Peres <martin.peres at linux.intel.com> wrote:
>> On 16/12/16 15:48, Daniel Vetter wrote:
>>> On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
>>>> The two remaining patches from , rebased.
>>>>  http://firstname.lastname@example.org
>>> Just for the record, I think the only thing missing here is the Xorg
>>> review on the -modesetting patch. As soon as we have that I can vacuum
>>> this up (probably best through drm-misc, but not sure).
>> Hey Daniel,
>> I tested again on Monday -modesetting with the patch from Jani to inject
>> faults and did manage to get both the link-status BAD and a lower
>> resolution got select dynamically when running KDE. For the latter, I
>> however needed the following patch:
>> Now, that being said, Jani's patch just prevents a new modeset to work,
>> it does not tear down the current mode. This may be the reason why I do
>> not manage to get a black screen after > 3 failures (and already a
>> 1024x768 resolution).
>> I however need to do more testing when running without a DE (straight X
>> + twm and xterm). Indeed, when I hotplug my DP screen, it gets to the
>> native resolution automatically without me asking for it using xrandr.
>> Also, the mode that is set does not seem to go through
>> intel_dp_start_link_train (what the heck?), so I do not get any failure
>> and I cannot induce one :s
> Huh, does your X + twm actually respond to hotplugs?
No, that was the point of the test :) I just wanted to see the screen
turn black but it did not because even if the link training fails, i915
keeps on going and pushes the pixels out constantly. My screen was
good-enough to pick it up and display it without complaining ... which
is really surprising for DP, isn't it?
More information about the Intel-gfx