[PATCH 0/3] Provide workarounds to use DRM/KMS with broken graphics hardware

From: Carsten Emde
Date: Sat Mar 10 2012 - 16:06:03 EST


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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/