How to handle the hardware X can't properly autodetect
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
- Started by
- Completed by
- Chris Halse Rogers
Whiteboard
Bryce's summary of desirable quirks lost in KMS switch: http://
Proposal for device tree quirk detection: https:/
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-
[raof] Add custom randr modes support to gnome-settings-
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-
raof, 2011-01-10: As we're not going to be switching to the new gnome-control-
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-
pitti, 2011-04-27: retargetting for oneiric, moving postponed WIs back to TODO
raof, 2011-05-18: Superseded by desktop-