siduck / chadwm

Making dwm as beautiful as possible!
MIT License
2.25k stars 170 forks source link

Changing tags with two monitors #167

Open Hugobsb opened 1 year ago

Hugobsb commented 1 year ago

Update

I'm writing this here in the top to make it easier for anyone finding a solution.

It's an approach that remediates the problem.

For me, it was just a matter of deactivating tag_preview. This can be achieved by changing this from 1 to 0 and recompiling.

Expected behavior

Whenever I change tags with opened screens in both monitors, I imagine it should either (or maybe both via configuration? I don't know):

What happens

When I'm on my primary monitor (on the right), I can freely change tags.

It's worth mentioning that the left monitor keeps the same tag and screen opened while I change tags on the right monitor.

However, whenever I try to change a tag on my left monitor (not primary) when I have a screen on it, I'm kicked out of the session (logoff) and then when I login again, my primary monitor is changed to be the left one and I'm not able to use the right one. Even after running the autorandr <profile> command.

I tried to:

Note: If I reboot, everything gets back to normal, but I can trigger the issue back anyways.

How to trigger the issue

Using two monitors, try to move to other tags in the monitor that is not the primary one.

Video demonstrating the issue

https://drive.google.com/file/d/1KYiMYOuuZo1P1nQPWPUaik48jBfhofrn/view?usp=sharing

Note: I'm sorry if I sounded weird or if I said something wrong. English is not my native language.

Technical information

I've installed Arco Linux ISO B of ChadWM. Plus, I'm using arandr and autorandr to manage my displays.

Here is what ~/.screenlayout/my-layout.sh looks like:

#!/bin/sh
xrandr --output HDMI-0 --primary --mode 1920x1080 --pos 1920x0 --rotate normal --output DP-0 --off --output DP-1 --off --output HDMI-1 --off --output DP-2 --off --output DP-3 --off --output HDMI-1-1 --off --output HDMI-1-2 --mode 1920x1080 --pos 0x0 --rotate normal

Note: I've modified ChadWM's /scripts/run.sh for the monitor setup. It looks like this:

#!/bin/sh

#xrdb merge ~/.Xresources 
#xbacklight -set 10 &
#xset r rate 200 50 &

function run {
 if ! pgrep $1 ;
  then
    $@&
  fi
}
run "dex $HOME/.config/autostart/arcolinux-welcome-app.desktop"
#run "xrandr --output VGA-1 --primary --mode 1360x768 --pos 0x0 --rotate normal"
#run "xrandr --output HDMI2 --mode 1920x1080 --pos 1920x0 --rotate normal --output HDMI1 --primary --mode 1920x1080 --pos 0x0 --rotate normal --output VIRTUAL1 --off"
#run xrandr --output eDP-1 --primary --mode 1368x768 --pos 0x0 --rotate normal --output DP-1 --off --output HDMI-1 --off --output DP-2 --off --output HDMI-2 --off
#run xrandr --output LVDS1 --mode 1366x768 --output DP3 --mode 1920x1080 --right-of LVDS1
#run xrandr --output DVI-I-0 --right-of HDMI-0 --auto
#run xrandr --output DVI-1 --right-of DVI-0 --auto
#run xrandr --output DVI-D-1 --right-of DVI-I-1 --auto
#run xrandr --output HDMI2 --right-of HDMI1 --auto
#autorandr horizontal
#run "autorandr horizontal"
run "autorandr two_monitors"
run "nm-applet"
run "pamac-tray"
#run "variety"
run "xfce4-power-manager"
run "blueberry-tray"
run "/usr/lib/xfce4/notifyd/xfce4-notifyd"
run "/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1"
picom -b  --config ~/.config/arco-chadwm/picom/picom.conf &
run "numlockx on"
run "volumeicon"
#run "pa-applet"
sxhkd -c ~/.config/arco-chadwm/sxhkd/sxhkdrc &
run "nitrogen --restore"
run "conky -c $HOME/.config/arco-chadwm/conky/system-overview"
#you can set wallpapers in themes as well
#feh --bg-fill /usr/share/backgrounds/archlinux/arch-wallpaper.jpg &
#feh --bg-fill /usr/share/backgrounds/arcolinux/arco-wallpaper.jpg &
#feh --bg-fill ~/.config/arco-chadwm/wallpaper/chadwm.jpg &
#feh --bg-fill ~/.config/arco-chadwm/wallpaper/chadwm1.png &
#feh --randomize --bg-fill /home/erik/Insync/Apps/Wallhaven/*

#nitrogen --set-zoom-fill --random /home/erik/Insync/Apps/Desktoppr/ --head=0
#nitrogen --set-zoom-fill --random /home/erik/Insync/Apps/Desktoppr/ --head=1

#wallpaper for other Arch based systems
#feh --bg-fill /usr/share/archlinux-tweak-tool/data/wallpaper/wallpaper.png &
#run applications from startup

#run "insync start"
#run "spotify"
#run "ckb-next -b"
#run "discord"
#run "telegram-desktop"
#run "dropbox"

pkill bar.sh
~/.config/arco-chadwm/scripts/bar.sh &
while type chadwm >/dev/null; do chadwm && continue || break; done

My neofetch info:

                    /-                      hugobsb@hugo-arco
                   ooo:                     -----------------
                  yoooo/                    OS: ArcoLinux
                 yooooooo                   Host: B360M AORUS Gaming 3
                yooooooooo                  Kernel: 6.1.46-1-lts
               yooooooooooo                 Uptime: 17 mins
             .yooooooooooooo                Packages: 1707 (pacman)
            .oooooooooooooooo               Shell: zsh 5.9
           .oooooooarcoooooooo              Resolution: 1920x1080, 1920x1080
          .ooooooooo-oooooooooo             DE: chadwm
         .ooooooooo-  oooooooooo            WM: dwm
        :ooooooooo.    :ooooooooo           Theme: Arc-Dark [GTK2/3]
       :ooooooooo.      :ooooooooo          Icons: Sardi-Arc [GTK2/3]
      :oooarcooo         .oooarcooo         Terminal: alacritty
     :ooooooooy           .ooooooooo        CPU: Intel i7-8700 (12) @ 4.600GHz
    :ooooooooo   /ooooooooooooooooooo       GPU: Intel CoffeeLake-S GT2 [UHD Graphics 630]
   :ooooooooo      .-ooooooooooooooooo.     GPU: NVIDIA GeForce RTX 3060
  ooooooooo-             -ooooooooooooo.    Memory: 2.29GiB / 15.48GiB (14%)
 ooooooooo-                 .-oooooooooo.   GPU Driver: Gigabyte Technology Co., Ltd CoffeeLake-S GT2 [UHD Graphics 630] [1458:d000]
ooooooooo.                     -ooooooooo   CPU Usage: 8%
                                            Disk (/): 37G / 92G (43%)
                                            Font: Noto Sans 11 [GTK2/3]
Hugobsb commented 1 year ago

I tried to replicate the issue in different ways to improve the description, that's why it's a bit edited. I even thought the problem was fixed suddenly, but what happens is that I must have an opened screen on the not primary monitor to trigger the issue.

siduck commented 1 year ago

i dont have multiple monitors so i cannot test this

Hugobsb commented 1 year ago

i dont have multiple monitors so i cannot test this

Well, I don't have much knowledge on the necessary tecnologies to fix this, I guess. I'd gladly share my screen on Discord or something like that to help fix the issue, but to be honest, it can be a waste of your time since you don't use multiple monitors.

I don't know if I see a feasible solution to this. I can try to manage it myself, find a friend who is able to fix the problem and post the solution here, I don't know. Whatever fits for you.

MinePro120 commented 1 year ago

Test with vanilla dwm and a clean installation and if the issue persists, send a detailed bug report to the appropriate suckless mailing list (see here). In fact, this is the proper way to troubleshoot chadwm; chadwm is just a fork of dwm with some patches and tweaks.

Hugobsb commented 1 year ago

Test with vanilla dwm and a clean installation and if the issue persists, send a detailed bug report to the appropriate suckless mailing list (see here). In fact, this is the proper way to troubleshoot chadwm; chadwm is just a fork of dwm with some patches and tweaks.

Thank you :) understood. I'll let you know.

