How do we want to deal with 4k tiled displays?
keithp at keithp.com
Wed Jan 22 19:01:20 PST 2014
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
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
Size: 810 bytes
Desc: not available
More information about the xorg-devel