Re: gtk+ and randr

["Maarten Maathuis" <madman2003 gmail com>]

On Fri, Jul 25, 2008 at 11:10 PM, Soeren Sandmann <sandmann daimi au dk> wrote:
> Adam Jackson <ajax nwnk net> writes:
>
>> On Wed, 2008-07-23 at 12:12 -0400, Matthias Clasen wrote:
>> > On Wed, 2008-07-23 at 11:12 -0400, Adam Jackson wrote:
>> > > I hacked up a proof-of-concept addition to the protocol along these
>> > > lines:
>> > >
>> > > http://people.freedesktop.org/~ajax/patches/randrproto-1.3.patch
>> > >
>> > > I'm not completely happy with it, but it's at least a starting point.
>> > > What API _do_ you want?
>> > >
>> > > (GetScreenResources is clearly an example of generalizing from too few
>> > > examples.  Let this be a lesson to you.
>> >
>> > Looks pretty good to me. It'll get us (almost) all the information we
>> > want. The one thing that GTK+ exposes, which is missing is per-monitor
>> > dpi, but we'll survive without it...
>>
>> After a hallway conversation with Matthias I want to amend this proposal
>> slightly.
>
> If EDID information can not be had without blinking, then flicker free
> boot and login is incompatible with multi-screen support that keys off
> EDID support. Which of these features should not be implemented, in
> your opinion?
>
> If EDID information *can* be had without blinking, then
> GetScreenResources is fine as is, and the randr and the drivers just
> need to be fixed along the lines Dave suggested.
>
>> Feedback definitely sought here.  And I'd send this on to the qt list
>> too, if I had any idea what it was called...
>
> There are qt-interest, and kde-devel.
> _______________________________________________
> xorg mailing list
> xorg lists freedesktop org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>

EDID gathering doesn't cause blinking, it's the connection checking
that causes blinking.

The most reliable way to check connection (given sufficiently modern
hardware) is to check hotplug pins (which are available on all modern
connectors as far as i know) and run load detect. This combined
information will tell you what is connected, even on DVI-I (or alike)
connectors, regardless of how good, bad or broken the edid is. But at
that stage analog connections have blinked. Some might say that using
the edid to determine connection and connection type is a the best
approach, but that puts responsibility with the monitor. It's
therefore not preferred.

In an ideal world the connection state checking would be seperated
from edid retrieval. This however does not imply that retrieving edid
is cheap. It is however possible to cache edid's in such a scheme.

Note that this is (obviously) my opinion, and does not neccesarily
conform to the majority opinion.

Maarten.