How to handle the hardware X can't properly autodetect

Registered by Chris Halse Rogers on 2010-10-11

This blueprint has been superseded. See the newer blueprint "Tools and processes for diagnosing issues with graphic drivers" for updated plans.

Our kernel/X/desktop stack is now at the point where 90% of hardware is autodetected and configured appropriately.

Sadly, some hardware will never be successfully autodetectable. This session is for that final 10%:
 * What hardware classes are most in need of manual configuration (example: EDID-less monitors)
 * What configuration should we support
 * What UI should we expose

Blueprint information

Status:
Complete
Approver:
Martin Pitt
Priority:
Medium
Drafter:
Chris Halse Rogers
Direction:
Needs approval
Assignee:
Chris Halse Rogers
Definition:
Superseded
Series goal:
Accepted for natty
Implementation:
Not started
Milestone target:
None
Completed by
Chris Halse Rogers on 2011-05-17

Whiteboard

Bryce's summary of desirable quirks lost in KMS switch: http://article.gmane.org/gmane.linux.ubuntu.devel.x/436
Proposal for device tree quirk detection: https://wiki.ubuntu.com/X/Dev/DeviceTreeHWDetection

Work items:
[apw] investigate whether the EDID etc could become writable at the kernel level:
[apw] can we move i915 power etc configs to sysfs:

Work items:
[raof] Investigate how to identify EDID-less monitors to apply quirks:
[raof] Merge windows driver import code from displayconfig-gtk into gnome-display-preferences:
[raof] Add custom randr modes support to gnome-settings-daemon xrandr plugin:

Old WIs for natty:
[bryce] Package edid-decode utility and upload to universe: DONE
[jk-ozlabs] proposal for device tree node specifying the graphics quirks: DONE
[raof] Discuss with gnome upstream adding custom randr modes & import windows driver information: DONE

pitti, 2010-11-08: What do you mean with "custom xrandr modes"? Specifying modes that X.org itself didn't detect? Should they be handlede at the EDID level (writable sysfs), or do you really want to introduce overrides on two different levels (EDID and xrandr)?

bryce, 2010-11-08: Yes, modes that X.org did not detect. It does make sense to investigate both approaches, but understand they're aiming at the problem in very different ways. The RANDR approach uses the established, stable RANDR API, which definitely works currently (via command line) and should be straightforward to implement in the GUI. With the EDID override approach, the problem is lower level kernel coding stuff. That's a pretty fundamental question and may be very non-trivial to do. If we can just deliver natty with the ability to replace the edid file via the command line, that'll be a huge step forward and will solve a class of issue that the randr approach can't.

raof, 2010-11-25: Discussed with gnome-control-centre upstream, and they should be willing to accept custom randr mode patches with pretty much the design we were thinking.

raof, 2011-01-10: As we're not going to be switching to the new gnome-control-centre and we don't want to duplicate this work next cycle the gnome-display-preferences work won't land in natty. The kernel-level quirking options will still be useful.

pitti, 2011-02-18: FF in three days, which isn't enough time to add the kernel feature (writable EDID, etc.) and develop the userspace code. Postponing the remaining WIs, should get a new spec for o.

bryce, 2011-04-07: Made a new spec for o, and moved the remaining WIs to that spec. Chris, you can mark this spec Superseded by desktop-o-xorg-tools-and-processes

pitti, 2011-04-27: retargetting for oneiric, moving postponed WIs back to TODO

raof, 2011-05-18: Superseded by desktop-o-xorg-tools-and-processes, which contains all the unfinished work items.

(?)

Work Items