Re: Progress Report - Pascal Schoenhardt - XRandR Display Configuration

["Pascal Schoenhardt" <stoanhart gmail com>]

> > - Single Monitor ? Tab greyed out, inaccessible.
> >
> > - Dual-Monitor ? Layout as in screenshots. Clear and concise.
> >
> > - Multi-Monitor ? Entire area becomes a canvas, in which screens can
> > be alligned via drag and drop. A "Identify Screens" button, similar to
> > that in That Other Operating System, will be in the bottom-left
> > corner, which will label the screens.
> >
> > The only problem I see with the above layout is that the "Screens"
> > section, currently under the "Dual Screen Mode" tab, will need to be
> > moved to the "Display Mode" tab since having a canvas in Multi-Monitor
> > mode will not leave any room for that. This isn't really a problem, I
> > think, but it will leave the "Dual Screen Mode" tab a bit bare looking
> > when there are only two screens.
>
> I couldn't judge this from this screenshots but does your dual-screen tab also
> allow me to say: I want my second monitor on the right of my first monitor,
> aligned on the top/bottom/middle.

No, the applet as it stands does not allow you to choose where the
alignment occurs, in the case that the two screens have different
resolutions. I suppose it might just be easier to use a graphical
alignment tool in all cases. It eliminates some code, and adds
consistency...

> > I have also been considering how to handle default resolutions, and
> > getting information on what resolutions are supported by a monitor.
> > EDID information is a good start, but it has several weaknesses. In
> > particular, EDID can not properly represent resolutions that are not
> > 4x3 or 16x9, and there are lots of 16x10 screens out there. Also, EDID
> > doesn't specify what the native resolution of an LCD is. I think a
> > database of monitors and capabilities is in order. However, that type
> > of thing takes a lot of time and effort to create. In this case,
> > however, I think that we can take advantage of the fact that most
> > monitor manufacturers create Windows drivers in the form of .inf files
> > for their screens. These are nothing more than a plain-text file that
> > describes the capabilities of the device.
>
> Doesn't RandR 1.2 provide the needed information? Stated otherwise, should the
> applet really know about this, or should the knowledge to the X server/hal ?

RandR should provide this, yes. It gets its information from EDID, so
I wouldn't need to read that directly. However, it seems to be quite
common to find monitors with incorrect EDID information, or no EDID
information. Another case problem, which was brought up during Keith
Packards demo of RandR1.2 and Akademy, was that the projector mounted
on the ceiling went through some sort of switching panel before it
connected to his laptop. This panel did not pass on the EDID
information. But I suppose in that case, we couldn't determine the
make/model of the display anyways, so having a database built up from
inf files would be quite useless...