Hugobsb commented 1 year ago

Test with vanilla dwm and a clean installation and if the issue persists, send a detailed bug report to the appropriate suckless mailing list (see here). In fact, this is the proper way to troubleshoot chadwm; chadwm is just a fork of dwm with some patches and tweaks.

Installing DWM was easier than I thought. I'm attaching a video showing that in DWM it works:

https://github.com/siduck/chadwm/assets/58279735/f27d4843-b7bb-48c8-a249-7fd1ef7514a0

bakkeby commented 1 year ago

It is possible to test multi-monitor behaviour using Xephyr with the Xinerama RANDR extension, e.g.

Xephyr +extension RANDR +xinerama -screen 1000x1080 -screen 1000x1080 -ac :3

Then running the window manager under the designated display.

DISPLAY=:3 ./dwm

But even with that I can't replicate chadwm crashing when changing tags on the second monitor.

Hugobsb commented 1 year ago

It is possible to test multi-monitor behaviour using Xephyr with the Xinerama RANDR extension, e.g.

Xephyr +extension RANDR +xinerama -screen 1000x1080 -screen 1000x1080 -ac :3

Then running the window manager under the designated display.

DISPLAY=:3 ./dwm

But even with that I can't replicate chadwm crashing when changing tags on the second monitor.

Hmm, that's weird. To replicate the crashes, all I have to do is open a screen on the secondary monitor and try to change tags.

