Open myrrc opened 1 month ago
Hi @myrrc,
that is an impressive amount of detail in your summary.
This doesn't sound like any issue I am familiar with, but it does remind me of the times when I have tested out command line flags for picom for example and have accidentally suspended the compositor by hitting Ctrl+z putting it in the background.
This does most likely not have anything to do with dwm itself, because besides having very few patches the window manager does not have anything directly to do with the actual drawing of the window content (it just handles window placement and restrictions and the like).
As such I think that this may be a compositor issue.
With the lack of a compositor I believe the drawing may fall back to the X server.
That you run startx in your .bash_profile
is suspicious, but I don't see any good reason why that should not work or interfere for that matter.
My recommendation would be to install Xephyr and try to run your dwm through that, spawn some terminals and see if you can reproduce the issue through that. Xephyr is a tool that lets you run a separate X11 session inside a window and can be quite useful to test and try things out.
(* in dwm of course the window manager handles the drawing of the bar)
(** on the Wayland side compositing and everything else must also be handled by the window manager)
Hi! Not quite confident what's the cause, or whether the cause is related to dwm, but maybe you could give me a hint. I'm using dwm (latest master) with the following patches:
The following key bindings are defined:
As a terminal emulator I use st (also latest master) with the following patches:
My main use case of st is launching it with /bin/bash, spawning some processes and suspending them via Ctrl+z. Sometimes, possibly when I mis-press Ctrl+z, dwm hangs with the following pattern:
killclient
, image of how it looks: https://ibb.co/wMB0S66.killall st
launched from dmenu sometimes helps -- all terminals are killed, but other windows become fully functional.killall dwm
orkillall Xorg
work, the only option is to restart the computer. They don't "work" in the sense the login window isn't shown, but rather just a blank screen with a cursor.I suppose it's dwm and not an st issue as, afaik multiple st instances don't share anything so issue with one st wouldn't affect other applications. I've tried building and launching dwm with debug info, killing it to generate a coredump, and changing xsessions file to redirect dwm log, but no useful info was found.
OS: Debian 13 trixie Xorg:
1:7.7+23.1
Login manager: none, x11 is started in.bash_profile
: