gtk+ and randr

Maarten Maathuis madman2003 at gmail.com
Tue Jul 22 16:47:21 PDT 2008


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?

>
> Dave.
>



More information about the xorg mailing list