[gentoo-desktop] questions and sundry gripes about X11 multihead (it's a rant)

[gentoo-desktop] questions and sundry gripes about X11 multihead (it's a rant)

[Brent Busby]

After years of assuming I'd probably never set my system up with 
multiple monitors, I've decided to go ahead and do it.  I've watched 
with some interest as various new schemes for doing it have emerged over 
the years (Xinerama, and now lately RandR), but I've always assumed that 
if nothing else, good old Zaphod mode would always be around, since it's 
built right into the way X11 numbers $DISPLAY (0:0, 0:1, 0:2...etc.). 
It's been around so long, it's older than Linux itself.

Lately, I've been reading a lot of listserv and newsgroup posts from 
developers telling various people in forums that if they want Zaphod 
mode, they're more or less strange odd creatures who ought to be ashamed 
of themselves.  The driver developers don't want to support it anymore. 
It's not so much a problem in the X server as in each of the individual 
video drivers for the various cards.  I've probably read seven or eight 
different threads like this now, so it's odd that the common trend in 
all of them is that each of these users is told no one else but them 
uses it.  (Apparently a lot do.)

Anyway, Zaphod is what I want.  I don't care that it won't let me drag 
windows between monitors.  That's precisely the advantage of it.  Many 
applications are written with such an assumption of a single display 
that it's best not to disappoint them.  I don't want to worry about what 
a fullscreen game will think of my multihead setup.  I don't want to see 
dialog windows (or anything else really) popping up, half on one monitor 
and half on another.  I don't want to have to setup the arrangement of 
my desktop so that it's arranged to not look rediculous at the point 
where the two monitors divide the screen.  It's all just simpler if we 
have two screens that are completely separate, and the only magic object 
that's able to move between them is the mouse pointer.

X11 has been able to do this since the 80's.

But now we're in a brave new world where "nobody wants to do that" 
(other than seven or eight people on various forums, and those are just 
the ones who complained).  I suppose I shouldn't be surprised.  They say 
we have Wayland in our future too, which we're assured will have some 
kind of way to run apps on a remote desktop that will certainly be at 
least as good as running a VNC app on Windows (oh joy).  While we're at 
it, why don't we get rid of this multiple desktops thing that most X11 
window managers support -- nobody does that on Windows either, so surely 
that's probably another thing that nobody on Linux really uses.  We 
should definitely find all the window managers that support that and 
strip that feature out of them for everyone's own good.

Ok, I suppose I should quit ranting.  It's just been a trend now for the 
past five years or so that I've been seeing upstream developers making 
"improvements" to Linux that are so basic to the infrastructure that no 
distro can fight them (PolicyKit, Wayland, goodbye Zaphod, udev, etc.). 
I normally don't complain about what the developers do, since it's not 
me doing the programming, but I think we should be able to make an 
exception for things that, a) affect us all, and b) are so basic to the 
way modern Linux systems work that not even the leadership of a major 
distro can say jack about it.  In cases like this, I think we should 
have a right to complain, because in this instance, saying that if you 
don't like it you can start your own fork is like saying that you're 
free to fork the entire GNU/Linux platform.  Technically it's true, but 
it's also not reasonable or helpful.  (Nobody is going to do that.)

So I am a bit disappointed when they decide behavior that's been an 
assumed part of the way Unix systems act for over twenty years is 
something nobody cares about, when then users complain, each user is 
told individually that they're the only ones who use that feature...all 
of them.

I'm not complaining that we have RandR now.  I think it's great.  One of 
X11's greatest weaknesses has always been that before now, you couldn't 
really make any big configuration changes while the X server is running. 
Now, thanks to RandR, you can do almost anything with your desktop 
running and active, and you don't even need root access.  You can't 
configure Zaphod type multihead that way, but that's fine -- you 
couldn't do that before either (nothing gained, nothing lost).  But 
RandR lets you make almost any other desktop geometry change as a 
regular user without restarting X, and I think that's great.

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.

I think I'm probably most irked by the claims being made by some 
developers that X doesn't feature network transparency anyway, thus 
they're not really taking away anything that we really had.  This, in 
spite of the daily experiences of anyone who's ever done 'ssh -Y' and 
seen that, shockingly, it actually works pretty well.

-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
+ Materials Research Ctr +  we know this is not true." -Robert Wilensky

Re: [gentoo-desktop] questions and sundry gripes about X11 multihead (it's a rant)

[Fat-Zer]

[-- Attachment #1: Type: text/plain, Size: 7763 bytes --]

2013/12/30 Brent Busby <brent@keycorner.org>

> After years of assuming I'd probably never set my system up with multiple
> monitors, I've decided to go ahead and do it.  I've watched with some
> interest as various new schemes for doing it have emerged over the years
> (Xinerama, and now lately RandR), but I've always assumed that if nothing
> else, good old Zaphod mode would always be around, since it's built right
> into the way X11 numbers $DISPLAY (0:0, 0:1, 0:2...etc.). It's been around
> so long, it's older than Linux itself.
>
> Lately, I've been reading a lot of listserv and newsgroup posts from
> developers telling various people in forums that if they want Zaphod mode,
> they're more or less strange odd creatures who ought to be ashamed of
> themselves.  The driver developers don't want to support it anymore. It's
> not so much a problem in the X server as in each of the individual video
> drivers for the various cards.  I've probably read seven or eight different
> threads like this now, so it's odd that the common trend in all of them is
> that each of these users is told no one else but them uses it.  (Apparently
> a lot do.)
>
> Anyway, Zaphod is what I want.  I don't care that it won't let me drag
> windows between monitors.  That's precisely the advantage of it.  Many
> applications are written with such an assumption of a single display that
> it's best not to disappoint them.  I don't want to worry about what a
> fullscreen game will think of my multihead setup.  I don't want to see
> dialog windows (or anything else really) popping up, half on one monitor
> and half on another.  I don't want to have to setup the arrangement of my
> desktop so that it's arranged to not look rediculous at the point where the
> two monitors divide the screen.  It's all just simpler if we have two
> screens that are completely separate, and the only magic object that's able
> to move between them is the mouse pointer.
>
> X11 has been able to do this since the 80's.
>
> But now we're in a brave new world where "nobody wants to do that" (other
> than seven or eight people on various forums, and those are just the ones
> who complained).  I suppose I shouldn't be surprised.  They say we have
> Wayland in our future too, which we're assured will have some kind of way
> to run apps on a remote desktop that will certainly be at least as good as
> running a VNC app on Windows (oh joy).  While we're at it, why don't we get
> rid of this multiple desktops thing that most X11 window managers support
> -- nobody does that on Windows either, so surely that's probably another
> thing that nobody on Linux really uses.  We should definitely find all the
> window managers that support that and strip that feature out of them for
> everyone's own good.
>
> Ok, I suppose I should quit ranting.  It's just been a trend now for the
> past five years or so that I've been seeing upstream developers making
> "improvements" to Linux that are so basic to the infrastructure that no
> distro can fight them (PolicyKit, Wayland, goodbye Zaphod, udev, etc.). I
> normally don't complain about what the developers do, since it's not me
> doing the programming, but I think we should be able to make an exception
> for things that, a) affect us all, and b) are so basic to the way modern
> Linux systems work that not even the leadership of a major distro can say
> jack about it.  In cases like this, I think we should have a right to
> complain, because in this instance, saying that if you don't like it you
> can start your own fork is like saying that you're free to fork the entire
> GNU/Linux platform.  Technically it's true, but it's also not reasonable or
> helpful.  (Nobody is going to do that.)
>
> So I am a bit disappointed when they decide behavior that's been an
> assumed part of the way Unix systems act for over twenty years is something
> nobody cares about, when then users complain, each user is told
> individually that they're the only ones who use that feature...all of them.
>
> I'm not complaining that we have RandR now.  I think it's great.  One of
> X11's greatest weaknesses has always been that before now, you couldn't
> really make any big configuration changes while the X server is running.
> Now, thanks to RandR, you can do almost anything with your desktop running
> and active, and you don't even need root access.  You can't configure
> Zaphod type multihead that way, but that's fine -- you couldn't do that
> before either (nothing gained, nothing lost).  But RandR lets you make
> almost any other desktop geometry change as a regular user without
> restarting X, and I think that's great.
>
> 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.
>
> I think I'm probably most irked by the claims being made by some
> developers that X doesn't feature network transparency anyway, thus they're
> not really taking away anything that we really had.  This, in spite of the
> daily experiences of anyone who's ever done 'ssh -Y' and seen that,
> shockingly, it actually works pretty well.
>
> --
> + Brent A. Busby         + "We've all heard that a million monkeys
> + Sr. UNIX Systems Admin +  banging on a million typewriters will
> + University of Chicago  +  eventually reproduce the entire works of
> + James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
> + Materials Research Ctr +  we know this is not true." -Robert Wilensky
>
> Could you be more specific? e.g. provide some links to bugs, mail archives
or whatever with subj discussions.
I'm using multihead «Zaphod mode», or whatever it's called, on nvidia's
blob for 3 years and haven't noticed any problems. (Except I had some
KDE3/TDE-related ones. But It's an another story...). Xorg.0.log yields
that RandR is disabled but I still can rotate/resize screen with xrandr. So
I never faced with issues you're talking about. On the other hand I'm a bit
concerned about all this situation. Because it would be damn sad if whoever
will drop support for it in future.

