Re: questions and sundry gripes about X11 multihead (it's a rant)

Brent Busby posted on Sun, 29 Dec 2013 23:51:03 -0600 as excerpted:

> RandR (and its predecessor, Xinerama) both assume though that if you're
> doing multihead, you want one big screen that spans multiple monitors.
> Nice if that's what you want, but as detailed above, there are good
> reasons why you might prefer otherwise.  For example, on my system, I
> have a landscape mode main monitor, and a secondary monitor rotated
> sideways (portrait mode) to the left of it.  That means that if I were
> to adopt some kind of RandR/Xinerama type spanned desktop, I'd have a
> choice:  I could have a desktop that's shaped like some kind of "L", or
> a desktop that's shaped like a sideways "T".  I don't think I really
> like either of those very much.  It's very weird, and many of my apps
> will probably think so too, especially when I try to fullscreen their
> windows.  Instead of desktops shaped like alphabet soup, why not have
> separate logical screens?
>  I don't mind that I can't move windows between them.  I don't want the
> desktops to know about eachother anyway. It's simpler that way.
> 
> There are Xinerama "hints" that apps which support Xinerama are supposed
> to use to help with this, which I think RandR is supposed to respect.
> The problem with this is the same as the problem with Wayland's
> expectation that clients will take care of their own network
> transparency needs:  As soon as you leave it to the individual programs,
> you will have varying levels of support in each one.  Some will be
> paragons of good behavior, others will be useless.  You can only make a
> feature truly available to all when it's provided as an OS feature.
> There will still be programs that misbehave, but they'll have to try
> much harder at it.

FWIW, while I think if you want zaphod mode you should be able to have it 
and thus don't want to take away from your rant, as a user running triple-
head randr (3 by full-hd-1920x1080, "stacked" configuration for 1920x3240 
total desktop size) here, the down sides aren't /quite/ as bad as you 
make them out to be.

Plus, there's a couple other alternatives too, which you haven't 
mentioned.


First to address randr.  I believe a lot there depends upon the 
flexibility and configurability of your window manager.  I qualify the 
claim with "I believe", because I've not run anything but kwin for quite 
some time, so I actually don't know how flexible/configurable other WMs 
are, but what I DO know is how well kwin works for me in this regard. =:^)

(But don't get the impression that I'm a full kde guy.  While I do still 
run kde as my general DE, I run a quite cut down kde here, including
USE=-semantic-desktop, and having switched to non-kde apps for pretty 
much everything critical but kwin and the desktop itself.  I run the gtk2 
based firefox as browser, gtk2 claws-mail as mail client and with its 
feed plugin for feeds, gtk2 pan as my nntp/news client, non-kde media 
players such as vlc (using its default qt4 interface), smplayer (qt4), 
and mpd with various front-ends (cli/ncurses/qt4).  If the switch to kde 
frameworks 5 with qt5 is anything like the kde4 upgrade, they'll probably 
lose me for the desktop too, but so far signs are good that they've seen 
some sense and don't intend to go thru /that/ again.)

So anyway, at least kwin can be configured to see the entire desktop as a 
single "screen" (USE=-xinerama for qt-gui), or to treat each one 
separately (USE=xinerama).  When kwin is in separate screens mode, which 
is what I use, full-screen and maximizing work to just the single randr 
monitor (formerly xinerama/X screen) and the default smart-window-
placement can be set to either put windows on the "active" screen as 
defined by where the mouse pointer is, or as defined by the parent or 
active window.  (I use pointer-active since it allows me to for instance  
click a link and quickly point at a different monitor if I want firefox 
to open there instead.)

For windows that don't behave to my liking, kwin has window rules which 
allow setting all sorts of exceptions.  I normally want my browser and 
konsole windows set half-maximized, for instance, maximized (to monitor) 
vertically, but half-max horizontally (on a full-HD 1920x1080 9:16 ratio 
widescreen, so 960x1080), so I can open two side-by-side.  Window rules 
allow me to enforce this.

There's an old DOS-based game (Master of Orion, original, now 20 years 
old... and the only non-freedomware app I still run) I run in dosbox, 
that I have set very specifically not only to size, but to position, so 
it always opens up in the same place on the same monitor, basically so 
the game is full monitor height, but not full monitor width as that would 
distort it.  I also have that particular window set to no-border since 
that would only be a distraction, but it's also possible to keep the 
title bar but force position and size such that only the titlebar appears 
on one screen, while the game in the client window appears vertically 
maximized in the screen below, and sometimes when I'm tweaking things, 
I'll switch it to that mode so I can see the parameters dosbox puts in 
the titlebar, without losing the full-height game display.

For other windows, including claws-mail (for mail and feeds) and pan (for 
nntp/news), I force horizontally maximized (to screen), while forcing 
them basically titlebar height shorter than vertically maximized.  I then 
force the position to the bottom of the screen such that there's just 
titlebar height available above them, so I can have the half-width full-
height browser, console or reply windows open and can easily switch 
between them with just a pointer movement (focus follows mouse, click-to-
raise, window transparency set so I can type in the active but second-
down window while referring to content in the window above it).  See the 
screenshot link, which illustrates this:

(Slightly NSFW warning, the firefox skin is a Sports Illustrated swimsuit 
model.  Bikini, but sensitive types may wish to avoid.)

http://wstaw.org/m/2013/05/11/duncan-fullscreen.png

If a window /still/ insists on ignoring the window-rule settings, as some 
that think they know better than the window manager where they should go 
and what their size constraints should be, there's a couple additional 
window rule options to force-ignore those settings too, and I do use that 
for a couple things altho it's rather rare that I actually need it.

Kwin actually has a nice "drag to side" half-maximize (full height, half 
width, or quarter-size, half-size both directions) trick too, as well as 
"drag to top" to maximize.  Of course both features are configurable.  
With a stacked config I find the to-top-maximize more trouble than it's 
worth so that's turned off, and the quarter size drag-to-side area (as 
opposed to half-size) is reduced since I don't have much use for it, but 
I do use the half-maximized functionality quite a bit.

Further, kwin can be configured as a full tiling window manager (hotkey 
tiling operation triggerable) for those that like that, but that's not my 
thing.

So basically what I'm saying is that whatever behavior, both generic and 
specific window, you might want, kwin is generally configurable to do 
exactly that.  And its config files are text-based so you can either use 
the GUI configurator or edit the text files directly, if you prefer.  =:^)


But as I said, if you want fully independent screens aka zaphod mode, I 
think it should be doable.  But given that it seems less and less so, 
what about those other workarounds that I mentioned?

There's two that I know of.  Which one you choose will depend on your 
needs and neither one is exactly like single-X-session zaphod mode as 
both involve multiple X sessions, but with some tweaking, hopefully one 
or the other will do what you want.

1) Xorg can handle multiple X sessions on the same hardware, each using 
its own VT.  This is sometimes referred to as fast-user-switching, 
particularly when it's handled via GUI at the XDM login level, but the 
same thing can be done using CLI login and running startx multiple times, 
as the same user or different users.  I actually do this accidentally on 
occasion if I forget that I already have an X session running, which is 
how I know it works, but a script that sets the XSESSION variable and 
switches out a few other things appropriately would be easily setup.

This lets you switch X sessions just like you do CLI VTs, using CTRL-ALT-
Fx.  Each X session runs on the same physical displays using the same 
input hardware, and you simply switch between them.  Thus, you'd have the 
same multi-monitor combined desktop setup in each one, but each X session 
would be separate and indeed, could be separate users too.  Similarly, 
starting say kde in one and enlightenment in another shouldn't be 
difficult to script.  (Running say two separate sessions of the same 
environment as the same user can be a bit problematic if the environment 
expects only one to be running and the two overwrite each others 
settings, but it's doable in general, as demonstrated by the accidental 
launches I find myself with here, on occasion, and it should be scriptable 
to keep them separate where necessary.)

2) It's also possible to do "multi-seat X", where each "seat" has its own 
entirely separate configuration, each talking to its own graphics card 
with its own displays attached and using its own input hardware, as 
configured.

This would be even more separate than either zaphod mode or multi-session-
multi-VT X, since not only are the X sessions separate, but each is using 
its own hardware display and input devices, as well.

To make this work, there's a kernel option that needs set so the graphics 
instructions get routed to the correct hardware.  Each xorg config would 
then specify the graphics card it was to use as well as the input 
devices, and to start the second one you'd add the appropriate config 
file option when invoking X.

But this might actually be more separation than you want, since switching 
between screens would mean switching keyboards/mice.  Also, I've not 
actually used this mode myself, so while I know a bit about it, the 
practical help I could give you would be a bit more limited.  And of 
course there's the fact that you now have the extra cost for those 
additional devices...

I /think/ it should even be possible using xinput to script logical 
disconnection of input devices from one xsession, and connection to the 
other, thus allowing you to invoke that script with a hotkey, for input 
switching the same input devices to work with multiple sessions.  That 
would limit the extra cost to the additional graphics card and let you 
switch which session and display you were working with via simple hotkey.  
But while I've done some xrandr scripting, I've not done any with xinput 
and don't actually have it installed, so I'm only guessing at what it can 
do in that regard based on previous articles I've read.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman