Awesome: Regression: Multiple separate X11 screens setup (Zaphod, no Xinerama) fails; WORKAROUND: start multiple instances

[Manfred-Knick]

REGRESSION
from
. . . x11-wm/awesome-3.4.15:0
to
. . . x11-wm/awesome-3.5.6-r1:0

My setup:
2 graphic "card"s with 1+3=4 monitors
= four separate X11 screens
( c.f. xorg.conf.d -> Attachment ).

Layout "Four":
Only on the fist screen a full working desktop appears.
The other three remain black.
In principle, all four X11 screens get addressed;
at least the "X" sign mouse cursor flows over the rest of the four.

Cross-Check:
Plain X works with (c)twm, as well as fluxbox, xfce, ... on all four screens.

[Manfred-Knick]

$ uname -a
Linux . . . 4.3.2-gentoo . . . x86_64 Intel(R) Xeon(R) CPU E3-1276 v3 . . .

ATTACHMENTS : my xorg.conf.d

Device-01.intel.conf.TXT
Device-11.nvidia.conf.TXT
Monitor.conf.TXT
Screen.conf.TXT

Files.conf.TXT
InputDevice_Keyboard.conf.TXT
InputDevice_Mouse.conf.TXT
ServerFlags.conf.TXT

ServerLayout.conf.TXT

[Manfred-Knick]

Added DEBUG into rc.lua:
. . . naughty.notify({ preset = naughty.config.presets.critical,
. . . . . . title = "DEBUG : rc.lua",
. . . . . . text = "screen.count() = " .. screen.count() })
RESULT:
. . . screen.count() = 1
EXPECTED:
. . . screen.count() = 4

QUERY with xrandr:
. . . xrandr -q --screen 0.n
with
. . . n = [ 0 .. 3 ]
All four deliver the correct values.

As expected, over-ruling "screen.count()" with a static "4" in the rest of rc.lua
resulted into errors like "screen does not exist".

[psychon]

Well, the support for zaphod mode was removed from 3.5 because there was a bug which I thought everyone using this code would notice. I concluded that no one used awesome with zaphod mode, but apparently I was wrong. The "nice" thing about this was that it simplified the code a lot and not being able to move windows between monitors seems awful to me...

There have been some attempts in https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1069 at bringing this back, but that died 1.5 years ago.

[Manfred-Knick]

I'm sorry to hear that - nevertheless, a big "Thanks!" FYI .

Well, combining multiple inhomogeneous graphic adapters with Monitors of different resolutions, Zaphod still proves the most reliable basic - Xinerama (overhead aside) no alternative.

twm / fvwm / fluxbox ... are minimial and old-fashioned, but all work perfectly for a SysAdmin environment;
and I really prefer having each monitor dedicated to it's own separate independent workspaces / tasks,
placing Servers / VMs / Management Console ... Windows always into the same screen / workspace tuple.

KDE becomes more and more bloated; stability of former KDE 3 core: way ahead ... Plasma?!

Gnome dictates it's own vision soleyly ...

KDE and lightweight LXQT both suffer from dbus being screen-agnostic : -> not supporting multi-head.

Enlightment, Openbox, now Awesome as well seem to evaluate RandR of first Screen only : -> same.
dwm, i3 : fail.

XFCE 4.12 remains -
but avisioning gtk+ 3.x , I expect 4.14 to become even much less responsible or low on resources.

Wayland really productive and stable : I guess, 1 1/2 years at minimum ... gtk+ 3.x put aside : qt-dbus?

What a pity.
What would be _your_ advice ?

[psychon]

Me? I don't think that Wayland works in cases where Xorg without Xinerama works. Well, ok, wayland might work, but weston (the reference implementation of a compositor) quite likely will not. After all, if weston could merge multiple outputs via something Xinerama/RandR-like, Xorg could do so as well.

