How do we want to deal with 4k tiled displays?

[Keith Packard]

"Alexander E. Patrakov" <patrakov at gmail.com> writes:

> What would be the case where the driver would want to do things
> differently?

It's always nice to provide the option?

>>  1) Report both EDIDs, presumably using some new convention
>>  2) Construct a fake unified EDID
>>  3) Don't report EDID at all
>>
>> Obviously 3) is the easiest :-)
>
> (3) breaks color managers, because they rely upon the EDID to
> associate color profiles with outputs.

Yeah, it's sub-optimal. 

> What's wrong with my proposal to report "mirrored screens" to clients
> even though the outputs are not really mirrors? In this case, each
> mirror can get one EDID, implementing option (1).

We'd have to report both at the full resolution so that applications
would maximize correctly; I don't see how this really helps here, other
than potentially confusing applications. It leaves the EDID problem
unsolved (you don't have an EDID which reflects the unified display),
and it may well confuse applications into thinking that they can
configure the two "monitors" separately.

> In the pathological sitiation when only one wire is hooked up, I guess
> that the monitor is still usable at its original size and aspect
> ratio, just not at full resolution. Someone has to verify this. If
> this is so, then "unplug one 1920x1080 monitors, plug two mirrored 4K
> monitors" sounds more appropriate. Or, if the fact that the other half
> exists is detectable from EDID, we can indeed not support single-wire
> operation.

I'd love to know if this works, in which case we really can mostly
ignore the problem. Of course, as you plug in the cables, you're going
to see a bunch of mode flipping.

Oh, I can imagine advertising the dual-wire setup as a separate output?
Would that be helpful at all?

> +1, but I repeat that mirrors would work here, too, and nicely account
> for busy CRTCs.

Yeah, that's a benefit. I still think the potential for confusing other
applications is higher with mirroring though.

> +1 to "separate problem". Indeed, there is one problem of making
> existing applications work without changing the protocol, and one
> problem of extending the protocol so that interested clients can learn
> about combined displays or make power walls on the fly.

We used to just have N outputs to 1 CRTC; it looks like we've got
N outputs to M CRTCs...

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140122/e89195f3/attachment.pgp>