linux-kernel - Re: drivers/gpu/drm/i915/intel_dp.c problem with commit dc22ee6fc18ce0f15424e753e8473c306ece95c1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGPN=9SBgWLHsUsfrCVCtVDpAcuW_4oe_4_X2tHCcZPatJdRgw@mail.gmail.com>
Date:	Wed, 30 Nov 2011 21:36:59 +0100
From:	Patrik Kullman <patrik.kullman@...il.com>
To:	Keith Packard <keith.packard@...el.com>
Cc:	Jerker Buud <b.jerker@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: drivers/gpu/drm/i915/intel_dp.c problem with commit dc22ee6fc18ce0f15424e753e8473c306ece95c1

Not sure if this is somehow related, but I experienced a weird issue
with the HDMI-output today.

I connected the computer to a (Acer) projector at work to hold a
presentation, but it didn't work.
In GNOME Displays, I could see a connected "Acer Technologies" screen,
its supported resolutions listed, I could even move the cursor as if a
screen was connected. Everything about Linux/GNOME seems to "think"
everything was working.

On the projector side of things, the Acer-logo was showing and the
source (HDMI1/2) was showing.
It didn't say "No Signal" as it can, but it didn't either come as far
as to "Process signal", which usually appears a moment before
everything is up and running.

Booting up Windows, everything worked perfectly.

When I got home, I connected the computer to my LCD TV and watched a
video without any issues.
Even sound through HDMI works great.

Please let me know if you think this might be related or if I should
start a new thread about this.

2011/11/29 Patrik Kullman <patrik.kullman@...il.com>:
> I checked out a clean v3.2-rc3, applied this patch and rebooted.
>
> It still doesn't work and Caps Lock still doesn't respond, but I get
> very subtle flickering of the screen, 2-3 seconds apart, kind of like
> different shades of black.
>
> It 'feels' as if some graphics card/link/monitor negotiation is taking place.
>
> 2011/11/26 Keith Packard <keith.packard@...el.com>:
>> On Sat, 26 Nov 2011 09:50:41 -0800, Jerker Buud <b.jerker@...il.com> wrote:
>>
>>> 245,247c245,246
>>> <       if (!is_edp(intel_dp) &&
>>> <           (intel_dp_link_required(intel_dp, mode->clock)
>>> <            > intel_dp_max_data_rate(max_link_clock, max_lanes)))
>>> ---
>>> >       if (intel_dp_link_required(intel_dp, mode->clock)
>>> >           > intel_dp_max_data_rate(max_link_clock, max_lanes))
>>
>> Ok, I think I understand why this change is required.
>>
>> These machines are 'optimized' to provide the bare minimum connection
>> necessary between the CPU and the eDP panel -- a single lane is hooked
>> up, which is just enough to run the link at 18bpp, but not enough to run
>> it at 24bpp.
>>
>> The problem here (in intel_dp_link_required) is that this is being
>> called to see which modes can be supported on the panel. Without the
>> CRTC being configured with the appropriate bpp value, this code assumes
>> 24bpp.
>>
>> I thought Adam Jackson had some code around that automatically switched
>> From 24bpp to 18bpp when the link didn't have enough bandwidth for
>> 24bpp, but I can't find that now.
>>
>> In any case, I think we need to centralize the bpp selection inside
>> intel_dp.c instead of having it in both places. Then, we can make that
>> depend on the requested mode as well as the machine configuration.
>>
>> Here's a patch which uses the VBT configured bpp value in this case. I'd
>> love to hear whether this suffices to resolve your problem.
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index 294f557..3e15479 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -212,10 +212,16 @@ intel_dp_link_required(struct intel_dp *intel_dp, int pixel_clock)
>>  {
>>        struct drm_crtc *crtc = intel_dp->base.base.crtc;
>>        struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>> -       int bpp = 24;
>> +       struct drm_device *dev = intel_dp->base.base.dev;
>> +       struct drm_i915_private *dev_priv = dev->dev_private;
>> +       int bpp;
>>
>>        if (intel_crtc)
>>                bpp = intel_crtc->bpp;
>> +       else if (intel_dp->base.type == INTEL_OUTPUT_EDP)
>> +               bpp = dev_priv->edp.bpp;
>> +       else
>> +               bpp = 24;
>>
>>        return (pixel_clock * bpp + 9) / 10;
>>  }
>>
>> --
>> keith.packard@...el.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/