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

[Alexander E. Patrakov]

Aaron Plattner wrote:
> So, monitor manufacturers are starting to make high-resolution displays that
> consist of one LCD panel that appears to the PC as two.  The one I've got
> is a Dell UP2414Q.  It shows up to the PC as two DisplayPort 1.2
> multistream devices that have the same GUID but different EDIDs.  There's
> an extension block in the EDID that's supposed to indicate which side is
> the left tile and which is the right, though I haven't tried to decode it
> yet.

<off-topic>
Thanks for disclosing the exact model information
</off-topic>

> The problem, obviously, is that applications (including some games) treat
> the two tiles as if they were completely separate monitors.  Windows
> maximize to only half of the screen.  My question is, how do we want to
> deal with these monitors?
> 
> As far as I see it, we have four options:
> 
>  1. Hide the presence of the second tile in the X server.
> 
>     Somehow combine the two tiles into a single logical output at the RandR
>     protocol level.  The X server would be responsible for setting up the
> right configuration to drive the logical output using the correct physical
> resources.
> 
>  2. Hide the presence of the second tile in libXrandr.
> 
>     This would allow interested applications to query the real state of the
>     hardware while also making it easier to do modesets on a per-monitor
> level rather than per-output.
> 
>     This could be exposed either as a new "simple" modeset API in libXrandr
> or similar, or by modifying the existing interface and having a new
> interface to punch through the façade and get at the real configuration,
> for clients that care.
> 
>  3. Update every application that uses RandR 1.2.
> 
>     Applications can detect the presence of these monitors and deal with
> them themselves, but this might have poor adoption because programmers are
> a lazy bunch in general.
> 
>  4. Do nothing and hope the problem goes away.
> 
>     Hopefully, the situation with current 4k monitors is temporary and we'll
> start seeing single-tile 4k displays soon, fixing the problem "forever".
> Until we get 8k tiled displays.
> 
> If the real output devices are still exposed through the protocol, it might
> make sense to add new properties describing their relative positions to
> make it easier for clients to lay them out in the right order.  This might
> be useful for power-walls too.

Disclaimer: I am just a user, not a developer of anything related to graphics.

Based on the above, I think that the following summarizes the requirements:

1. Games must think that there is a single 4k screen they can maximize to. Key 
idea: mirrors would work, too!

2. Information that there are two CRTCs consumed should be also available to 
the clients.

3. There must be a way to configure several existing frameless displays as a 
single power wall, i.e. erase boundaries between them.

4. The X server must erase boundaries automatically for devices that only 
pretend to consist of two or more parts.

So my proposal would be to add a new request that marks some existing outputs 
as a power wall. As a result of this request, the list of modes they support 
should be replaced with one single fixed mode - that of the resulting power 
wall, and boundaries should be erased. For compatibility with the existing 
applications, all these outputs should pretend that they are mirrors of each 
other (and indeed it currently makes sense to run a game on mirrored 
displays). Relative positions of outputs inside the power wall should not be 
available through xrandr 1.2 protocol. Attempts to set them to anything else 
than mirrors should fail.

So here is some mockup of the resulting xrandr output:

Screen 0: minimum 3840x2160, current 3840x2160, maximum 8192 x 8192
DP1 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 509mm x 
286mm
   3840x2160     60.0*+
DP2 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 509mm x 
286mm
   3840x2160     60.0*+

even though each half is in fact 1920x2160.

-- 
Alexander E. Patrakov