Open Hugobsb opened 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.
i dont have multiple monitors so i cannot test this
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.
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.
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.
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
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.
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.
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.
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).
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 inconfig.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 thetagwin
window is only created in theupdatepreview
function and this is only called once (on startup in thesetup
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 theupdatebars
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.
@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.
@bakkeby got it. Thanks for the explanation 🤝
I updated the patch, you can try MinePro120/ddwm.
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?
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.
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.
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:
Super + D
to search and open something with the monitor focused;Super + Shift + Arrow keys
.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
andautorandr
to manage my displays.Here is what
~/.screenlayout/my-layout.sh
looks like:Note: I've modified ChadWM's
/scripts/run.sh
for the monitor setup. It looks like this:My neofetch info: