[PATCH 3/3] drivers-gpu-drm-i915-invert-backlight-brightness

[Carsten Emde]

[Carsten Emde]

In the good old days when graphics parameters were configured explicitly
in a file called xorg.conf, even broken hardware could be managed.

Today, with the advent of Kernel Mode Setting, a graphics board is
either correctly working because all components follow the standards -
or the computer is unusable, because the screen remains dark after
booting or displays the wrong area. Cases when this happens are:
- The BIOS assumes that an LVDS is always connected, even if it isn't.
- The graphics board does not recognize the monitor.
- The graphics board is unable to detect any EDID data.
- The graphics board incorrectly forwards EDID data to the driver.
- The monitor sends bogus EDID data.
- A KVM sends its own EDID data instead of querying the connected monitor.
- The brightness setting of the panel backlight does not work.
- Any combination of the above.
Adding the kernel parameter "nomodeset" helps in most cases, but causes
restrictions later on.

The three patches of this series add module parameters to the
drm_kms_helper module that
1. allow to load an EDID data set via the firmware interface,
2. provide a module parameter to selectively enable or disable a
graphics port,
3. provide a module parameter to select inverted brightness.

EDID data sets along with source files are provided for commonly used
screen resolutions (1024x768, 1280x1024, 1680x1050, 1920x1080).

Please note that these patches neither fix a kernel bug nor provide any
extra functionality. They simply work around broken hardware that
otherwise would be either unusable or usable in a very restricted way.
The patches do not modify the current functionality of the related
components in any way, unless the kernel is configured accordingly
and/or the newly provided module parameters are set.

-Carsten.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Carsten Emde]

[Carsten Emde]

[Dave Airlie]

On Sat, Mar 10, 2012 at 8:20 PM, Carsten Emde <C.E...@osadl.org> wrote:
> Some recent integrated graphics chipset, notably Intel's "Pineview", also
> provide on-chip LVDS support. As an extra service, the LVDS interface supplies
> EDID data - irrespective of whether an LVDS panel is connected or not. The
> drm_mode_getresources() function, therefore, causes Xorg to always include
> the LVDS panel into the display and initialize a separate screen for it. e.g.
> (II) intel(0): Output LVDS1 connected
> (II) intel(0): Output VGA1 connected
> (II) intel(0): Using spanning desktop for initial modes
> (II) intel(0): Output LVDS1 using initial mode 1024x768 +0+0
> (II) intel(0): Output VGA1 using initial mode 1280x1024 +1024+0
> which is not what you want, if the only connected screen is a VGA monitor.
> One would assume that the BIOS settings of such systems would allow to
> separately enable or disable LVDS support; unfortunately, systems have been
> found in the wild that do not provide this feature.

So video=LVDS-1:d doesn't work for you?

Dave.

[Alan Cox]

> This patch allows to load an EDID data set via the firmware interface.
> It contains data sets of frequently used screen resolutions (1024x768,
> 1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
> specified as a module parameter of the drm_kms_helper module, e.g.
> options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
> command line parameter.

What if the DRM layer and driver are compiled in. They'll come up as
console before the file system so the firmware request will hang ?


Given the EDID is tiny and is data not code wouldn't it be simpler (and
smaller) if this option compiled in a few generic EDIDs to use ?

Alan

[Carsten Emde]

On 03/11/2012 08:20 AM, Dave Airlie wrote:
> On Sat, Mar 10, 2012 at 8:20 PM, Carsten Emde<C.E...@osadl.org> wrote:
>> Some recent integrated graphics chipset, notably Intel's "Pineview", also
>> provide on-chip LVDS support. As an extra service, the LVDS interface supplies
>> EDID data - irrespective of whether an LVDS panel is connected or not. The
>> drm_mode_getresources() function, therefore, causes Xorg to always include
>> the LVDS panel into the display and initialize a separate screen for it. e.g.
>> (II) intel(0): Output LVDS1 connected
>> (II) intel(0): Output VGA1 connected
>> (II) intel(0): Using spanning desktop for initial modes
>> (II) intel(0): Output LVDS1 using initial mode 1024x768 +0+0
>> (II) intel(0): Output VGA1 using initial mode 1280x1024 +1024+0
>> which is not what you want, if the only connected screen is a VGA monitor.
>> One would assume that the BIOS settings of such systems would allow to
>> separately enable or disable LVDS support; unfortunately, systems have been
>> found in the wild that do not provide this feature.
>
> So video=LVDS-1:d doesn't work for you?

Oops, yes, you are totally right. By some reason, I overlooked this
option. I tried two systems that need forced disabling and enabling with
video=LVDS-1:d video=VGA-1:e
which worked perfectly well.

So please skip this patch, sorry for the noise.

Thanks,
-Carsten.

[Carsten Emde]

On 03/11/2012 02:44 PM, Alan Cox wrote:
>> This patch allows to load an EDID data set via the firmware interface.
>> It contains data sets of frequently used screen resolutions (1024x768,
>> 1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
>> specified as a module parameter of the drm_kms_helper module, e.g.
>> options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
>> command line parameter.
>
> What if the DRM layer and driver are compiled in. They'll come up as
> console before the file system so the firmware request will hang ?

Admittedly I did not try to compile the DRM layer and driver into the
kernel. However, I created an error condition by specifying a
non-existing EDID file. In this case, the function returns with error,
the mode count remains 0, and the system continues to run as if the
edid_firmware= parameter had not been specified.

Now that you were asking, I created a static kernel and did some more
tests, but I couldn't find any problem. Everything worked as expected. I
believe that the early console still runs in BIOS VGA mode, i.e. either
using the BIOS default mode or the one that was specified using the vga=
parameter, if any. DRM apparently comes into play at a later stage only,
but I will do some more testing.

> Given the EDID is tiny and is data not code wouldn't it be simpler (and
> smaller) if this option compiled in a few generic EDIDs to use ?

Yes, this certainly would be possible. However, we would loose the
flexibility to specify an individual EDID data set without recompiling
the kernel. As an alternative, we could compile the four standard EDIDs
into the DRM helper instead of providing them as a file, but still leave
the option to load an individual EDID via the firmware interface. This
would make the patch much smaller and avoid spamming the firmware
directory. How about that?

Thanks,
-Carsten.

[Carsten Emde]

Alan,

>> This patch allows to load an EDID data set via the firmware interface.
>> It contains data sets of frequently used screen resolutions (1024x768,
>> 1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
>> specified as a module parameter of the drm_kms_helper module, e.g.
>> options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
>> command line parameter.

> [..]

> Given the EDID is tiny and is data not code wouldn't it be simpler (and
> smaller) if this option compiled in a few generic EDIDs to use ?

I liked the idea so much that I gave it a try. The patch looks much
better now, but has the same functionality as before. As the only
disadvantage, the patch no longer contains the template to produce a
particular EDID. But this code may be made available elsewhere - no need
to have it in the kernel.

Hope you like it.

Thanks,
-Carsten.

[Valdis.K...@vt.edu]

On Sat, 10 Mar 2012 21:20:15 +0100, Carsten Emde said:

> EDID data source files are provided for documentation purpose and as a
> template to create EDID data sets for other screen resolutions. Note
> that source compilation is not part of the build process, but needs to
> be done manually, e.g.
>
> #!/bin/bash
> cd firmware/edid
> for i in [1-9]*.S
> do

Would it be possible to include a version of this patch's Changelog as a file
under Documentation/fixing-broken-edid.txt or something, so people don't have
to go and find the git commit log to know things like "you need to run
dos2unix"? Be a shame to have a changelog that does such a good job of
documenting what you need to do, and have it lost in git...

[Michael Witten]

On Sun, 11 Mar 2012 22:23:22 +0100, Carsten Emde wrote:

> On 03/11/2012 02:44 PM, Alan Cox wrote:
>
>>> This patch allows to load an EDID data set via the firmware interface.
>>> It contains data sets of frequently used screen resolutions (1024x768,
>>> 1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
>>> specified as a module parameter of the drm_kms_helper module, e.g.
>>> options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
>>> command line parameter.
>>
>> What if the DRM layer and driver are compiled in. They'll come up as
>> console before the file system so the firmware request will hang ?
>
> Admittedly I did not try to compile the DRM layer and driver into the
> kernel. However, I created an error condition by specifying a
> non-existing EDID file. In this case, the function returns with error,
> the mode count remains 0, and the system continues to run as if the
> edid_firmware= parameter had not been specified.

Unfortunately, as of at least last month, my system hangs when I try to
use your feature (just as described by Alan Cox); the log shows that
during the boot process, there is a one-minute hang:

[ 0.175207] [drm] radeon: power management initialized
[ 60.896507] [drm:edid_load] *ERROR* Requesting EDID firmware "edid/1920x1200.bin" failed (err=-2)

Is there any way to make your feature smarter about its timing with
relation to file system accessibility?

Sincerely,
Michael Witten

[Carsten Emde]

Michael,

> On Sun, 11 Mar 2012 22:23:22 +0100, Carsten Emde wrote:
>> On 03/11/2012 02:44 PM, Alan Cox wrote:
>>>> This patch allows to load an EDID data set via the firmware interface.
>>>> It contains data sets of frequently used screen resolutions (1024x768,
>>>> 1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
>>>> specified as a module parameter of the drm_kms_helper module, e.g.
>>>> options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
>>>> command line parameter.
>>> What if the DRM layer and driver are compiled in. They'll come up as
>>> console before the file system so the firmware request will hang ?
>> Admittedly I did not try to compile the DRM layer and driver into the
>> kernel. However, I created an error condition by specifying a
>> non-existing EDID file. In this case, the function returns with error,
>> the mode count remains 0, and the system continues to run as if the
>> edid_firmware= parameter had not been specified.
> Unfortunately, as of at least last month, my system hangs when I try to
> use your feature (just as described by Alan Cox); the log shows that
> during the boot process, there is a one-minute hang:
>
> [ 0.175207] [drm] radeon: power management initialized
> [ 60.896507] [drm:edid_load] *ERROR* Requesting EDID firmware "edid/1920x1200.bin" failed (err=-2)
>
> Is there any way to make your feature smarter about its timing with
> relation to file system accessibility?

Sure.

Please copy your EDID data file to the directory "firmware/edid" of the
kernel source tree, configure

CONFIG_EXTRA_FIRMWARE="edid/1920x1200.bin"
CONFIG_EXTRA_FIRMWARE_DIR="firmware"

and rebuild/reboot your kernel.

Does it work then?

-Carsten.