gtk+ and randr

[Dave Airlie]

On Wed, Jul 23, 2008 at 9:47 AM, Maarten Maathuis <madman2003 at gmail.com> wrote:
> On Wed, Jul 23, 2008 at 1:26 AM, Dave Airlie <airlied at gmail.com> wrote:
>> On Wed, Jul 23, 2008 at 8:45 AM, Maarten Maathuis <madman2003 at gmail.com> wrote:
>>> On Tue, Jul 22, 2008 at 11:24 PM, Dave Airlie <airlied at gmail.com> wrote:
>>>> On Wed, Jul 23, 2008 at 7:19 AM, Maarten Maathuis <madman2003 at gmail.com> wrote:
>>>>> On Tue, Jul 22, 2008 at 11:04 PM, Dave Airlie <airlied at gmail.com> wrote:
>>>>>> On Wed, Jul 23, 2008 at 3:19 AM, Alex Deucher <alexdeucher at gmail.com> wrote:
>>>>>>> On Tue, Jul 22, 2008 at 12:38 PM, Eric Piel <E.A.B.Piel at tudelft.nl> wrote:
>>>>>>>> Alex Deucher schreef:
>>>>>>>>>
>>>>>>>>> On Tue, Jul 22, 2008 at 4:18 AM, Eric Piel <E.A.B.Piel at tudelft.nl> wrote:
>>>>>>>>>>
>>>>>>>>>> Alex Deucher schreef:
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 21, 2008 at 6:39 PM, Ben Gamari <ben at mw0.ath.cx> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Intel hardware it seems to probe the outputs and re-acquire EDID
>>>>>>>>>>>> information, which in itself seems to usually cause loss of sync. It
>>>>>>>>>>>> seems this is what XRRGetScreenResources() is supposed to do so I
>>>>>>>>>>>> really
>>>>>>>>>>>> don't see any way to avoid the cost.
>>>>>>>>>>>
>>>>>>>>>>> If you have monitors with EDIDs plugged into your connectors, then
>>>>>>>>>>> you're fine.  if you have nothing on one or more connectors or a
>>>>>>>>>>> monitor without an EDID, you may get flickering as the driver attempts
>>>>>>>>>>> to use load detection to sense the presence of a monitor since there
>>>>>>>>>>> is no EDID.
>>>>>>>>>>
>>>>>>>>>> With my i965 and a monitor _with_ EDID connected to the VGA output, I do
>>>>>>>>>> get
>>>>>>>>>> flickering (the screen turns black for one second). So, it seems the
>>>>>>>>>> flickering happens all the time. Is it a bug in the intel driver? Or
>>>>>>>>>> maybe
>>>>>>>>>> it's because there is also a TV output? (that would be nasty because the
>>>>>>>>>> laptop don't even have the plug!)
>>>>>>>>>
>>>>>>>>> TV is load detection only, so it's probably the tv port.  I suspect
>>>>>>>>> your laptop needs a quirk to ignore the tv connector.
>>>>>>>>
>>>>>>>> Oh well, I've doubled checked, and if you buy the "media station" for my
>>>>>>>> laptop, the tv connector is available. So it's better not to disable it
>>>>>>>> completely!
>>>>>>>>
>>>>>>>> Still, isn't it strange that the fact there is a "load detection" on the TV
>>>>>>>> output affects the VGA output?
>>>>>>>
>>>>>>> No, load detection requires a crtc as you need to send a signal to the
>>>>>>> tv dac to check the load.  So what happens is the crtc that's
>>>>>>> currently driving one of the other outputs is borrowed temporarily to
>>>>>>> do the load detection, hence the flicker.
>>>>>>>
>>>>>>
>>>>>> I've been thinking about this and I think we should change the
>>>>>> detection ordering.
>>>>>>
>>>>>> Instead of just going through the outputs one by one we should go
>>>>>> through the outputs that
>>>>>> were connected the last time we checked first. So if for example on
>>>>>> radeon we have a shared DAC,
>>>>>> we can see the VGA is still connected to it, and not bother with TV
>>>>>> load detection. This should remove
>>>>>> some of the flickering cases we see today on radeon.. On intel if we
>>>>>> can't get a crtc we shouldn't bother load detecting
>>>>>> instead of stealing a crtc from an active output.
>>>>>
>>>>> This is very device dependent, and randr-1.2 has "no idea" of all
>>>>> this. For modesetting-101 a fill_all_modes function could do the trick
>>>>> and something similar could also be done for randr-1.2. It all boils
>>>>> down to handing more control to the driver. Maybe randr-1.3 could also
>>>>> replace other functions with stuff a la set_mode_major.
>>>>>
>>>>
>>>> With randr-1.2 my scheme would work fine, just do the detects in order
>>>> of what was connected previously.
>>>> Then if the VGA turns out to be now disconnected, then the TV detect
>>>> can know it can use the DAC to detect.
>>>
>>> But how do you know dac sharing occurs? How do you know you need a
>>> crtc for load detect or not?
>>>
>>>>
>>
>> Because the driver knows, so when I get a detect request for a
>> previously disconnected TV out,
>> if the DAC is already in use which I should be able to know by
>> checking if the other user is connected,
>> then I don't do load detect for the TV out at that time. Also for the
>> intel case if there is no free crtc when I get
>> to tv-out detect I don't do tv-out detect.
>>
>> The big difference here is that changing the search order means the
>> driver can know that the shared dac or crtc
>> is actually in use as opposed to maybe in use which its gets with the
>> current ordering.
>
> And the driver is supposed to know when it's doing a sequence, or will
> there be a flag of some kind? If not, how long before this cache
> should invalidated?

What cache?

I think you missed something... randr always calls the output detects
in order, from xf86ProbeOutputModes.
The detect for the shared output just need to know that the info for
the output it shares with is correct, so
it makes sense to check the previously connected outputs first to
update their state before calling the previously
disconnected outputs.

You are over complicating this in some way.

Dave.