[Bug 91434] [IVB/HSW] 23.976Hz & 24Hz modes broken on dual-display with recent (4.0.x) kernels

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91434

--- Comment #65 from Martin Andersen <martin.x.andersen at gmail.com> ---
It took me a bit longer than anticipated to test this, but this has now finally
been done.

I will cut right to it - setting bpc to 8 with xrandr *does ensure proper
output* on the HDMI2 port, at least on the Haswell system I am testing with.
Tested 23.976Hz, 24Hz, 50Hz & 60Hz modes.

The limitiation of doing this with xrandr does present some other major issues
though which Intel needs to consider:

- No display is visible before Xorg has been started, a user logged in and the
xrandr command issued. This necessitates use of a second monitor simply to
accomplish the bpc switch.

- Any application can override this setting by requesting 10 or 12 bpc (for 
whatever reason, presumably by requesting the maximum bpc 'supported')

- For systems where the output which does not work properly on 10- or 12-bpc is
the sole means of interacting, having to rely on xrandr is not an option, as it
requires logging into a system which does not have a working display.

- More importantly, for systems which are using encrypted root-volumes via –
i.e, LUKS – there is no way to interact with the password prompt as the system
does not have display output.


Another point I need to make is that this issue is *only* present on Intel
systems using the built-in iGPU.

None of my other hardware devices consisting of:

- An Oppo Blu-Ray player
- A PS3
- A PS4
- A CableTV box
- An Nvidia Shield

Exhibit this issue, and they are hooked up *precisely the same way* as the
standalone Intel iGPU systems. Point being, the default should be 8bpc unless
an application specifically requests it. No functionality should be lost this
way.

Furthermore, the setting to lock one or more outputs to a certain bpc needs to
be set via a kernel parameter to the i915.ko or drm.ko kernel modules
themselves, in order to *ensure* that the system is not going black during boot
(or going black during operation due to an application requesting higher bpc). 

Once set, the output is working as the system shuts down (i.e, after X has
terminated)

Surely Intel sees the value of having the functionality work this way;
especially now that the source of the problem has been identified and the
mechanism for setting a lower bpc - has been implemented. It would certainly
affect more HTPC systems than just mine.

I will include debug logs for the sake of completeness.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20190206/9d9ef7b6/attachment.html>