Some considerations about RANDR Monitors

[Giuseppe Bilotta]

Hello,

I noticed is that for 'tracking' Monitors, the pixel information
follows the rotation, but the physical size does not. I'm assuming
this is intentional, as it fits what is mentioned in randrproto (which
was however written before the Monitor type was introduced).

> To avoid multiplicative explosion between orientation, reflection and sizes,
> the sizes are only those sizes in the normal (0) rotation.

When constructing the geometry automatically, the randr/rrmonitor.c
code is also very explicit about this: it iterates over all CRTCs,
gets the mm size of the first output without considering rotation,
expands the pixel bounding box with all other outputs, and finally
sets the physical size of the monitor in order to preserve the DPI of
the first output.

While this works reasonably well for what was the intended “normal”
use of Monitors (joining up the multiple outputs of high-resolution
monitors that use MST), it has two issues.

The first issue is that, since the Monitor has no rotation
information, the user needs to do two extra roundtrips to fetch the
relevant information (one to fetch the output info for one of the
outputs of the monitor info, and a second one to fetch the CRTC info
for the output).

The second issue is that this approach doesn't work, neither client
nor server side, when the user joins outputs whose CRTCs have
different rotation values. One may consider such a configuration
unsupported, but it's actually rather reasonable. Consider for example
a user that has two displays with the same (or similar) DPI, one
rotated and one in normal orientation. If they are joined in a single
Monitor with automatic sizing, the final reported size will actually
depend on the enumeration order, and if the rotated one is enumerated
first, the results will be completely bogus, even though in the other
case they would actually be “correct” (or at the very least much more
reasonable).

A possible approach in this case would be to consider the rotation for
the first CRTC when getting the initial physical size. One could then
swap mmwidth and mmheight at the end if this swap was done initially.
This would actually be consistent with the current behavior.

I would actually prefer keeping the sizes swapped, to avoid the two
extra roundtrips needed client-side, but of course, this would mean
that different values would be reported, and this would break current
clients (are there any actually using the information?)

Any remarks? (I can implement the double-swap approach if deemed appropriate).

By the way, I noticed here a bit of a discrepancy in randrproto. The
MONITORINFO type is defined as having an outputs field which maps to a
LISTofOUTPUTS (section 5.6). However, the wire protocol documentation
(section A.1.1) actually mentions CRTCs. I found this rather
confusing. I looked through the xserver source code, and it seems it's
RROutputs that get sent, but in at least one place,
randr/rrmonitor.c:95 in RRMonitorSetFromServer, the code reads

    monitor->outputs = calloc(crtc->numOutputs, sizeof(RRCrtc));

I'm assuming that the mention (and use) of CRTCs is in error, so I'll
try to provide patches for this. Also, xrandr has monitors support,
but it's not in the man page that I can see, I'll see if I can do
something about this too.

Also related, would a patch adding to xrandr the possibility to apply
output changes to all outputs of a monitor make sense? Either with a
specific --monitor <name> flag, or by accepting a monitor name
wherever an output name is accepted?


-- 
Giuseppe "Oblomov" Bilotta