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

[Keith Packard]

Andy Ritger <aritger at nvidia.com> writes:

> Keith, did you mean to say "driver" or "X server"?

Well, I meant to say 'driver', but I can see reasons for wanting to at
least have some code in hw/xfree86/modes that could help out. In any
case, definitely within the X server, but beyond that I'd say we should
make as much code common as possible.

> The case of connectors sharing DP lanes seems like a hardware-specific
> constraint best arbitrated within the hardware's driver.  But these tiled
> monitors requiring multiple CRTCs+outputs doesn't seem hardware-specific,
> so arguably doesn't belong in a hardware-specific driver.  At the least,
> it would be unfortunate if each driver chose to solve this configuration
> differently.

Right, which is where a helper function might be a better solution, in
case the driver did want to do things differently.

> But, even if we hide the two tiles within the X server, rather than
> within drivers, there would be behavioral quirks.  E.g.,
>
> * The EDID of each tile indicates the modetimings for that tile (as well
>   as the physical position of the tile within the whole monitor).  When we
>   provide the EDID to RandR clients through the EDID output property,
>   which tile's EDID should we provide?  Or should we construct a fake
>   EDID that describes the combined resolution?  Maybe in practice no
>   RandR clients care about this information.

Interesting. Sounds like we have three choices:

 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 :-)

> * How should hotplug of the monitor's second tile be handled by the
>   server if it is hiding the two tiles?  Should such a hotplug generate
>   a connected event to RandR clients?  Maybe a hotplug on either tile
>   gets reported as a connect event on the one API-facing output.

Presumably you'd only want to report 'connected' if both wires were
hooked up? Otherwise, the monitor isn't really useful.

> Also, there are a variety of other scenarios where one large virtual
> monitor has multiple tiles of input: powerwalls, multi-projector
> setups, etc.  In these cases, users already complain about windows
> getting maximized to only one output, or fullscreen applications only
> setting a mode on one of the outputs.

Which is why we must synthesize a single output.

> Those installations are admittedly niche and generally have savvy
> administrators who can beat a configuration into submission, while the
> tiled 4k monitors are coming to the average user.  Still, it seems like
> both tiled 4k monitors and powerwalls present the same general problem,
> so it would be nice if we can solve them with one general solution.
>
> I think I lean slightly towards trying to handle this client-side.

I don't see how this will work as we have multiple RandR bindings now,
and one (XCB) is explicitly very low-level. We'd have to interpose a new
library into the system and convert all applications to using that. I
think it'd be a whole lot easier to do this in the X server.

> It seems like that information could be conveyed through Aaron's
> OutputGroup idea.  Maybe that is too much detail for clients, but
> maybe we could have a client-side library (either added to libXrandr
> or something new) that can abstract the details from clients who prefer
> to use that than to have full flexibility themselves.

Much as core clients can't see multiple RandR outputs today, and instead
use the screen geometry directly, I think we have to make existing RandR
aware applications "work" reasonably with the current protocol, which
means synthesizing a large output out of multiple smaller outputs. If
you want to *also* extend the RandR protocol so that smarter clients can
drill through that large output and see the individual monitors, that
sounds like a separable problem.

> Granted, clients would probably hate this idea...

And, if clients hate it, they'll drag their feet and you won't get
anything usable until the 2-wire monitors go away. It's not a terrible
plan at that :-)

-- 
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/ad120ac3/attachment.pgp>