Andy Ritger <[email protected]> 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 :-) -- [email protected]
pgp2EVBvu9liR.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
