[Intel-gfx] [PATCH 1/2] drm/i915: Detect SDVO-RGB before SDVO TV
Fu Michael
michael_fu at linux.intel.com
Tue Feb 2 01:19:32 CET 2010
Zhenyu Wang wrote:
> On 2010.01.30 09:38:16 +0800, Fu Michael wrote:
>
>>> 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.
>>>
>>>
>> actually it's not the code but the card in this case.
>>
>>
>
> well, we need to fix our code to work with that SDVO behaivor..
>
>
>> 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.
>>
>
> In my origin patch for UMS on multifunction SDVO support, SDVO connector
> info is updated in output detect and output name for randr is given massage
> to adjust for real output type. For SDVO KMS, we should split encoder/connector
> state based on device capability, and detect would check if connector type
> matches.
>
>
btw, maybe you are talking about another issue that yakui has been
working on, but this issue we talk about here has nothing to do with
wether we should use multiple connector or rename an output - This card
_only_ have VGA connector from external, no way to switch to its TV
capability. The motherboard design never intend to use the TV capability
at all. Would using multiple connector or rename an output or not isn't
the core of the issue. It is the non-existing TV connector is reported
as connected bothering us...
>> 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.
>>
>>
>
> UMS is fine with that as my note above. I think we do have a littlefall
> motherboard which has multi-function sdvo, that I used for SDVO TV enabling before.
>
>
>
>> 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...
>>
>
> yeah, old platform usually won't have finally correct BIOS update.
>
>
More information about the Intel-gfx
mailing list