[i915/drm] Add module option to disable 12bpc at boot-time in order to ensure video output
This is in reference to my long-running issue, #24 (closed), where the underlying problem was eventually partially solved by adding an option to xrandr to manually switch bpc after X has started, and a user logged in. I was asked to open a new issue for this enhancement, and I am therefore doing so now. [ref. @vsyrjala, @l4kshmi, @banns]
This xrandr approach – however – is only part of the solution: affected systems still do not have any video output at all during boot, thus preventing a user from successfully logging in. It also prevents user interaction before an xrandr command is issued, e.g, in order to provide a LUKS passphrase to unlock the system drive, or diagnose any boot errors due to system or kernel changes. This is quite a significant drawback.
As I mention in the ticket referenced above, this can easily be achieved by providing a module option to the i915 driver which disables deep color – if this was excplicitly requested at boot-time by the user – by implementing the following as an option which returns false for the "hdmi_deep_color_possible" function below (i915.disable_deep_color = 1):
./drivers/gpu/drm/i915/display/intel_hdmi.c
2147 static bool hdmi_deep_color_possible(const struct intel_crtc_state *crtc_state,
2148 int bpc)
2149 {
2150 return false;
I have tested this fix on recent 5.5.x and 5.6.x kernel branches, as well as drm-tip, and the approach ensures proper output from the Intel iGPU (where, again, other systems connected the exact same way does not have an issue)
It was tested on my main Ivy Bridge system (running an HD4000), and on two Haswell systems (one HD4600) and the other a MacBook w/ Iris(TM) Pro Graphics 5200.
To summarize: the limitiation of only being able to do this via xrandr presents some 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:
- A Blu-Ray player
- A PS3
- A PS4
- A CableTV box
- An Nvidia Shield
- A Raspberry Pi
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.