1 |
Brent Busby posted on Sun, 29 Dec 2013 23:51:03 -0600 as excerpted: |
2 |
|
3 |
> RandR (and its predecessor, Xinerama) both assume though that if you're |
4 |
> doing multihead, you want one big screen that spans multiple monitors. |
5 |
> Nice if that's what you want, but as detailed above, there are good |
6 |
> reasons why you might prefer otherwise. For example, on my system, I |
7 |
> have a landscape mode main monitor, and a secondary monitor rotated |
8 |
> sideways (portrait mode) to the left of it. That means that if I were |
9 |
> to adopt some kind of RandR/Xinerama type spanned desktop, I'd have a |
10 |
> choice: I could have a desktop that's shaped like some kind of "L", or |
11 |
> a desktop that's shaped like a sideways "T". I don't think I really |
12 |
> like either of those very much. It's very weird, and many of my apps |
13 |
> will probably think so too, especially when I try to fullscreen their |
14 |
> windows. Instead of desktops shaped like alphabet soup, why not have |
15 |
> separate logical screens? |
16 |
> I don't mind that I can't move windows between them. I don't want the |
17 |
> desktops to know about eachother anyway. It's simpler that way. |
18 |
> |
19 |
> There are Xinerama "hints" that apps which support Xinerama are supposed |
20 |
> to use to help with this, which I think RandR is supposed to respect. |
21 |
> The problem with this is the same as the problem with Wayland's |
22 |
> expectation that clients will take care of their own network |
23 |
> transparency needs: As soon as you leave it to the individual programs, |
24 |
> you will have varying levels of support in each one. Some will be |
25 |
> paragons of good behavior, others will be useless. You can only make a |
26 |
> feature truly available to all when it's provided as an OS feature. |
27 |
> There will still be programs that misbehave, but they'll have to try |
28 |
> much harder at it. |
29 |
|
30 |
FWIW, while I think if you want zaphod mode you should be able to have it |
31 |
and thus don't want to take away from your rant, as a user running triple- |
32 |
head randr (3 by full-hd-1920x1080, "stacked" configuration for 1920x3240 |
33 |
total desktop size) here, the down sides aren't /quite/ as bad as you |
34 |
make them out to be. |
35 |
|
36 |
Plus, there's a couple other alternatives too, which you haven't |
37 |
mentioned. |
38 |
|
39 |
|
40 |
First to address randr. I believe a lot there depends upon the |
41 |
flexibility and configurability of your window manager. I qualify the |
42 |
claim with "I believe", because I've not run anything but kwin for quite |
43 |
some time, so I actually don't know how flexible/configurable other WMs |
44 |
are, but what I DO know is how well kwin works for me in this regard. =:^) |
45 |
|
46 |
(But don't get the impression that I'm a full kde guy. While I do still |
47 |
run kde as my general DE, I run a quite cut down kde here, including |
48 |
USE=-semantic-desktop, and having switched to non-kde apps for pretty |
49 |
much everything critical but kwin and the desktop itself. I run the gtk2 |
50 |
based firefox as browser, gtk2 claws-mail as mail client and with its |
51 |
feed plugin for feeds, gtk2 pan as my nntp/news client, non-kde media |
52 |
players such as vlc (using its default qt4 interface), smplayer (qt4), |
53 |
and mpd with various front-ends (cli/ncurses/qt4). If the switch to kde |
54 |
frameworks 5 with qt5 is anything like the kde4 upgrade, they'll probably |
55 |
lose me for the desktop too, but so far signs are good that they've seen |
56 |
some sense and don't intend to go thru /that/ again.) |
57 |
|
58 |
So anyway, at least kwin can be configured to see the entire desktop as a |
59 |
single "screen" (USE=-xinerama for qt-gui), or to treat each one |
60 |
separately (USE=xinerama). When kwin is in separate screens mode, which |
61 |
is what I use, full-screen and maximizing work to just the single randr |
62 |
monitor (formerly xinerama/X screen) and the default smart-window- |
63 |
placement can be set to either put windows on the "active" screen as |
64 |
defined by where the mouse pointer is, or as defined by the parent or |
65 |
active window. (I use pointer-active since it allows me to for instance |
66 |
click a link and quickly point at a different monitor if I want firefox |
67 |
to open there instead.) |
68 |
|
69 |
For windows that don't behave to my liking, kwin has window rules which |
70 |
allow setting all sorts of exceptions. I normally want my browser and |
71 |
konsole windows set half-maximized, for instance, maximized (to monitor) |
72 |
vertically, but half-max horizontally (on a full-HD 1920x1080 9:16 ratio |
73 |
widescreen, so 960x1080), so I can open two side-by-side. Window rules |
74 |
allow me to enforce this. |
75 |
|
76 |
There's an old DOS-based game (Master of Orion, original, now 20 years |
77 |
old... and the only non-freedomware app I still run) I run in dosbox, |
78 |
that I have set very specifically not only to size, but to position, so |
79 |
it always opens up in the same place on the same monitor, basically so |
80 |
the game is full monitor height, but not full monitor width as that would |
81 |
distort it. I also have that particular window set to no-border since |
82 |
that would only be a distraction, but it's also possible to keep the |
83 |
title bar but force position and size such that only the titlebar appears |
84 |
on one screen, while the game in the client window appears vertically |
85 |
maximized in the screen below, and sometimes when I'm tweaking things, |
86 |
I'll switch it to that mode so I can see the parameters dosbox puts in |
87 |
the titlebar, without losing the full-height game display. |
88 |
|
89 |
For other windows, including claws-mail (for mail and feeds) and pan (for |
90 |
nntp/news), I force horizontally maximized (to screen), while forcing |
91 |
them basically titlebar height shorter than vertically maximized. I then |
92 |
force the position to the bottom of the screen such that there's just |
93 |
titlebar height available above them, so I can have the half-width full- |
94 |
height browser, console or reply windows open and can easily switch |
95 |
between them with just a pointer movement (focus follows mouse, click-to- |
96 |
raise, window transparency set so I can type in the active but second- |
97 |
down window while referring to content in the window above it). See the |
98 |
screenshot link, which illustrates this: |
99 |
|
100 |
(Slightly NSFW warning, the firefox skin is a Sports Illustrated swimsuit |
101 |
model. Bikini, but sensitive types may wish to avoid.) |
102 |
|
103 |
http://wstaw.org/m/2013/05/11/duncan-fullscreen.png |
104 |
|
105 |
If a window /still/ insists on ignoring the window-rule settings, as some |
106 |
that think they know better than the window manager where they should go |
107 |
and what their size constraints should be, there's a couple additional |
108 |
window rule options to force-ignore those settings too, and I do use that |
109 |
for a couple things altho it's rather rare that I actually need it. |
110 |
|
111 |
Kwin actually has a nice "drag to side" half-maximize (full height, half |
112 |
width, or quarter-size, half-size both directions) trick too, as well as |
113 |
"drag to top" to maximize. Of course both features are configurable. |
114 |
With a stacked config I find the to-top-maximize more trouble than it's |
115 |
worth so that's turned off, and the quarter size drag-to-side area (as |
116 |
opposed to half-size) is reduced since I don't have much use for it, but |
117 |
I do use the half-maximized functionality quite a bit. |
118 |
|
119 |
Further, kwin can be configured as a full tiling window manager (hotkey |
120 |
tiling operation triggerable) for those that like that, but that's not my |
121 |
thing. |
122 |
|
123 |
So basically what I'm saying is that whatever behavior, both generic and |
124 |
specific window, you might want, kwin is generally configurable to do |
125 |
exactly that. And its config files are text-based so you can either use |
126 |
the GUI configurator or edit the text files directly, if you prefer. =:^) |
127 |
|
128 |
|
129 |
But as I said, if you want fully independent screens aka zaphod mode, I |
130 |
think it should be doable. But given that it seems less and less so, |
131 |
what about those other workarounds that I mentioned? |
132 |
|
133 |
There's two that I know of. Which one you choose will depend on your |
134 |
needs and neither one is exactly like single-X-session zaphod mode as |
135 |
both involve multiple X sessions, but with some tweaking, hopefully one |
136 |
or the other will do what you want. |
137 |
|
138 |
1) Xorg can handle multiple X sessions on the same hardware, each using |
139 |
its own VT. This is sometimes referred to as fast-user-switching, |
140 |
particularly when it's handled via GUI at the XDM login level, but the |
141 |
same thing can be done using CLI login and running startx multiple times, |
142 |
as the same user or different users. I actually do this accidentally on |
143 |
occasion if I forget that I already have an X session running, which is |
144 |
how I know it works, but a script that sets the XSESSION variable and |
145 |
switches out a few other things appropriately would be easily setup. |
146 |
|
147 |
This lets you switch X sessions just like you do CLI VTs, using CTRL-ALT- |
148 |
Fx. Each X session runs on the same physical displays using the same |
149 |
input hardware, and you simply switch between them. Thus, you'd have the |
150 |
same multi-monitor combined desktop setup in each one, but each X session |
151 |
would be separate and indeed, could be separate users too. Similarly, |
152 |
starting say kde in one and enlightenment in another shouldn't be |
153 |
difficult to script. (Running say two separate sessions of the same |
154 |
environment as the same user can be a bit problematic if the environment |
155 |
expects only one to be running and the two overwrite each others |
156 |
settings, but it's doable in general, as demonstrated by the accidental |
157 |
launches I find myself with here, on occasion, and it should be scriptable |
158 |
to keep them separate where necessary.) |
159 |
|
160 |
2) It's also possible to do "multi-seat X", where each "seat" has its own |
161 |
entirely separate configuration, each talking to its own graphics card |
162 |
with its own displays attached and using its own input hardware, as |
163 |
configured. |
164 |
|
165 |
This would be even more separate than either zaphod mode or multi-session- |
166 |
multi-VT X, since not only are the X sessions separate, but each is using |
167 |
its own hardware display and input devices, as well. |
168 |
|
169 |
To make this work, there's a kernel option that needs set so the graphics |
170 |
instructions get routed to the correct hardware. Each xorg config would |
171 |
then specify the graphics card it was to use as well as the input |
172 |
devices, and to start the second one you'd add the appropriate config |
173 |
file option when invoking X. |
174 |
|
175 |
But this might actually be more separation than you want, since switching |
176 |
between screens would mean switching keyboards/mice. Also, I've not |
177 |
actually used this mode myself, so while I know a bit about it, the |
178 |
practical help I could give you would be a bit more limited. And of |
179 |
course there's the fact that you now have the extra cost for those |
180 |
additional devices... |
181 |
|
182 |
I /think/ it should even be possible using xinput to script logical |
183 |
disconnection of input devices from one xsession, and connection to the |
184 |
other, thus allowing you to invoke that script with a hotkey, for input |
185 |
switching the same input devices to work with multiple sessions. That |
186 |
would limit the extra cost to the additional graphics card and let you |
187 |
switch which session and display you were working with via simple hotkey. |
188 |
But while I've done some xrandr scripting, I've not done any with xinput |
189 |
and don't actually have it installed, so I'm only guessing at what it can |
190 |
do in that regard based on previous articles I've read. |
191 |
|
192 |
-- |
193 |
Duncan - List replies preferred. No HTML msgs. |
194 |
"Every nonfree program has a lord, a master -- |
195 |
and if you use the program, he is your master." Richard Stallman |