[-- Attachment #2: Type: text/html, Size: 8319 bytes --]

[gentoo-desktop] Re: questions and sundry gripes about X11 multihead (it's a rant)

[Duncan]

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

Re: [gentoo-desktop] questions and sundry gripes about X11 multihead (it's a rant)

[Dominique Michel]

Le Sun, 29 Dec 2013 23:51:03 -0600 (CST),
Brent Busby <brent@keycorner.org> a écrit :

> After years of assuming I'd probably never set my system up with 
> multiple monitors, I've decided to go ahead and do it.  I've watched 
> with some interest as various new schemes for doing it have emerged
> over the years (Xinerama, and now lately RandR), but I've always
> assumed that if nothing else, good old Zaphod mode would always be
> around, since it's built right into the way X11 numbers $DISPLAY
> (0:0, 0:1, 0:2...etc.). It's been around so long, it's older than
> Linux itself.
> 
> Lately, I've been reading a lot of listserv and newsgroup posts from 
> developers telling various people in forums that if they want Zaphod 
> mode, they're more or less strange odd creatures who ought to be
> ashamed of themselves.  The driver developers don't want to support
> it anymore. It's not so much a problem in the X server as in each of
> the individual video drivers for the various cards.  I've probably
> read seven or eight different threads like this now, so it's odd that
> the common trend in all of them is that each of these users is told
> no one else but them uses it.  (Apparently a lot do.)
> 
> Anyway, Zaphod is what I want.  I don't care that it won't let me
> drag windows between monitors.  That's precisely the advantage of
> it.  Many applications are written with such an assumption of a
> single display that it's best not to disappoint them.  I don't want
> to worry about what a fullscreen game will think of my multihead
> setup.  I don't want to see dialog windows (or anything else really)
> popping up, half on one monitor and half on another.  I don't want to
> have to setup the arrangement of my desktop so that it's arranged to
> not look rediculous at the point where the two monitors divide the
> screen.  It's all just simpler if we have two screens that are
> completely separate, and the only magic object that's able to move
> between them is the mouse pointer.
> 
> X11 has been able to do this since the 80's.
> 
> But now we're in a brave new world where "nobody wants to do that" 
> (other than seven or eight people on various forums, and those are
> just the ones who complained).  I suppose I shouldn't be surprised.
> They say we have Wayland in our future too, which we're assured will
> have some kind of way to run apps on a remote desktop that will
> certainly be at least as good as running a VNC app on Windows (oh
> joy).  While we're at it, why don't we get rid of this multiple
> desktops thing that most X11 window managers support -- nobody does
> that on Windows either, so surely that's probably another thing that
> nobody on Linux really uses.  We should definitely find all the
> window managers that support that and strip that feature out of them
> for everyone's own good.
> 
> Ok, I suppose I should quit ranting.  It's just been a trend now for
> the past five years or so that I've been seeing upstream developers
> making "improvements" to Linux that are so basic to the
> infrastructure that no distro can fight them (PolicyKit, Wayland,
> goodbye Zaphod, udev, etc.). 

Each software you are talking about here is a particular case.
*kit is a mandatory dependency of gnome and a few other desktops/window
managers. I just don't install them, so I don't have *kit into my
system. You can do that even on Debian.

udev have much to do with the kernel. It is still possible to make an
udev free system and manage a static /dev, and I know at least 1 user
that managed to do that on a desktop PC. Also, an udev free system must
be the way to go for many simple embedded systems, but that's another
subject.

Wayland is another issue. Due to the complexity of X and of all its
extensions, wayland's compatibility layer will be a never finished
job, which will break hundreds of good working software. Because of
that, I think wayland may be a good move for the mobile or game market,
but than for the desktop, X will remain in use for a long time, at
least by experienced users. Or many of these experienced users will
be looking for alternatives. Some already have done it, or are in
the process to do it.

Another concern with wayland is windows managers. Most of them will
just stop to work with wayland, and this is not an incomplete
compatibility layer that will make them to work. My main concern here
is fvwm, which is not only a wm, but also a tool-kit for the Xlib which
let its users do whatever they can think about with it. I don't see
anything like that coming with wayland. So for me, wayland is just not a
viable alternative, and I am not the only one in that case.

Re: [gentoo-desktop] questions and sundry gripes about X11 multihead (it's a rant)

[Brent Busby]

On Mon, 30 Dec 2013, Fat-Zer wrote:

> Could you be more specific? e.g. provide some links to bugs, mail 
> archives or whatever with subj discussions. I'm using multihead 
> ?Zaphod mode?, or whatever it's called, on nvidia's blob for 3 years 
> and haven't noticed any problems. (Except I had some KDE3/TDE-related 
> ones. But It's an another story...). Xorg.0.log yields that RandR is 
> disabled but I still can rotate/resize screen with xrandr. So I never 
> faced with issues you're talking about. On the other hand I'm a bit 
> concerned about all this situation. Because it would be damn sad if 
> whoever will drop support for it in future.

Sorry, I was just in a bad mood and spewing generally about things. 
Just for starters though:

http://phoronix.com/forums/showthread.php?20384-Zaphod-mode-with-the-Open-Source-Driver

http://mail-index.netbsd.org/tech-x11/2013/06/29/msg001263.html

I did get the impression during my trawl of the forums that the nVidia 
closed driver still offers some support for this configuration, but even 
that is depressing to me:  As soon as we reach a point where only one 
non-FOSS driver is fully supporting a feature that used to be a basic 
part of X-Windows, it's basically dead.  It's now become a perk of 
running nVidia hardware that will be with us for only as long as nVidia 
wants to continue indulging us.

And that support only comes in a driver that the Linux kernel developers 
understandably don't like very much...

-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
+ Materials Research Ctr +  we know this is not true." -Robert Wilensky

Re: [gentoo-desktop] Re: questions and sundry gripes about X11 multihead (it's a rant)

[Brent Busby]

On Mon, 30 Dec 2013, Duncan wrote:

> 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. =:^)

I did read about a window manager called Awesome that's supposed to be 
more multihead-aware than any other, including specific support for 
Zaphod mode (if you can get your card's video driver to do it at all).

> (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.)

That's a great example of the sort of thing I was ranting about -- the 
KDE developers decided nobody really likes KDE as we knew it and decided 
to give us a whole new product.  They even put us through five or six 
releases of beta quality software while they tried to stabilize the new 
desktop that we never asked for.  I never posted a rant about that 
before though because on Unix, if you don't like a desktop, don't run 
it.  If you start taking away basic features of X11 though, that's 
really annoying, which is why the Zaphod and Wayland issues bother me 
much more.

> 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.)

That brings up an interesting possibility:  Since I'd heard everywhere 
that basically RandR has supplanted Xinerama, I have my system compiled 
globally with USE=-xinerama.  Does this mean that if I turn USE=xinerama 
on, I may be able to get window placement to behave?  I'm still facing 
driver issues with the open source radeon driver, but this could at 
least be an answer to the window/desktop management problem (e.g., 
maximizing windows fullscreen to just one monitor).

> 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.

Yes, this is the type of configuration tricks I'm going to have to start 
learning a lot of I think.  Having two monitors is nice, but it's going 
to make life complicated.  :)

> 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.

I have a feeling I'm probably just going with RandR, just because that's 
the direction the wind is blowing.  You can only fight upstream for so 
long.

> 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.

I've thought about doing this too...  The fast user switching applets 
all assume you want to switch between two X servers on the same monitor. 
If I go this route, I'd imagine it will be more like just using 
Ctrl-Alt-F<n> to switch the mouse and keyboard back and forth between 
two monitors.

> 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.

Yes, that sounds really cool, though that's more than I'm wanting.

-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
+ Materials Research Ctr +  we know this is not true." -Robert Wilensky

Re: [gentoo-desktop] questions and sundry gripes about X11 multihead (it's a rant)

[Brent Busby]

On Mon, 30 Dec 2013, Dominique Michel wrote:

> Each software you are talking about here is a particular case. *kit is 
> a mandatory dependency of gnome and a few other desktops/window 
> managers. I just don't install them, so I don't have *kit into my 
> system. You can do that even on Debian.

For now, you can still fight it, but I have a feeling it's going to be 
like DBus (which I don't hate, but it still makes a good example for 
this):  It will become so integrated into the way Linux works that 
eventually, you just won't be able to live without it.  Most things like 
that I don't fight because I know you can only do it for so long.

> udev have much to do with the kernel. It is still possible to make an 
> udev free system and manage a static /dev, and I know at least 1 user 
> that managed to do that on a desktop PC. Also, an udev free system 
> must be the way to go for many simple embedded systems, but that's 
> another subject.

You can fight it, but is it worth it?  My main annoyance with udev is 
that it makes copying the image of an installed Linux machine to another 
machine more complicated than it really needs to be, due to the way it 
retains and depends on information about a particular PC's hardware that 
get configured at install time.  I've learned to work around it, but 
it's annoying.  Still...you can't fight upstream.

> Wayland is another issue. Due to the complexity of X and of all its 
> extensions, wayland's compatibility layer will be a never finished 
> job, which will break hundreds of good working software. Because of 
> that, I think wayland may be a good move for the mobile or game 
> market, but than for the desktop, X will remain in use for a long 
> time, at least by experienced users. Or many of these experienced 
> users will be looking for alternatives. Some already have done it, or 
> are in the process to do it.

Just having big distros like Fedora and Ubuntu pushing it will fracture 
the Linux platform even more than it already is.  It's true that there 
will still be X and users who use it, but everyone will have to deal 
with a world where the first question about your Linux install will be, 
"Do you run X or Wayland?"  And from there, the fun begins...

> Another concern with wayland is windows managers. Most of them will 
> just stop to work with wayland, and this is not an incomplete 
> compatibility layer that will make them to work. My main concern here 
> is fvwm, which is not only a wm, but also a tool-kit for the Xlib 
> which let its users do whatever they can think about with it. I don't 
> see anything like that coming with wayland. So for me, wayland is just 
> not a viable alternative, and I am not the only one in that case.

Totally agree.  I love FVWM (and WindowMaker), and I think the ability 
to change to a whole different kind of desktop if you want is one of the 
greatest features of X.  I have a feeling Wayland users are going to end 
up with a desktop that's theme-able (in the way you can theme a Windows 
desktop), but not completely replaceable with any of twenty wholly 
different desktop/window managers.  Some people will say that's an 
improvement, since I've been hearing for years that Linux should have 
only one desktop, but the problem with those arguments is that everyone 
making it thinks their favorite window manager should be the one. 
Choice is good as long as it doesn't break things that used to work, so 
I think having a choice of lots of desktops is a great thing.

-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
+ Materials Research Ctr +  we know this is not true." -Robert Wilensky

Re: [gentoo-desktop] questions and sundry gripes about X11 multihead (it's a rant)

[Dominique Michel]

Le Mon, 30 Dec 2013 10:52:14 -0600 (CST),
Brent Busby <brent@keycorner.org> a écrit :

> On Mon, 30 Dec 2013, Dominique Michel wrote:
> 
> > Each software you are talking about here is a particular case. *kit
> > is a mandatory dependency of gnome and a few other desktops/window 
> > managers. I just don't install them, so I don't have *kit into my 
> > system. You can do that even on Debian.
> 
> For now, you can still fight it, but I have a feeling it's going to
> be like DBus (which I don't hate, but it still makes a good example
> for this):  It will become so integrated into the way Linux works
> that eventually, you just won't be able to live without it.  Most
> things like that I don't fight because I know you can only do it
> for so long.

It is another issue on Debian. It's called systemd. It make the kernel
cgroups totally unusable with cpu.rt_runtime_us. systemd insist to take
control of it, put whatever it think is good to have into the rt
cgroup, and the machine just freeze without warning.

> 
> > udev have much to do with the kernel. It is still possible to make
> > an udev free system and manage a static /dev, and I know at least 1
> > user that managed to do that on a desktop PC. Also, an udev free
> > system must be the way to go for many simple embedded systems, but
> > that's another subject.
> 
> You can fight it, but is it worth it?  My main annoyance with udev is 
> that it makes copying the image of an installed Linux machine to
> another machine more complicated than it really needs to be, due to
> the way it retains and depends on information about a particular PC's
> hardware that get configured at install time.  I've learned to work
> around it, but it's annoying.  Still...you can't fight upstream.

That's right, but on the long run, the users will decide. It is a few
years ago, GNU/Linux was the fastest growing OS on the desktop market.
Today, that's not true any more, and I think mainly because users get
tired of break_my_good_working_system.tm idiotic stuffs. It begun with
the kde3 to kde4 move. Instead of fixing existing bugs, they replaced a
lot a advanced applications with pale copies of them, and a few years
later, many of these pale copies never get updated with the
functionalities of the older versions. As example kaffeine. This app
was the perfect TV application for an average desktop user coming from
windows. Nothing to setup, it just worked. The GUI was a little bit
buggy, but full with features. It remain almost nothing of these
features in the new versions.

Also sometime upstream are like the French in politics. It work in
practice, but they ask: What say the theory? A good example of that is
the animated png support in linux. A patch exist, but nobody care about
supporting it into its software, that just because it is not in the
norm, it is only an extension. It was a kde3 application that was able
to open such files, it was one of the most advanced pic viewer on Linux.
Now, this app is dead and if I want to open such files, I must run
e-uae, and load some AmigaOS from the eighties into it. Tell that to a
linux newbie coming from windows, this give that:
http://ubuntuforums.org/showthread.php?t=1383411

> 
> > Wayland is another issue. Due to the complexity of X and of all its 
> > extensions, wayland's compatibility layer will be a never finished 
> > job, which will break hundreds of good working software. Because of 
> > that, I think wayland may be a good move for the mobile or game 
> > market, but than for the desktop, X will remain in use for a long 
> > time, at least by experienced users. Or many of these experienced 
> > users will be looking for alternatives. Some already have done it,
> > or are in the process to do it.
> 
> Just having big distros like Fedora and Ubuntu pushing it will
> fracture the Linux platform even more than it already is. It's true
> that there will still be X and users who use it, but everyone will
> have to deal with a world where the first question about your Linux
> install will be, "Do you run X or Wayland?"  And from there, the fun
> begins...

What they are currently doing in Wayland is only half of the job. See
above.

> 
> > Another concern with wayland is windows managers. Most of them will 
> > just stop to work with wayland, and this is not an incomplete 
> > compatibility layer that will make them to work. My main concern
> > here is fvwm, which is not only a wm, but also a tool-kit for the
> > Xlib which let its users do whatever they can think about with it.
> > I don't see anything like that coming with wayland. So for me,
> > wayland is just not a viable alternative, and I am not the only one
> > in that case.
> 
> Totally agree.  I love FVWM (and WindowMaker), and I think the
> ability to change to a whole different kind of desktop if you want is
> one of the greatest features of X.  I have a feeling Wayland users
> are going to end up with a desktop that's theme-able (in the way you
> can theme a Windows desktop), but not completely replaceable with any
> of twenty wholly different desktop/window managers.  Some people will
> say that's an improvement, since I've been hearing for years that
> Linux should have only one desktop, but the problem with those
> arguments is that everyone making it thinks their favorite window
> manager should be the one. Choice is good as long as it doesn't break
> things that used to work, so I think having a choice of lots of
> desktops is a great thing.
> 
Sure. What I think about wayland is simple. They want to integrate the
wm into the server, which is a good idea, but that will break a lot of
things. At the same time, they don't want to further integrate these
with the tool-kit, mainly because folks from mainstream QT and GTK will
not accept that, and are arguing this is not effective on multi-core
processors. They can say what they want, but only 1 core at 8MHz was
necessary to provide a full premptible OS with real multitasking and a
wonderful GUI for that time on the Amiga. Which on a 4 cores
processors, let 3 cores free to make something else.

And more. With the hardware, we can see a new tendency slowly emerging
on the mobile market: multi-core processors with dedicated cores. 1 low
frequency and low power core for the standby, 1 dedicated core to deal
with the hardware, 1 generic core to deal with the GUI, and a DSP core
to deal with all kind of calculations inclusive multimedia. DSP cores
and their multiple data buses have obvious speed advantages over the
best optimised C code on general purpose cores, that for any kind of
calculation. And back from the eighties, the algorithms are well known
and have proved to be very efficient.

Because of that, I really hope, and think, this trend will reach the PC
market as well. And that day, some smart guys will make a Wayland v.2
with the tool-kit integrated into the wm integrated into the server.
And every thing will break again. -:)

Dominique

[gentoo-desktop] Re: questions and sundry gripes about X11 multihead (it's a rant)

[Duncan]

Brent Busby posted on Mon, 30 Dec 2013 10:52:14 -0600 as excerpted:

> Totally agree.  I love FVWM (and WindowMaker), and I think the ability
> to change to a whole different kind of desktop if you want is one of the
> greatest features of X.  I have a feeling Wayland users are going to end
> up with a desktop that's theme-able (in the way you can theme a Windows
> desktop), but not completely replaceable with any of twenty wholly
> different desktop/window managers.

I'm somewhat more optimistic than that.

Certainly wayland is a huge change that will change the landscape of GUI 
Linux as we know it in a huge way, relegating huge swaths of current but 
deep-in-maintenance-mode X-based apps to legacy status unless someone 
picks them up and updates them for wayland; absolutely no question about 
that.

And I think at one point there was a danger of wayland effectively fully 
integrating the WM into it.  But at least in a number of areas (including 
client-side decorations), the kde/kwin folks simply said no, that's not 
going to work for us and we will not be doing it that way, period.

That was the big no to the way wayland and weston had things planned, but 
some other projects took advantage of it and the consequent hooks made 
available and no longer 100% assumptions, and are doing their own thing 
now too.

I /think/ that's part of why weston broke off into a separate project -- 
it's now the reference implementation of what is sort of a parallel to WMs 
(but the comparison is only a rough one, they're technically working at 
rather different levels, with compositing manager being a better 
description of the wayland side), with wayland now exposing a protocol 
both weston and other implementations can use.

And for certain, kde is going to have its own implementation, because as 
I said, there were certain bits of the original implementation as now 
found in weston, that were unacceptable to kde.

That leaves the way open for others as well, and I've read of at least 
one other independent project working on its own implementation, tho at 
this point I think they're actually using weston too.

I expect that as kde frameworks' wayland implementation matures as a full 
second implementation of the compositing manager, showing the way and 
working out some of the original oversights and kinks for others, we'll 
eventually see other choices develop as well, either fully independently, 
or as forks of the original big-two original reference weston, and kde 
frameworks kwin (I don't know if there's a final name for the kde 
frameworks wayland compositor yet, or if they'll keep the kwin name).

Whether it'll ever develop into the complex ecosystem of WM variants we 
have for X after all these decades, or whether it'll remain at a list in 
the single digits, remains to be seen, but I believe the opportunity is 
and will remain there for devs who get that itch to scratch, in part 
thanks to kde/kwin's early NO, that will not work for us and we will not 
accept it, to parts of the original plan.

-- 
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

[gentoo-desktop] Re: questions and sundry gripes about X11 multihead (it's a rant)

[Duncan]

Brent Busby posted on Mon, 30 Dec 2013 10:34:41 -0600 as excerpted:

> On Mon, 30 Dec 2013, Duncan wrote:
> 
>> First to address randr.  I believe a lot there depends upon the
>> flexibility and configurability of your window manager.
> 
> I did read about a window manager called Awesome that's supposed to be
> more multihead-aware than any other, including specific support for
> Zaphod mode (if you can get your card's video driver to do it at all).

Indeed.  I've seen some very good reviews of awesome as well. =:^)

> That brings up an interesting possibility:  Since I'd heard everywhere
> that basically RandR has supplanted Xinerama, I have my system compiled
> globally with USE=-xinerama.  Does this mean that if I turn USE=xinerama
> on, I may be able to get window placement to behave?

Definitely so (tho of course USE=xinerama behavior, as with any USE flag, 
will be somewhat package dependent).

USE=xinerama doesn't necessarily refer to xinerama itself, but rather to 
the general family of protocol extensions it introduced, many of which 
survive the deprecation/demise of xinerama itself.

Things like per-monitor placement are part of those extensions, and are 
still enabled by USE=xinerama even when it's randr or something else 
providing the actual multi-monitor framework in X.

So I'd definitely try it.

If you list the output of equery hasuse xinerama, it's likely that 
various people can fill in the blanks of what its effect is for each 
package.  Here's the packages I have installed here with that flag:

equery h xinerama
 * Searching for USE flag xinerama ... 
[IP-] [  ] dev-qt/qtgui-4.8.5-r1:4
[IP-] [  ] media-libs/libsdl-1.2.15-r4:0
[IP-] [  ] media-video/mplayer2-2.0_p20130428-r1:0
[IP-] [  ] x11-apps/xdpyinfo-1.3.1:0
[IP-] [  ] x11-libs/gtk+-2.24.22:2

qtgui, as I said, controls kwin and plasma-desktop behavior as well, as 
might be expected since they're obviously multi-monitor sensitive and are 
qt-based.

libsdl will likely control the full-screen behavior of various games, 
anything based on sdl.  Here, it controls dosbox.  There's a lot of other 
packages I have here depending on libsdl, including gegl (gimp), vlc, 
ffmpeg and others (grub2?  I wonder what /it/ does with sdl?), but I 
don't believe they all use sdl for full-screen display, so the flag 
likely has little/no effect on some of them.  (For vlc, the qt-based 
front-end is the default if built, while I suspect svlc is the sdl 
variant, so the libsdl xinerama USE flag probably affects only svlc.)

mplayer2... I don't know, as I only use it thru frontends like (qt-based) 
smplayer2.

xdpyinfo just prints display info, so all USE=xinerama could do for it is 
add a bit more info there.

gtk+-2, I'd guess that affects fullscreen for all my gtk-2 based apps, 
primarily firefox and claws-mail.  (I run pan too, but it doesn't have a 
built-in fullscreen option.)

> I'm still facing
> driver issues with the open source radeon driver, but this could at
> least be an answer to the window/desktop management problem (e.g.,
> maximizing windows fullscreen to just one monitor).

I'm running radeon here, too, generally ~amd64 but with a current (3.13-
rcX+) kernel, TURKS hardware (Radeon hd6670 or 6770 IIRC, neither dmesg 
nor the xorg log seem to give the model number, only TURKS, these days).

I've been quite happy with it altho I don't do a lot of gaming.  The 
triple outputs are very nice, as I'm running 3 @ 1920x1080 stacked for 
1920x3240.  It's really something seeing kwin's cube or globe multi-
desktop effect on that, when two of them are 42-inch monitors that 
stacked together fill practically an entire wall!

(The third monitor is actually off to the side as the two big monitors 
take up the entire wall in front of me.  It runs my superkaramba theme 
with all sorts of system performance monitors, as seen in the screenshot 
linked earlier.  I logically stack, however, to avoid the "L" effect you 
mentioned.  Took a few days to get used to, mainly being aware that if I 
can't find the pointer it might be on the third screen above/off-to-the-
side since nothing goes there but superkaramba and I wasn't used to 
looking there, but it's working well for me now.)

-- 
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

Re: [gentoo-desktop] questions and sundry gripes about X11 multihead (it's a rant)

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 7172 bytes --]

On Dec 30, 2013 7:51 AM, "Brent Busby" <brent@keycorner.org> wrote:
>
> After years of assuming I'd probably never set my system up with multiple
monitors, I've decided to go ahead and do it.  I've watched with some
interest as various new schemes for doing it have emerged over the years
(Xinerama, and now lately RandR), but I've always assumed that if nothing
else, good old Zaphod mode would always be around, since it's built right
into the way X11 numbers $DISPLAY (0:0, 0:1, 0:2...etc.). It's been around
so long, it's older than Linux itself.
>
> Lately, I've been reading a lot of listserv and newsgroup posts from
developers telling various people in forums that if they want Zaphod mode,
they're more or less strange odd creatures who ought to be ashamed of
themselves.  The driver developers don't want to support it anymore. It's
not so much a problem in the X server as in each of the individual video
drivers for the various cards.  I've probably read seven or eight different
threads like this now, so it's odd that the common trend in all of them is
that each of these users is told no one else but them uses it.  (Apparently
a lot do.)
>
> Anyway, Zaphod is what I want.  I don't care that it won't let me drag
windows between monitors.  That's precisely the advantage of it.  Many
applications are written with such an assumption of a single display that
it's best not to disappoint them.  I don't want to worry about what a
fullscreen game will think of my multihead setup.  I don't want to see
dialog windows (or anything else really) popping up, half on one monitor
and half on another.  I don't want to have to setup the arrangement of my
desktop so that it's arranged to not look rediculous at the point where the
two monitors divide the screen.  It's all just simpler if we have two
screens that are completely separate, and the only magic object that's able
to move between them is the mouse pointer.
>
> X11 has been able to do this since the 80's.
>
> But now we're in a brave new world where "nobody wants to do that" (other
than seven or eight people on various forums, and those are just the ones
who complained).  I suppose I shouldn't be surprised.  They say we have
Wayland in our future too, which we're assured will have some kind of way
to run apps on a remote desktop that will certainly be at least as good as
running a VNC app on Windows (oh joy).  While we're at it, why don't we get
rid of this multiple desktops thing that most X11 window managers support
-- nobody does that on Windows either, so surely that's probably another
thing that nobody on Linux really uses.  We should definitely find all the
window managers that support that and strip that feature out of them for
everyone's own good.
>
> Ok, I suppose I should quit ranting.  It's just been a trend now for the
past five years or so that I've been seeing upstream developers making
"improvements" to Linux that are so basic to the infrastructure that no
distro can fight them (PolicyKit, Wayland, goodbye Zaphod, udev, etc.). I
normally don't complain about what the developers do, since it's not me
doing the programming, but I think we should be able to make an exception
for things that, a) affect us all, and b) are so basic to the way modern
Linux systems work that not even the leadership of a major distro can say
jack about it.  In cases like this, I think we should have a right to
complain, because in this instance, saying that if you don't like it you
can start your own fork is like saying that you're free to fork the entire
GNU/Linux platform.  Technically it's true, but it's also not reasonable or
helpful.  (Nobody is going to do that.)
>
> So I am a bit disappointed when they decide behavior that's been an
assumed part of the way Unix systems act for over twenty years is something
nobody cares about, when then users complain, each user is told
individually that they're the only ones who use that feature...all of them.
>
> I'm not complaining that we have RandR now.  I think it's great.  One of
X11's greatest weaknesses has always been that before now, you couldn't
really make any big configuration changes while the X server is running.
Now, thanks to RandR, you can do almost anything with your desktop running
and active, and you don't even need root access.  You can't configure
Zaphod type multihead that way, but that's fine -- you couldn't do that
before either (nothing gained, nothing lost).  But RandR lets you make
almost any other desktop geometry change as a regular user without
restarting X, and I think that's great.
>
> 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.
>
> I think I'm probably most irked by the claims being made by some
developers that X doesn't feature network transparency anyway, thus they're
not really taking away anything that we really had.  This, in spite of the
daily experiences of anyone who's ever done 'ssh -Y' and seen that,
shockingly, it actually works pretty well.
>
> --
> + Brent A. Busby         + "We've all heard that a million monkeys
> + Sr. UNIX Systems Admin +  banging on a million typewriters will
> + University of Chicago  +  eventually reproduce the entire works of
> + James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
> + Materials Research Ctr +  we know this is not true." -Robert Wilensky
>

You make it sound much worse than it actually is.

These days pretty much everything works well with randr. Sure, there are
corner cases, but it's been a while since I hit one :) I see no reason not
to use it.

The -kit fiasco, well... That's a different story.

[-- Attachment #2: Type: text/html, Size: 7911 bytes --]