On Sun, Dec 31, 2017 at 08:29:45PM +0100 I heard the voice of Max, and lo! it spake thus: > > As promised a long time ago :), I made a POC of xrandr use:
Sweet! I haven't had a chance (and I wouldn't count in the near future) to look at it in detail, but here's a few thoughts anyway. > As a remainder, the goal is to allow ctwm to work correctly in > "xinerama" mode with multiple monitors using different sizes. To clarify (as I assume I'm thinking right); that's the realm of peaking XRandR to understand the layout of displays and the available screen area, *not* the case of XRnR making dynamic changes to it during runtime (that being a whole different keg of black powder). > 1. the following functions should take into account the new layout > mechanism: > + bottomzoom = hbzoom [...] > > 2. new "zoom" functions to operate on the current monitor only, > instead of the WHOLE screen > + monitorfullscreenzoom [...] My immediate thought would be to go the other way; have the existing functions fill out the current display, and have new functions to expand across displays. e.g., if I've got mplayer on one display running an important instructional video (and totally not a MST3k back-episode or something) and I hit 'f' to full-screen it, I'd expect it to fill out that display, not cover up the important work (and totally not random flamefesting) I'm doing on the other display. Possibly my expectations are skewed? A second thing is that, at a glance, it seems like you're currently making XRandR a hard dependancy and replacing the old Xinerama bits with it. We should ask and answer the question about what that does to our support. A glance at the release history summary suggests you probably wouldn't be requiring anything newer than RandR 1.3, and further minor digging suggests that's X.org server 1.6 (early 2009) and randr libraries of the same era. A little poking at the obvious suspect for current-OS-with-old-packages suggests that keeps us in the good graces of RHEL/CentOS 6, but perhaps not 5. We may also lose whatever (if any) we still have of older proprietary unices or non-X.org servers. That doesn't seem facially out of the question. That's a similar vintage to things like standard-XCB and Xft2 and the like, which are on my list to consider pushing toward. Just that it's a thing that we do need to explicitly consider and intentionally decide. -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
