1 |
After years of assuming I'd probably never set my system up with |
2 |
multiple monitors, I've decided to go ahead and do it. I've watched |
3 |
with some interest as various new schemes for doing it have emerged over |
4 |
the years (Xinerama, and now lately RandR), but I've always assumed that |
5 |
if nothing else, good old Zaphod mode would always be around, since it's |
6 |
built right into the way X11 numbers $DISPLAY (0:0, 0:1, 0:2...etc.). |
7 |
It's been around so long, it's older than Linux itself. |
8 |
|
9 |
Lately, I've been reading a lot of listserv and newsgroup posts from |
10 |
developers telling various people in forums that if they want Zaphod |
11 |
mode, they're more or less strange odd creatures who ought to be ashamed |
12 |
of themselves. The driver developers don't want to support it anymore. |
13 |
It's not so much a problem in the X server as in each of the individual |
14 |
video drivers for the various cards. I've probably read seven or eight |
15 |
different threads like this now, so it's odd that the common trend in |
16 |
all of them is that each of these users is told no one else but them |
17 |
uses it. (Apparently a lot do.) |
18 |
|
19 |
Anyway, Zaphod is what I want. I don't care that it won't let me drag |
20 |
windows between monitors. That's precisely the advantage of it. Many |
21 |
applications are written with such an assumption of a single display |
22 |
that it's best not to disappoint them. I don't want to worry about what |
23 |
a fullscreen game will think of my multihead setup. I don't want to see |
24 |
dialog windows (or anything else really) popping up, half on one monitor |
25 |
and half on another. I don't want to have to setup the arrangement of |
26 |
my desktop so that it's arranged to not look rediculous at the point |
27 |
where the two monitors divide the screen. It's all just simpler if we |
28 |
have two screens that are completely separate, and the only magic object |
29 |
that's able to move between them is the mouse pointer. |
30 |
|
31 |
X11 has been able to do this since the 80's. |
32 |
|
33 |
But now we're in a brave new world where "nobody wants to do that" |
34 |
(other than seven or eight people on various forums, and those are just |
35 |
the ones who complained). I suppose I shouldn't be surprised. They say |
36 |
we have Wayland in our future too, which we're assured will have some |
37 |
kind of way to run apps on a remote desktop that will certainly be at |
38 |
least as good as running a VNC app on Windows (oh joy). While we're at |
39 |
it, why don't we get rid of this multiple desktops thing that most X11 |
40 |
window managers support -- nobody does that on Windows either, so surely |
41 |
that's probably another thing that nobody on Linux really uses. We |
42 |
should definitely find all the window managers that support that and |
43 |
strip that feature out of them for everyone's own good. |
44 |
|
45 |
Ok, I suppose I should quit ranting. It's just been a trend now for the |
46 |
past five years or so that I've been seeing upstream developers making |
47 |
"improvements" to Linux that are so basic to the infrastructure that no |
48 |
distro can fight them (PolicyKit, Wayland, goodbye Zaphod, udev, etc.). |
49 |
I normally don't complain about what the developers do, since it's not |
50 |
me doing the programming, but I think we should be able to make an |
51 |
exception for things that, a) affect us all, and b) are so basic to the |
52 |
way modern Linux systems work that not even the leadership of a major |
53 |
distro can say jack about it. In cases like this, I think we should |
54 |
have a right to complain, because in this instance, saying that if you |
55 |
don't like it you can start your own fork is like saying that you're |
56 |
free to fork the entire GNU/Linux platform. Technically it's true, but |
57 |
it's also not reasonable or helpful. (Nobody is going to do that.) |
58 |
|
59 |
So I am a bit disappointed when they decide behavior that's been an |
60 |
assumed part of the way Unix systems act for over twenty years is |
61 |
something nobody cares about, when then users complain, each user is |
62 |
told individually that they're the only ones who use that feature...all |
63 |
of them. |
64 |
|
65 |
I'm not complaining that we have RandR now. I think it's great. One of |
66 |
X11's greatest weaknesses has always been that before now, you couldn't |
67 |
really make any big configuration changes while the X server is running. |
68 |
Now, thanks to RandR, you can do almost anything with your desktop |
69 |
running and active, and you don't even need root access. You can't |
70 |
configure Zaphod type multihead that way, but that's fine -- you |
71 |
couldn't do that before either (nothing gained, nothing lost). But |
72 |
RandR lets you make almost any other desktop geometry change as a |
73 |
regular user without restarting X, and I think that's great. |
74 |
|
75 |
RandR (and its predecessor, Xinerama) both assume though that if you're |
76 |
doing multihead, you want one big screen that spans multiple monitors. |
77 |
Nice if that's what you want, but as detailed above, there are good |
78 |
reasons why you might prefer otherwise. For example, on my system, I |
79 |
have a landscape mode main monitor, and a secondary monitor rotated |
80 |
sideways (portrait mode) to the left of it. That means that if I were |
81 |
to adopt some kind of RandR/Xinerama type spanned desktop, I'd have a |
82 |
choice: I could have a desktop that's shaped like some kind of "L", or |
83 |
a desktop that's shaped like a sideways "T". I don't think I really |
84 |
like either of those very much. It's very weird, and many of my apps |
85 |
will probably think so too, especially when I try to fullscreen their |
86 |
windows. Instead of desktops shaped like alphabet soup, why not have |
87 |
separate logical screens? I don't mind that I can't move windows |
88 |
between them. I don't want the desktops to know about eachother anyway. |
89 |
It's simpler that way. |
90 |
|
91 |
There are Xinerama "hints" that apps which support Xinerama are supposed |
92 |
to use to help with this, which I think RandR is supposed to respect. |
93 |
The problem with this is the same as the problem with Wayland's |
94 |
expectation that clients will take care of their own network |
95 |
transparency needs: As soon as you leave it to the individual programs, |
96 |
you will have varying levels of support in each one. Some will be |
97 |
paragons of good behavior, others will be useless. You can only make a |
98 |
feature truly available to all when it's provided as an OS feature. |
99 |
There will still be programs that misbehave, but they'll have to try |
100 |
much harder at it. |
101 |
|
102 |
I think I'm probably most irked by the claims being made by some |
103 |
developers that X doesn't feature network transparency anyway, thus |
104 |
they're not really taking away anything that we really had. This, in |
105 |
spite of the daily experiences of anyone who's ever done 'ssh -Y' and |
106 |
seen that, shockingly, it actually works pretty well. |
107 |
|
108 |
-- |
109 |
+ Brent A. Busby + "We've all heard that a million monkeys |
110 |
+ Sr. UNIX Systems Admin + banging on a million typewriters will |
111 |
+ University of Chicago + eventually reproduce the entire works of |
112 |
+ James Franck Institute + Shakespeare. Now, thanks to the Internet, |
113 |
+ Materials Research Ctr + we know this is not true." -Robert Wilensky |