How to report DVI/HDMI support to Xrandr?

[Endejan, Edward]

> From: Adam Jackson [mailto:ajackson at redhat.com]
> Sent: Friday, March 07, 2008 3:56 PM
> To: Endejan, Edward
> Cc: xorg at lists.freedesktop.org
> Subject: Re: How to report DVI/HDMI support to Xrandr?
> 
> On Fri, 2008-03-07 at 12:03 -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
> > HDMI or DVI connector types can be converted to the other type
through
> > an adapter or cable, so it seems that just describing the physical
> > connector type which is present is not enough. Both HDMI and DVI use
> > TMDS signaling, but HDMI can interleave audio data along with the
video
> > 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?
> > Is there a better way or has this already been implemented in a
> > different way?
> 
> Why don't you just report the whole EDID block?  We already have
clients
> parsing it, they might as well grow knowledge of the extensions.
> 
> - ajax
I agree that the EDID Extension Block could be useful for other purposes
and so I was planning to report it as a separate 128 byte block so that
any code which is already parsing the initial 128 bytes does not get
confused. But I also thought it made sense to do some level of parsing
and report back the properties I discovered so that every client doesn't
have to duplicate that effort. The Extension Block is not a fixed
structure like the first block is, so parsing it is a bit more involved
than looking for fixed offsets.

I'm still stuck with the problem that _none_ of the properties are
coming through, so I have to solve that regardless of what properties I
decide to report.

- Ed