It's a pity that supporting X11's protocol screens requires so much complicated code. I do wonder that your Zaphod mode + RandR setup works with awesome 3.5, I thought that it would ignore RandR if Zaphod mode is in use (so you'd get three monitors merged into one).

Edit: Sorry, meant "awesome 3.4" in the above paragraph.

Some other advice from me: Run several awesome instances, one per protocol screen (so DISPLAY=:0.0 awesome and DISPLAY=:0.1 awesome). Surprisingly, today someone else also reported bug #599 which is exactly about an issue with such a setup.

[Manfred-Knick]

? "I do wonder that your Zaphod mode + RandR setup works with awesome 3.5" ?
CLARIFICATION: It does _not_ - that what this bug is about.

[psychon]

Sorry, I meant "worked with awesome 3.4"

[Manfred-Knick]

@ Uli : I guess you have already noticed
[ http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-starting-services ]

Per default:
"X Windowing System: ...
the X display _without_ the screen number ..."

But, a little bit above, a possible alternative is pointed out:
"Message Bus Service Scope ...
We could add an optional scope to a bus name. For example, for _per-(display,session pair)_, we could have a unique ID for each display generated automatically at login and set on screen 0 by executing a special "set display ID" binary. The ID would be stored in a _DBUS_DISPLAY_ID property and would be a string of random bytes. This ID would then be used to scope names. Starting/locating a service could be done by ID-name pair rather than only by name. ..."

Thus, the _default_ X dbus scope _is_ screen-agnostic, correct -
but I begin to doubt the dogma of the core KDE developers that it can not be done.
Unfortunately, I don't know about the situation in (current) qtdbus.

[Manfred-Knick]

Cite: "Run several awesome instances, one per protocol screen"
If it is that easy - perhaps awesome could start itself in multiple instances [ 0 .. N-1 ]
as long as "xrandr -q --screen n" does not respond with "Invalid screen number n (display has N)"
(well, maybe depending upon a new command line argument "--multiple-screens") ?

[Manfred-Knick]

After starting
"startx /usr/bin/awesome -c ~/.config/awesome/rc.lua -- -layout Four" ,
I can successfully start the other 3 instances from an added menu entry pointing to
$ cat /home/manfred/bin/awesome-on-four
DISPLAY=:0.1 awesome &
DISPLAY=:0.2 awesome &
DISPLAY=:0.3 awesome &

However, having started "konsole" on one screen,
every following start request from menu issued on another screen
again starts "konsole" on the screen where it was started first.
This is the same behaviour which formerly drove me away from fluxbox.

Do you think this is related to the second fix in #607 as well ?

[Manfred-Knick]

UPDATE :
A) Test: Just back-ported that patch into awesome-3.5.6 to no different avail.
B) In contrast, this phenomenon does _not_ apply to e.g. kate.

[Manfred-Knick]

Luckily I found several deply buried hints concerning konsole using class _KUniqeApplication_ :
Resolution against mis-placement: add additional parameter "_--separate_".

My entries now read
. . . { "k--User", "konsole _--separate_ --profile User" },
. . . { "k--Root", "konsole _--separate_ --profile Root" },
. . . { "k--Shell", "konsole _--separate_ --profile Shell" },

WORKSFORME:

• + + Applying the after-starts described above,
• + + salted with the second fix in #607 back-ported into awesome-3.5.6
• + + and peppered with "_--separate_" for KDE's konsole terminal.
  Thanks.

[psychon]

However, having started "konsole" on one screen, every following start request from menu issued on another screen again starts "konsole" on the screen where it was started first.

That sounds more like konsole not starting a new process, but using dbus to tell the already-running konsole window "please open a new konsole window".

I would suggest that you change /home/manfred/bin/awesome-on-four and prefix each call to awesome with dbus-launch --exit-with-session so that each awesome gets its own dbus user session.

[Manfred-Knick]

CROSS-REFERENCE for Gentoo users:
https://bugs.gentoo.org/show_bug.cgi?id=571544
providing Gentoo-specific patches.

[Manfred-Knick]

Hi, Uli,
sorry for reporting only now.
Strange findings
for starting awesome with dbus-launch --exit-with-session, as you proposed:

Positive confirmation:
"--separate" is not needed as long as you exploit another screen
based upon a monitor connected to the same VGA.

Negative confirmation:
"--separate" is still needed the moment you start konsole on another screen
based upon a monitor connected to a different VGA !

FAIL-SAFE:
. . . start awesome with "dbus-launch --exit-with-session",
. . . but still start konsole with "--separate"

[Manfred-Knick]

CROSS-REFERENCE to Fedora's BugZilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1297487

[Manfred-Knick]

@ Uli :
Do you have any idea why and how dbus should recognize "different VGA HW" ?

[Manfred-Knick]

@ Uli :
As far as the package is concearned,
only the backported patch has to be incorporated into a next version of awesome.

But what about a good place containing all the rest of the gathered information and examples ?
Perhaps: What do you think about a sub-chapter entry like
. . . "Multiple awesome sessions for separate X11 screens"
in
. . . http://awesome.naquadah.org/wiki/Main_Page ->
. . . -> Documentation -> Installation & Basics For Users
to maintain it central (instead of out-dating distribution docu) ?
My Gentoo BUG 571544 above contains all the ingredients already,
and I'd volunteer for supplying some kind of "HowTo" draft text
to be reviewed by you.

[psychon]

I have no clue about the details of konsole nor that "different VGA HW" business.
For the wiki, well, it's a wiki. Feel free to write something there.

[Elv13]

@Manfred-Knick Can you describe your hardware and workflow?

I am in no authority to ask you to change your ways, and I wont. However, lets face it, this is a dead end. It will only get worst and worst are you are probably one of the very last people who use this exact method. Younger developers don't know it exists, older ones don't care. You asked in the other thread (and above) if KDE on wayland will fix your problems: no it wont.

Maybe there is other ways to achieve the same result using other technologies. Otherwise I will close all 3 issues as wont fix/upstream. I am trying to cleanup the backlog and close everything that realistically wont ever be fixed (or have no fix), unless @psychon disagree, I think this is one of them.

The options are:

If you have a single GPU that works:

• Use xrandr and rules to open your apps on the right window

If you have a single GPU, but it's broken and gives you a giant framebuffer across all screens unless you enable Zaphod/Xinerama (some low end AMD r600g GPUs):

• Awesome 4.0+ supports virtual screens inside Awesome itself, they are no longer tied to X11 screens. They will have their own tags and everything.

If you have multiple GPUs:

• Use Xinerama, it isn't perfect, but it's less broken than it used to be
  
  
  
  • If you want to run video games, use a second X server without Xinerama and switch with ctrl+alt+f8/f7
  
  
• Use AMD EyeFinity (exposed as xrandr)
• Use NVIDIA MOSAIC with virtual Awesome screens
• Use multiple X11 servers with Synergy
• Use Awesome 3.4

