[Intel-gfx] [PATCH 1/2] drm/i915: Detect SDVO-RGB before SDVO TV

[ykzhao]

On Sat, 2010-01-30 at 09:38 +0800, Fu Michael wrote:
> Eric Anholt wrote:
> > On Wed, 27 Jan 2010 16:32:45 +0800, yakui.zhao at intel.com wrote:
> >   
> >> From: Zhao Yakui <yakui.zhao at intel.com>
> >>
> >> Some VGA/TV dual function SDVO card  with only VGA port incorrectly report all
> >> kinds of its connection as connected when VGA monitor is connected.
> >> This patch workaround it.
> >>
> >> http://bugs.freedesktop.org/show_bug.cgi?id=25787
> >>
> >> Signed-off-by: Zhao Yakui <yakui.zhao at intel.com>
> >>     
> >
> > Why should what order the connectors get set up matter?  If it's supposed
> > to matter, has this been tested in anything other than this guy's
> > particular configuration to make sure that you're not regressing other
> > picky encoders?
> >
> > If I had to take a wild guess, this would be another manifestation of
> > the failure of the SDVO code to have a single encoder instance managing
> > the multiple connectors attached to it, so the different connectors
> > fight over the state of the encoder.

This issue is related with the output device name of multi-function SDVO
card.
1. When it is in UMS mode, the output device name is handled in our
driver. We can rename the name of output device based on the external
connected device. And this is realized by using xorg API function.

2. When it is in KMS mode, the output device name is obtained by using
connector type/id. More than one connector type can be supported on such
multi-function SDVO card. Our driver will initialize one connector
type/id for it. Then when the different external device is attached, we
will use the new connector type based on the external connected device.
But as the connector id is not changed, maybe we will get the conflict
name. At the same time the corresponding output device name can't be
reflected to user.

I also try to change the connector type/id dynamically based on the
external connected device. But this idea is not accepted by the
community. 

>http://lists.freedesktop.org/archives/intel-gfx/2010-January/005603.html

>    
> actually it's not the code but the card in this case.
> 
> we have only one way to know what kind of monitor is attached to a sDVO 
> card, that is to send a command to it and read back response. For the 
> card in this bug report, even though it only has VGA attached. It report 
> all of its capabilities are connected, which apparently is not true. if 
> we just pass that message up to user space, the bogus connection would 
> mess up mode setting then, so technically, this is a patch in UMS that 
> happen worked around it.
> 
> Such kind of multi-function sdvo card is rare. we don't have any, and we 
> only see one bug report from community in our bugzilla as well.  I guess 
> that's why UMS has been living with it fine for a long time.
> 
>  I guess if we want a decent fix for this, maybe our last hope is to see 
> if VBT has any information to tell us not to bother with other type but 
> just one kind of connector on this SDVO device. But I'm not sure if this 
> would break other normal cards then, just in case a VBT is broken...

The device_type field of child device parsed in VBT can indicate the
device type of SDVO card. But the spec defines more than twenty
device-class types for the SDVO card. Do we need to compare the
device-type with the device type list? At the same time I am not sure
whether the spec covers the all possible device type for SDVO-card.

I agree with what Michael said. And if the VBT is broken, maybe it will
break other normal cards.

Thanks.
   Yakui.

> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >   
>