Re: Multiple monitors, VirtualScreens and/or Xrandr

Hi all,

Episode III:

* Correction of very old bug when using BorderSize>0 and no 3D borders: 
https://github.com/maxatome/ctwm-mirror/commit/ec40a4b9f07b21f90562b7731efceb3a6fecdf6d
   As I note in commit message, I think the bw parameter of 
MoveOutline() should always be 0 (at least for BorderSize>0 and no 3D 
borders);

* XRandr support can be disabled at compile time use USE_XRANDR15=OFF 
(default to ON);

* fill "right|left|top|bottom", pack "right|left|top|bottom" and jump* 
functions now detect inter-monitors edges;

Remaining things:

* rename current *zoom functions (which operate across several monitors) 
to <prefix>*zoom, <prefix> to be defined, some ideas? :)

* modify *zoom functions to operate on current monitor only;

* untouched: finish the inventory of Scr->root* uses (43% done) to know 
if they need to be switched to layout mechanism or not.

https://github.com/maxatome/ctwm-mirror/tree/xrandr

++

Max.

On 04.01.2018 12:49, Max wrote:
> Le 04/01/2018 à 09:20, Matthew D. Fuller a écrit :
>> On Sun, Dec 31, 2017 at 08:29:45PM +0100 I heard the voice of
>> Max, and lo! it spake thus:
>> [snip]
>>> 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).
> Yes, you're right. Dynamic layout changes could be handled later. As
> ctwm restart is fast, it can be used when the layout (monitor
> add/remove) changes.
>
>>> 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?
> It can be done your way.
> I wouldn't change too much the actual behavior that zooms over all
> monitors, but I agree with your point of view. I can adapt very easily,
> what name/prefix do you suggest to operate on several monitors instead
> of current one?
>
>> 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.
> The only RandR function used is XRRGetMonitors() which needs RandR 1.5,
> so 1.3 does not match.
>
> I can make Xrandr_LIB completely optional, with the help of a new
> USE_XRANDR15 parameter (as USE_EWMH does for EWMH.)
> In case this parameter is not defined, the layout will reflect the
> old-big-screen instead of the precise monitors one without any change
> elsewhere. It's a very small change located in this function:
> https://github.com/maxatome/ctwm-mirror/blob/xrandr/xrandr.c#L14 (+
> handling of USE_XRANDR15 of course.)
>
>> 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.
> It's up to you :)
>
> Regards,
>
> Max.