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 _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel