Features/HDTVEnhancements

From FedoraProject

< Features
Revision as of 14:52, 24 June 2009 by Ajax (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Contents

Enhanced HDTV Support

Summary

The X server in Fedora 10 has been enhanced to support HDTVs better.

Owner

Current status

  • Targeted release: Fedora 11
  • Last updated: 2008-09-18
  • Percentage of completion: 66%

Update, 2008-08-29: The X server in rawhide will fetch all EDID extension blocks, and publishes the complete block in all the usual places (log file, RANDR properties, etc). Extended block parse is still TODO.

Update, 2008-09-18: Minor ABI issues were discovered with trying to do this in an upstream-consumable way. See this message to the xorg list for details. I'm changing strategy for F10 to parse the extended blocks directly inside the RANDR code rather than try to define a driver ABI, which will require some minor rewriting.

Detailed Description

HDTV displays often include additional EDID data that describes their preferred video timings for non-native resolutions. For example, a 1080p display might list only the native timing in the base EDID block, and leave the 720p or 480p modes for the extended block. It is important to use the device's preferred timings, since they are padded to allow room in the signal for HDMI audio.

Benefit to Fedora

  • Using the display's timing will allow HDMI audio to work without fiddling.
  • Allowing the display to scale video will take the scaling load off the CPU, saving power and thus the planet.

Scope

The first part is the act of fetching EDID blocks beyond the first from the monitor. This is mostly accomplished in upstream X server, and is a straightforward backport. The second part is parsing the additional data, which is also straightforward but not written yet. Should be a weekend hack if we're lucky.

Drivers using the RANDR 1.2 infrastructure for setup should be able to pick up this enhancement mostly for free, since the EDID fetch code is called from within the RANDR core itself. Legacy setup drivers would need to be patched to use this additional information, but those drivers are relatively rare for modern hardware, and can be done last and as a best-effort.

How To Test

The test matrix is basically a 2 by 2 square: RANDRful and legacy drivers, against monitors with simple and extended EDID.

RANDRful drivers include intel, radeon, and nv when running on GeForce 8 and newer. Legacy drivers is everything else.

Known extended EDID monitors that I have easily accessible include:

  • Sharp PN-G655 (industrial signage)
  • Westinghouse 42W2 (consumer TV)
  • Apple 23" Cinema Display (single-link DVI PC display)
  • Apple 30" Cinema Display (dual-link DVI PC display)

This gives pretty broad coverage across a range of display types. Simple EDID monitors are still the vast majority, so will be easy to find.

User Experience

More "Just Works" for HTPC users, and for presentation screens that use large-format LCDs instead of projectors.

Dependencies

Given the ABI issues with exposing this in a driver-visible way, this will be done entirely within the X server's RANDR code. No driver changes should be needed anymore.

Contingency Plan

The existing EDID fetch code appears to be stable, and can be left in for release with no ill effects. The final mode extraction code is not landed yet, and is entirely contained to the server's RANDR code; if necessary it can be delivered in a post-release update.

Documentation

(First section assuming the mode extraction code lands)

If the output of:

grep 'sections to follow' /var/log/Xorg.0.log

is not empty, then your monitor may have additional EDID sections that can be used to better configure your display. To help us better configure these kinds of displays, please email your X log to FIXME need an email address here.

Release Notes

None needed, hopefully, although a reminder about gnome-display-properties being super awesome now is probably a good idea.

Comments and Discussion