Mailing List Archive

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.

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

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.

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

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

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

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

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

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

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.