I will remove everything regarding chadwm and clone again to be 200% sure I have everything updated here. My local files may be older, even though the installation process I've followed should bring the most recent changes.

Hugobsb commented 1 year ago

I could get a log of the problem:

dwm: fatal error: request code=53, error code=9
X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  53 (X\_CreatePixmap)
  Resource id in failed request:  0x0
  Serial number of failed request:  9160
  Current serial number in output stream:  9161

Edit: I tried this, for example, searching for a fix to it, no success until then.

bakkeby commented 1 year ago

I see what you mean now.

all I have to do is open a screen on the secondary monitor and try to change tags

By "open a screen" in this context refers to hotplugging (or enabling) a new monitor while the window manager is running.

Also tag_preview will need to be enabled in config.h I believe; if you disable that then you should in principle not have this issue.

The problem is that selmon->tagwin does not exist for the new monitor because the tagwin window is only created in the updatepreview function and this is only called once (on startup in the setup function).

This is something that was an issue in very early versions of the tag preview patch and the implementation here looks like an early adoption. The tag preview patch on the suckless site creates the tagwin window in the updatebars function if it does not already exist.

As an end user I'd recommend just disabling the config for now until the issue is addressed (assuming that there is interest in fixing the issue).

Hugobsb commented 1 year ago

I see what you mean now.

By "open a screen" in this context refers to hotplugging (or enabling) a new monitor while the window manager is running.

Also tag_preview will need to be enabled in config.h I believe; if you disable that then you should in principle not have this issue.

The problem is that selmon->tagwin does not exist for the new monitor because the tagwin window is only created in the updatepreview function and this is only called once (on startup in the setup function).

This is something that was an issue in very early versions of the tag preview patch and the implementation here looks like an early adoption. The tag preview patch on the suckless site creates the tagwin window in the updatebars function if it does not already exist.

As an end user I'd recommend just disabling the config for now until the issue is addressed (assuming that there is interest in fixing the issue).

Hmm, by "open a screen" I mean open any application or window on the left monitor and then try to change tags. But what you said fits perfectly in the issue, it's a better description that goes directly to the point, I think.

And I'm a bit confused because my autorandr <profile> is not concurrent (autorandr <profile> &) and is written before the initialization of chadwm at run.sh. But no problem at all.

Anyways, turning off the tag_preview fixed the problem. I appreciate *a lot* your help, many many thanks for you time, @bakkeby, @MinePro120 and @siduck :D


I don't have any problem if you want to close the issue, I'll just not close it to give you the decision.

bakkeby commented 1 year ago

@Hugobsb

And I'm a bit confused because my autorandr is not concurrent (autorandr &) and is written before the initialization of chadwm at run.sh.

If we use a simpler example of using startx and a .xinitrc file and you were to use an xrandr command to explicitly set the monitor arrangement:

xrandr --output DisplayPort-0 --off --output DVI-D-0 --mode 1920x1080 --pos 0x0 --rotate left --output HDMI-A-0 --primary --mode 2560x1080 --pos 1080x648 --rotate normal &
exec dwm

The & here would make the xrandr command spawn in the background and the script would continue and run exec dwm. This can lead to a race condition where the xrandr may or may not complete before the window manager has initialised.

If it completes before then dwm will start up with the desired monitor positions, but if it completes after then dwm will start up with whatever setup was there initially. When the xrandr command completes the X server will send a ConfigureNotify event to the window manager at which point it will find out that there is a new monitor and initialise that and so on.

Dropping the & from the command more or less eliminates this race condition in this scenario.

I am not overly familiar with how autorandr works, but I'd assume that the command either forks itself or that it just says to use the given profile when detecting monitors. By that I mean that the race condition as described with the xrandr example may be there regardless of whether you run the autorandr command in the background or not, and it may happen so quickly that it is not noticeable on startup.

Hugobsb commented 1 year ago

@bakkeby got it. Thanks for the explanation 🤝

MinePro120 commented 1 year ago

I updated the patch, you can try MinePro120/ddwm.

Hugobsb commented 1 year ago

I updated the patch, you can try MinePro120/ddwm.

Nice :D do you want me to help test this branch in my machine or is it fine already?

MinePro120 commented 1 year ago

Nice :D do you want me to help test this branch in my machine or is it fine already?

You can test it, that would be helpful.

Hugobsb commented 11 months ago

I apologize for the delay in my response; I have been preoccupied with some complex personal matters.

I wanted to share an update before I return from my travels post-holidays. I suspect that the issue was related to the BIOS internal graphics settings being enabled. Upon disabling this setting and successfully connecting a second cable to the graphics card, the problem ceased to occur.

I suppose this was already expected here though.