Short Guide to KMS Graphics Quirks in the Kernel

[Bryce Harrington]

What follows is a brief overview of kernel code where graphics hardware
can be quirked. 

Quirks have tended to be one of the most important ways we fix up
hardware specific graphics problems.

Knowing where to look for quirks (and creating them where needed) is a
good thing to know whether you do:  A) Hardware Enablement, B) Customer
Technical Support, C) DRM Bug Triage, D) X Package Maintenance.

Tip for DRM maintainers: Look in the upstream git tree for these files
to see if new quirks have recently been added.  Often these are cheap
and easy backports that solve serious graphics issues on specific HW.

Btw, all files mentioned are found under linux-*/drivers/gpu/drm/


=== Monitor Quirking:  drm_edid.c ===

Broken EDID is one of the most common kinds of issues we need to quirk
for.  These bugs are monitor-specific, and sometimes even
resolution-specific.  Typical symptoms include:

  * Incorrect font sizes
  * Wrongly selected resolutions
  * Wrongly selected refresh rates
  * Wrong physical screen dimensions reported

These quirks are covered in the file drivers/gpu/drm/drm_edid.c.  The
documentation in the source code is pretty vague.  I don't think there's
a simple way to test out quirks other than patching the kernel code.  So
if you suspect you have a monitor needing one of these quirks, add the
monitor name and/or product_id to the edid_quirk_list[] list with the
quirk you want to test.  Rebuild kernel, boot, and test.


=== Radeon Output Quirking: radeon/radeon_atombios.c and
radeon_combios.c  ===

The routine radeon_atom_apply_quirks() in the file radeon_atombios.c
fixes issues related to bad output detection for newer ATI hardware that
uses atombios.  So if a given piece of hardware has DVI but it shows up
as HDMI or VGA, or reports DVI-D instead of DVI-I, or similar types of
problems, this is where it's fixed.

For older pre-atombios hardware, this is done in
radeon_apply_legacy_quirks() in radeon_combios.c


=== Radeon AGP Quirking: radeon/radeon_agp.c ===

For older AGP-based systems, having the wrong AGP_Mode is a common
problem.  Unfortunately these are often incompatibilities between the
graphics card and the host bridge, and quirking is the only viable
solution.

I guess the best way for bug reporters to test this is to boot into UMS
mode and test different AGP_Modes in their xorg.conf.  When one is found
to work, add an appropriate quirk to the radeon_agpmode_quirk table.
You need to know the bus id (the first entry in lspci -vvnn) and the
card pci id (also in lspci -vvnn - the line for the VGA card).


=== Radeon Encoder Quirks: radeon/radeon_encoders.c ===

I'm not sure when you'd want to do quirks to the encoder but this is
done in atombios_apply_encoder_quirks() in radeon_encoders.c.  There is
one macbook listed here.


=== Intel No Display After Lid Close Quirks: i915/intel_lvds.c ===

A common problem on Intel is laptop lids that incorrectly report their
status.  This can result in the display turning black after the splash
screen but before gdm shows up.  The system isn't hung (you can still
hear the login sound) but the display just doesn't come on.

The bad_lid_status[] list in intel_lvds.c contains the quirks for these
devices.  You need to gather dmidecode output from the bug reporter in
order to add these quirks, but given that it should be straightforward
to construct a quirk patch.  Unfortunately with KMS I don't know of a
way to let the user test a quirk without having to rebuild the kernel;
with UMS there were options exposed by the driver that could be set in
the xorg.conf which made testing easy.


=== Intel Phantom LVDS Quirks: i915/intel_lvds.c ===

Some systems report having a LVDS display when in reality they don't.
Hybrid systems like the Dell Studio Hybrid and various *Mini type
systems are like this.  They have a laptop motherboard in a desktop
case, and thus the confusion.

These systems can be quirked in the intel_no_lvds[] list in intel_lvds.c


=== Intel Bad SDVO TV Quirks: i915/intel_sdvo.c ===

intel_sdvo_bad_tv[] in intel_sdvo.c lists systems that have an incorrect
SDVO TV output that should be ignored.  Only one system is listed so
this seems to be an unusual problem.  Again, dmidecode data is needed
for making these quirks.