On Mon, 2010-11-22 at 13:26 +0000, Bastien Nocera wrote: > On Mon, 2010-11-22 at 12:27 +1100, Christopher James Halse Rogers wrote: > <snip> > > Monitors quite often come with windows driver discs, and these drivers > > are also commonly available on manufacturer's websites. These “drivers” > > are little more than a list of modes supported by the monitor; there's > > some code floating around to parse these. > > > > There's also a class of users who have an idea what the correct > > resolution for their monitor is but aren't able to do the magic xrandr > > dance to add it. > > > > I'd like to implement some UI to support both of these use-cases - “I've > > got some windows drivers here…” and “The box says it supports > > 1280x1024…”. Given this previous exchange… > > From a control-center POV, this isn't something we'd want to add to the > UI. > > > On Thu, 04 Nov 2010 19:32:10 +0000, Bastien Nocera wrote: > > > > > <snip> > > > The problem with your thinking is that the display panel is not there to > > > switch resolutions, but to allow easy setup of projectors, or external > > > displays. > > > > > > This isn't to say that switching resolutions should be impossible, but > > > it's not the goal of the tool. > > > > > > Rotating the screens is also not a priority, as we hope to handle that > > > through key presses (there's a patch to that effect in GNOME bugzilla) > > > or auto-detection (for tablet laptops). > > > > …I'm not sure where the best place for this UI would be. It seems that > > it's probably out of scope for the Display panel, but it doesn't seem to > > fit anywhere else in http://live.gnome.org/Design/SystemSettings . > > > > Is this the sort of thing which belongs in the control centre? If not, > > where should it be? > > I'm not sure this is even a problem we'd want to tackle. EDID was first > added to VESA 1.0 in 1994. If hardware manufacturers cannot get it right > after 16 years, there's no hope for them. > Indeed. There's no hope for them. Windows works around this with a combination of the “driver” support and occasionally hardcoding corrected EDIDs in the video drivers, Macs don't need to care because they control the hardware and ensure it's correct. There's also the problem of monitors behind a KVM switch, which is no fault of the monitor's. > And if it's a problem with the video card not handling EDID properly, > then the driver needs to be fixed. This problem is largely gone, and, yes, remaining driver problems should be fixed at the driver level. Some problems we should quirk automatically below the UI - when monitors return known-bad EDIDs and we know the correct values, we should replace that transparently. We currently do this for a small Some problems cannot be automatically handled - monitors which don't supply EDIDs at all, monitors behind a KVM which strip DDC - and these need to be handled *somewhere*. Xorg.conf is not an appropriate level to handle this, as it's static and hence can't really handle monitor hotplug appropriately. With XRandR 1.2 we can handle that appropriately in the desktop environment. This is certainly an edge-case, but it's not an edge-case which is going to go away. > > Something best discussed on the xorg-devel list, and see whether we even > want something like this, or whether it's necessary at all. Most of the infrastructure needed to do this properly is available now - sufficiently advanced users can add modelines via xorg.conf or the xrandr tool - but X isn't the right level to do all of this. Where there's no way to reliably work around the hardware bug there's a policy decision to be made, and that's the responsibility of the DE.
Attachment:
signature.asc
Description: This is a digitally signed message part