If all you want is being able to do things like DISPLAY=1.1 myapp, then Awesome now supports something called "startup notification". This allows to do the same thing but without the broken-ness. With some extra patches (https://github.com/awesomeWM/awesome/pull/1487), it will be more reliable than your current solution. You can create a bash alias and have awlaunch 3 myapp where 3 is the screen index.

[Manfred-Knick]

(c.f. reading attachments et al. would spare speculations)

To recapitulate the quest of the Grail:

Combine

• multiple driver-_incompatible_ VGAs (e.g., think of 'AMD + Intel + Matrox + NVIDIA')
• multiple monitors with _different_ resolutions @ each of them
• one keyboard, one mouse

into one rock-solid place to work at (e.g., think of 'control centre').

• Permanently attach pre-defined applications to fixed (virtual) screens;
• dis-able to move them around to other (non-fitting) monitors
• games: none, definitely
• preferred: resource-friendly, no unnecessary overhead

Let me stay silent about my former experiences with Xinerama ...
Given above requirements: _Can you seriously advise me to invest into another test?_

I'm eager and would be grateful to learn your tailored suggestion.

Sorry for not pointing out wayland as a mere rethoric question clearly enough.

Also, I'm pretty aware that esp. @ KDE, presumably nobody will care.

No, I do not mind to close all my bugs concerning Multiple separate X11 screens
if you / Uli think nobody cares / needs the information / find the warnings gathered within;
no urge to spoil the bug list:

• for all applications I really care, I proved awesome^^n works great!

[Elv13]

multiple driver-incompatible VGAs (e.g., think of 'AMD + Intel + Matrox + NVIDIA')

It usually works, but if by "Matrox" you mean the old PCI card from the 90's, then get something new. I tried adding a PCI card in my last setup and it only resulted in sluggishness. I recommand going either with cards designed "many screens" like the AMD EyeFinity or going with many NVIDIA GPUS. Mixing them only cause problems. It works, but barely. This isn't an Awesome limitation, if you understand how driver and synchronization work, you can see why this will always be a problem.

multiple monitors with different resolutions @ each of them

This works perfectly. I used to have this:

I also had this one with one of the screen over VNC to another laptop:

Can you seriously advise me to invest into another test?

Done right, it works. Nobody uses Zaphod because everybody who have these setups use Xinerama. It's as simple as that.

Permanently attach pre-defined applications to fixed (virtual) screens;
dis-able to move them around to other (non-fitting) monitors

Can be done using Awesome rules and some signal magic to prevent apps from leaving their screen.

preferred: resource-friendly, no unnecessary overhead

If you running your setup on a Pentium II, I suggest you get modern hardware. Anything newer than a Core2Duo+2Gb RAM will work just fine with 6 screens. I ran Xinerama on a Pentium4 with 4 screens and played games on it, so it can work.

[Manfred-Knick]

_Xeon E3 1275 -> Intel driver,
PNY Quadro -> NVidia driver,
specialized HW above all._

Mixing them only cause problems.

Dreaming like "All of this would be easier if only the customer would not have this technically based non-disputable request" does not help the slightest bit.

It works, but barely.

I deeply disagree.

This isn't an Awesome limitation

I already approved this multiple times, as positively confirmed as last line of my comment above.

Update the supported multiscreen modes

https://github.com/awesomeWM/awesome-www/pull/97

https://github.com/awesomeWM/awesome-www/pull/97/commits/7444e28d0f691bc986ed752335136908112e78e3

Completely dropping Zaphod mode multihead support from the list of supported features
is a clear and honest decision to be respected, of course.

With this rationale, I'll take over closing referencing bugs (Gentoo / KDE / et al.) as "OBSOLETE".

Thanks for every contribution - very much appreciated, indeed.

[Elv13]

Dreaming like "All of this would be easier if only the customer would not have this technically based non-disputable request" does not help the slightest bit.

I disagree, this is a totally legitimate answer. If you try to plug a mud brick to a PCI slot and call it a video card, don't ask for a driver. Xinerama works fine as long as the hardware you use it with does the same. As for Zaphod, it is a dead end:

• Most WMs dropped support
• Most applications dropped official support
• Large projects like KDE/Gnome have very exactly zero core developers using it as they now dogfood the Wayland graphic system. As it cannot easily be unit tested, it is doomed to regress.
• As far as I know, XDG-app/flatpack will downright disallow it by adding a proxy below the surfaces (and don't plan to add the necessary code for Zaphod as they expect X11 market share to drop)
• No Wayland compositor honor it as they "emulate" DISPLAY as surfaces
• No other modern operating systems use such setups (Oracle don't develop SunRays anymore and LTSP is dead-ish).
• Windows dropped support for non-optimus multi GPU-vendor (well, both AMD and NVIDIA dropped support in their driver), OSX (as far as I know) never supported it (each generation of PowerMac/MacPro only support 1 vendor). Even single vendor quad SLI/CrossFire is dead. This is no longer a common scenario on Linux either. Some parties are a little hypocrite and claim it is still supported, but I am quite sure it isn't tested. I myself had AMD+NVIDIA for the last time in 2013 and it was an unstable nightmare that barely worked.

I deeply disagree.

This is an unsustained claim. I used it for years and only had minor issues.

Completely dropping Zaphod mode multihead support from the list of supported features
is a clear and honest decision to be respected, of course.

It is an oversaw, that section hasn't been updated in years. v3.4.15 was the last release with this feature enabled. The full changelog mentions it:

commit 32d9a5b2ab8ab81241b2a0a1b4dffceca4212332
Author: Uli Schlachter <[email protected]>
Date:   Mon Aug 16 13:47:40 2010 +0200

    Remove support for zaphod mode

    This makes awesome support only a single X11 protocol screen. If you are still
    using zaphod mode, you can run multiple instances of awesome on the single
    screens, e.g.:

    DISPLAY=:1.0 awesome & DISPLAY=:1.1 awesome &

    Signed-off-by: Uli Schlachter <[email protected]>

[Manfred-Knick]

I really do not understand what you are fighting.
Sorry, but I'll spare my breath.

[rabite0]

Just found this after wondering if there's a way to make awesome manage separate X screens. I recently got a new laptop with a Nvidia GPU with Optimus (shame on me) and all other options are even more broken or won't work period. It's all compromises. xrandr doesn't work at all unless I'm using nouveau, since the laptop screen is connected to the Intel GPU, while all the ports are only connected to the Nvidia GPU. Xinerama kinda works, but that means no OpenGL at all on the laptop screen. Not being able to move windows between screens is barely an inconvenience to me.

So far using multiple awesome instances works well enough, the only thing I noticed is that switching between screens with the default key bind won't work, but that's to be expected if awesome doesn't have any special handling for this case. Can be fixed with xwarppointer though.

EDIT: xwarppointer alone doesn't actually change which screen/window gets the focus, so it's pretty useless by itself. If anyone encounters the same problem, here's a small script that cycles through all screens and changes the focus:

#!/bin/sh

xwarppointer screen +
WINDOW=$(xdotool getmouselocation | cut -d ":" -f 5)
xdotool windowfocus $WINDOW

[Manfred-Knick]

@ rabite0: From my latest digging for a new Notebook (more than half a year ago),
the following links are not really 'fresh' anymore,
but point to development in upcoming X Server versions in some distant future ...

A) PRIME GPU Offloading Improvement For GLXVND Merged For X.Org Server 1.21
[ https://www.phoronix.com/scan.php?page=news_item&px=GLXVND-Offload-Improve-1.21 ]

B) PRIME render offloading on Nvidia Optimus
[ https://forums.developer.nvidia.com/t/prime-render-offloading-on-nvidia-optimus/44439#5355181 ]

In order to circumvent all those troubles without any convincing hope for the foreseeable future, my consequence was to resort to a notebook with an i7-8750H processor, but _without_ any NVidia graphics which I finally found @ Tuxedo Computers - Business Line: "BC1507". And I'm still more than happy by it's value-for-money. Today, it would be a "TUXEDO Book BC1510".

[rabite0]

Maybe things will improve eventually, maybe not, but in my case I really do appreciate a dedicated GPU for playing games every now and then (works great now, btw), so I consciously bought one with a dGPU. The only problem is that the external outputs aren't connected to the iGPU, so to get a unified desktop (with no OpenGL/Vulkan AT ALL on the internal screen, otherwise Xinerama works) some interplay is required between drivers (RandR 1.4 support), which the Nvidia driver doesn't do yet.

That said, I'm very happy with this setup so far. The only thing that doesn't work is moving windows between screens, but I've done that rarely even when I could. I don't move my laptop around very often, so I don't really need any dynamic screen management and neither is battery life a concern to me since it's always plugged in. This might be a very niche case, but it's working better than I expected after realizing this problem with the outputs.

[Manfred-Knick]

Glad to hear your success!

That's exactly what people need to identify for themselves:

• Do I need a dGPU?
• Do I want to play? Do I have to do a lot of rendering? or CAD?
• Do I use it from battery (road) or with power provided most of the time?

Personally, in my office, I exploit several Xeon-based WS (Gentoo)
including iGPUs and NVidia dGPUs with multiple monitors connected,
but travelling, power efficiency really counts: 2 x akku = whole working day :-) .