search

awesomeWM / awesome

awesome window manager
https://awesomewm.org/
GNU General Public License v2.0
6.39k stars 597 forks source link

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

Closed Manfred-Knick closed 7 years ago

Manfred-Knick commented 8 years ago

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 commented 8 years ago

$ 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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

? "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 commented 8 years ago

Sorry, I meant "worked with awesome 3.4"

Manfred-Knick commented 8 years ago

@ 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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

psychon commented 8 years ago

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 commented 8 years ago

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

Manfred-Knick commented 8 years ago

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 commented 8 years ago

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

Manfred-Knick commented 8 years ago

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

Manfred-Knick commented 8 years ago

@ 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 commented 8 years ago

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 commented 7 years ago

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

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

If you have multiple GPUs:

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 commented 7 years ago

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

To recapitulate the quest of the Grail:

Combine

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

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:

Elv13 commented 7 years ago

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

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

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 commented 7 years ago

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 commented 7 years ago

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:

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 <psychon@znc.in>
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 <psychon@znc.in>
Manfred-Knick commented 7 years ago

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

rabite0 commented 4 years ago

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 commented 4 years ago

@ 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 commented 4 years ago

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 commented 4 years ago

Glad to hear your success!

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

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