How to report DVI/HDMI support to Xrandr?

[Endejan, Edward]

> On Monday, March 10, 2008 9:21 AM, Matthias Hopf wrote:
> On Mar 07, 08 12:03:18 -0500, Endejan, Edward wrote:
> > The driver I'm working on is now able to distinguish between an
attached
> > display with HDMI support versus one with only DVI support (no
audio) by
> > reading and parsing the second 128 bytes of the display's EDID
> > (Extension Block 1). My question is how to best report this
information
> > through Xrandr.
> >
> > I've searched quite a bit through the archives and have found some
> > discussion about Output Properties being used to describe
CONNECTOR_TYPE
> > = { ... HDMI, DVI-A, DVI-D, ...} or SIGNALLING_LEVEL = {... TMDS,
LVDS,
> > ...} but I don't think either of these work for this use case.
Either
> 
> Though I think it would work. In my notion RANDR_SIGNAL_FORMAT would
be
> non-static, so the driver could change this to TMDS-DVI or TMDS-HDMI
> accordingly. AFAICS there *are* some differences in the signal, like
> Audio being present, or maximum link bandwidth (TMDS-HDMI-13: 340MHz),
> and 10/12/16 bit xvYCC video.
> 
> Do you think this would suffice?
> 

I see what you mean, and I think that could work for my purposes, but I
think it depends on what that property is called. If it is
SIGNALLING_LEVEL as I had seen proposed, the level doesn't differ
between DVI and HDMI, they are both TMDS. If it is called SIGNAL_FORMAT
as you suggest, then TMDS-DVI, TMDS-HDMI, and TMDS-HDMI-13 make sense to
me.

> > data. I still think that an Output Property would be a good method
to
> > report this information though, so I'm proposing to create a new
Output
> > Property called HDMI_AUDIO which would be set to TRUE when that
> > functionality is supported. Are there any objections to this
approach?
> 
> Hm. Sounds reasonable.

Other properties such as COLOR_DEPTH and COLOR_SPACE could be used with
this approach to cover the other attributes you mentioned. Either way
will work for me. Anyone else have a preference of which approach to
use?

> 
> > A separate issue is that some output properties (e.g EDID) that I
> > believe have been set by the driver do not seem to be getting
through to
> > the other side and are not displayed when I use the --properties or
> > --verbose options on the command line with xrandr. Is it possible
that I
> 
> It does work for the radeonhd driver in my environment, so in
principle
> the mechanisms work.
> 

I've seen it work as well on a desktop running Fedora Core 8, but I'm
still struggling with getting it to work on my target system (VIA
EPIA-EX15000G).

Ed