From: Carsten Emde <C.Emde@osadl.org>
To: David Airlie <airlied@linux.ie>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Carsten Emde <C.Emde@osadl.org>,
DRI <dri-devel@lists.freedesktop.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH 0/3] Provide workarounds to use DRM/KMS with broken graphics hardware
Date: Sat, 10 Mar 2012 21:20:14 +0100 [thread overview]
Message-ID: <20120310202014.828058552@osadl.org> (raw)
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.
next reply other threads:[~2012-03-10 21:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-10 20:20 Carsten Emde [this message]
2012-03-10 20:20 ` [PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch Carsten Emde
2012-03-11 13:44 ` Alan Cox
2012-03-11 21:23 ` Carsten Emde
2012-04-25 2:30 ` Michael Witten
2012-04-25 22:46 ` Carsten Emde
2012-03-11 23:59 ` Carsten Emde
2012-03-12 17:14 ` Valdis.Kletnieks
2012-03-10 20:20 ` [PATCH 2/3] drivers-gpu-drm-add-disable-enable-connector.patch Carsten Emde
2012-03-11 7:20 ` Dave Airlie
2012-03-11 20:46 ` Carsten Emde
2012-03-10 20:20 ` [PATCH 3/3] drivers-gpu-drm-i915-invert-backlight-brightness Carsten Emde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120310202014.828058552@osadl.org \
--to=c.emde@osadl.org \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox