RandR 1.3 additions?

[Soeren Sandmann]

Kevin DeKorte <kdekorte at gmail.com> writes:

> Alex Deucher wrote:
> > On Jan 22, 2008 11:48 AM, Keith Packard <keithp at keithp.com> wrote:
> >> On Tue, 2008-01-22 at 09:54 -0500, Alex Deucher wrote:
> >>
> >>> For one, most users don't even
> >>> seem to know that output properties exist.
> >> That's a UI issue; the xrandr CLI app isn't supposed to be the end-state
> >> of design in this space...
> > 
> > heh... if anyone ever writes one ;)
> > 
> 
> I'm currently maintaining the grandr_applet (gnome applet for selecting
> the xrandr mode).

FWIW, I am writing a randr configuration panel for gnome. Feel free to
look at 

        http://www.gnome.org/~ssp/randr/

for what I have so far. It can be checked out as a git repository:

        http://www.gnome.org/~ssp/randr/.git

In particular, you might want to look at randrwrap.[ch] which is a
wrapper around Xrandr 1.2 that uses the glib mainloop to deal with
event etc. behind the scenes.

> 2. A way to get the device name of the display, if there is one, based
> on the output it is connected to.

At the moment you can get the EDID information, modulo driver bugs,
and you have to parse it yourself.

Here are some properties that would be useful:

Vendor Code: A property that contains the three-letter vendor code for
   the display, such as SNY for Sony and DEL for Dell. 

   The client should probably be responsible for translating that into
   something user displayable.

Product Id and Serial Number: Together with the vendor code they allow
   clients to identify a monitor uniquely.

Physical Size: This is already available, I think, but I think I have
   sometimes seen conflicting data from EDID vs. the existing
   properties. 

These are the ones I'll need in the near future, and it should be
relatively uncontroversial to standardize them.

It might be nice to get this information in a way that doesn't require
EDID, but as far as I am concerned this is not a huge deal. 

> 3. A listing of the modes that an output supports.

This is already possible.

> 4. A way to tell if the mode is scaled or not.

Outputs expose "preferred modes", so you can usually know what the
native resolution is.

> And then documentation on how to use it all.

The best documentation I have found is the randr protocol spec:

http://gitweb.freedesktop.org/?p=users/keithp/randrproto.git;a=blob_plain;h=f0ec5e1326565e7008056159249df2329eab1156;f=randrproto.txt




Soren