post: dwm-debugging edit
Prithu Goswami pg@prithu.dev
Sun, 18 Feb 2024 23:06:18 +0530
1 files changed,
132 insertions(+),
80 deletions(-)
jump to
M
content/posts/debugging-dwm.md
→
content/posts/debugging-dwm.md
@@ -2,19 +2,24 @@ ---
title: "Debugging dwm to fix an annoying bug" date: 2024-02-17T18:19:23+05:30 draft: true -description: "Me debugging my window manager and learning a bit about it. This post is going to be me going through the process of debugging." +description: "Going through the source code of dwm written in C and debugging it using gdb to fix an annoying issue." --- -I use [dwm](https://dwm.suckless.org) as my window manager and I always wanted to hack on it since I started using it. This is just going to be me explaining some parts of the dwm codebase that I understood while debugging an annoying issue I was facing with it and how I learnt to not be overwhelmed by the codebase. +I use [dwm](https://dwm.suckless.org) as my window manager and I always wanted +to hack on it since I started using it. This post is just going to be a lot of +snippets from dwm source code with my explanatiion on it as I understand it +myself and sharing what I learnt while debugging dwm along the way. I wanted to +fix an annoying issue I was facing with dwm and this blog post serves as a +documentation of how I fixed it. It's also a reason to practice my writing. -The annoying issue that I was facing with my dwm setup was related to a scratchpad patch. I use a scratchpad terminal using the [scratchpad patch](https://dwm.suckless.org/patches/scratchpad/). It gives me an extra tag called the scratchpad where I can have a floating terminal window wherever I want. +The annoying issue that I was facing with my dwm setup was related to a scratchpad patch. I use a scratchpad terminal using the [scratchpad patch](https://dwm.suckless.org/patches/scratchpad/) which gives me an extra tag called the scratchpad tag where I can have a floating terminal window wherever I want. Like this: {{< video src="https://m.prithu.dev/dwm-debug-1-scratchpad-demo.mp4" type="video/mp4" loop=true autoplay=true >}} -I have [nnn](https://github.com/jarun/nnn) running in a tmux window (I usually +I usually have [nnn](https://github.com/jarun/nnn) running in a tmux window (I usually have a tmux session called `scratchpad` for this) which let's me quickly browse and open files. I also have other tmux windows for quick commands or to note down something.@@ -23,13 +28,13 @@ {{< aside >}}
### A little about dwm tags -DWM has the concept of "tags" and not workspaces. Those numbers on the top-left are tags. A window can be part of one or more tags. It's a little confussing when coming from other window managers, but this concept makes sense when you start using it. Example, let's say I have browser window on tag 2 and 4, so when I move from 2 to 4 the browser window appears on both the tags. DWM also allows you look at two tags at the same time. Which means all the windows in tag 2 and 4 appear at the same time. Might seem very weird for someone coming from another window manager where the numbers usually represent a workspace. Tags are a different concept, they aren't workspaces. +DWM has the concept of "tags" and not workspaces. Those numbers on the top-left are tags. A window can be part of one or more tags. It's a little confussing when coming from other window managers, but this concept makes sense when you start using it. Example, let's say I have a browser window on tag 2 and 4, so when I move from 2 to 4 the browser window appears on both the tags. DWM also allows you look at two tags at the same time. Which means all the windows in tag 2 and 4 appear at the same time. Might seem very weird for someone coming from another window manager where the numbers usually represent a workspace, but tags are different than workspaces. {{< /aside >}} ## The Problem -Now, the problem is when I launch programs from the `scratchpad`, they stick around in the scratchpad tag too, which shouldn't happen. This means that the image viewer window has the tags `1` and `6` set (6 is the internal number for the scratch tag). Now when I move to another tag. (Note: there is no such thing as "moving" to another tab, just that you set a tag visible or invisible) and open the scratchpad there (make `scratch` tag visible) the image viewer opens there as well. This is pretty annoying. The expected behaviour for me is I want the scratchpad to launch GUI applications on the tag "behind" the scratchpad (i.e the other tag that is visible along with the scratchpad) +Now, the problem is when I launch programs from the `scratchpad`, they stick around in the scratchpad tag too, which shouldn't happen. This means that the video player window has the tags `1` and `6` set (6 is the internal number for the scratch tag). Now when I move to another tag, `2`. (Note: there is no such thing as "moving" to another tab, just that you set a tag visible or invisible) and open the scratchpad there (make `scratch` tag visible) the video player appears there as well. This is pretty annoying. The expected behaviour for me is I want the scratchpad to launch GUI applications on the tag "behind" the scratchpad (i.e the other tag that is visible along with the scratchpad) and not in the scratchtag itself. Here's a video of the problem (You can see how frustrated I am by the chaotic mouse movement at the end):@@ -70,8 +75,8 @@
``` Starting from the `main()` function We see some argument checks, check if we can open the X display, check for another wm running, etc. Then some function calls: -- `setup()` - sets up things for dwm like initializing monitor and allocating space for some structs. -- `scan()` - Scans the X server for all windows there are. Goes through every window using the [`XQueryTree()`](https://tronche.com/gui/x/xlib/window-information/XQueryTree.html) function and calls `manage()` for each window it finds. This is when I skim through `manage()` a little. It seems to me in the first read that this function is actually responsible for "registering" an X window as a "client" of dwm. Ok, we'll come back to this later. +- `setup()` - sets up things for dwm like initializing the Monitors (an important struct, I'll touch later) and allocating space for some other variables. +- `scan()` - Scans the X server for all windows there are. It goes through every window using the [`XQueryTree()`](https://tronche.com/gui/x/xlib/window-information/XQueryTree.html) function and calls [`manage()`](#the-manage-function) for each window it finds. This is when I skim through `manage()` a little. It seems to me in the first read that this function is actually responsible for "registering" an X window as a "client" of dwm. Ok, we'll come back to this later. - `run()` - function which is nice and small and has the main event loop. Let's explore this further:@@ -110,7 +115,7 @@ [UnmapNotify] = unmapnotify
}; ``` -To me, the ones that seemed of my interest were `Expose`, `MappingNotify`, `MapRequest`. Now I started to read about the different [XEvents](https://tronche.com/gui/x/xlib/events/types.html). `Expose` is an event produced when a part of window is visible. `MappingNotify` seems like something related to keyboard/pointer mapping, which is unrelated to windows spawning. At this point I had read a little about how one creates a window and "maps" it in X. X refers to Mapping a window as the actual process of drawing it on the screen. You can create a window, but not displayed yet. A call to `XMapWindow()` is what makes the window visible on the screen. From the [docs](https://tronche.com/gui/x/xlib/window/XCreateWindow.html) of `XCreateWindow()`: +To me, the ones that seemed of interest were `Expose`, `MappingNotify`, `MapRequest`. Now I started to read about the different [XEvents](https://tronche.com/gui/x/xlib/events/types.html). `Expose` is an event produced when a part of window is visible. `MappingNotify` seems like something related to keyboard/pointer mapping, which is unrelated to windows spawning. At this point I had read a little about how one creates a window and "maps" it in X. X refers to Mapping a window as the actual process of drawing it on the screen. You can create a window, but not displayed yet. A call to `XMapWindow()` is what makes the window visible on the screen. From the [docs](https://tronche.com/gui/x/xlib/window/XCreateWindow.html) of `XCreateWindow()`: > The created window is not yet displayed (mapped) on the user's display. To display the window, call XMapWindow().@@ -119,6 +124,7 @@
> The X server can report MapRequest events to clients wanting information about a different client's desire to map windows That's it! DWM "subscribes" to this event because it wants to know which windows it needs to be managing. Now, need to look at what `maprequest` handler does: + ```c void@@ -163,45 +169,9 @@
``` -Okay then! `manage()` is where it's at then. I mean, the clue is in the word "manage". It is a window "manager" we are dealing with after all. - -Here are the first few lines of the function. - - -```c -void -manage(Window w, XWindowAttributes *wa) -{ - Client *c, *t = NULL; - Window trans = None; - XWindowChanges wc; - - c = ecalloc(1, sizeof(Client)); - c->win = w; - /* geometry */ - c->x = c->oldx = wa->x; - c->y = c->oldy = wa->y; - c->w = c->oldw = wa->width; - c->h = c->oldh = wa->height; - c->oldbw = wa->border_width; - - updatetitle(c); - if (XGetTransientForHint(dpy, w, &trans) && (t = wintoclient(trans))) { - c->mon = t->mon; - c->tags = t->tags; - } else { - c->mon = selmon; - applyrules(c); - } +Okay then! `manage()` is where it's at then. I mean, the clue is in the word "manage". It is a window "manager" we are dealing with after all. Before going into the `manage()` function, I'd like to mention the `Monitor` and `Client` structs. -// ... -// ... -``` - -`manage()` gets a `Window` type (which is an `unsigned long` type underneath) which is an id of the window. It also gets a `XWindowAttributes` type which is a structure defining several attributes like `x`, `y` coordinates, `width`, `height`, `border_width`, etc. -Before we go further, let's see what a `Client` and a `Monitor` is: - -{{< aside >}} +### Monitor and Client structs `Monitor` and `Client` are the main structs of the program. Monitors hold clients and a client is a representation of a window that dwm is currently managing.@@ -216,9 +186,9 @@ int by; /* bar geometry */
int ty; /* tab bar geometry */ int mx, my, mw, mh; /* screen size */ int wx, wy, ww, wh; /* window area */ - unsigned int seltags; + unsigned int seltags; /* used to select which tagset is active */ unsigned int sellt; - unsigned int tagset[2]; + unsigned int tagset[2]; /* a tagset represents tags as int set */ int showbar, showtab, topbar, toptab; Client *clients; Client *sel;@@ -242,7 +212,7 @@ int x, y, w, h;
int oldx, oldy, oldw, oldh; int basew, baseh, incw, inch, maxw, maxh, minw, minh; int bw, oldbw; - unsigned int tags; + unsigned int tags; /* The tags the client is assigned */ int isfixed, isfloating, isurgent, neverfocus, oldstate, isfullscreen; int fakefullscreen; Client *next;@@ -252,15 +222,70 @@ Window win;
}; ``` +{{< aside >}} + +### Global static variables + There's `selmon` and `mons` global static variables that live throughout the -lifecycle of the program are one of the main variables of the program. `selmon` -points to the current selected monitor where the user's cursor is and `mons` -points to the first monitor. Ech monitor points to the next monitor in a linked -list fashion. +life-cycle of the program. They are one of the main variables of the program. +`selmon` points to the current selected monitor and `mons` points to the first +monitor. Ech monitor points to the next monitor in a linked list fashion. {{< /aside >}} + +### The manage() function + +Here are the first few lines of the function. + +```c +void +manage(Window w, XWindowAttributes *wa) +{ + Client *c, *t = NULL; + Window trans = None; + XWindowChanges wc; + + c = ecalloc(1, sizeof(Client)); + c->win = w; + /* geometry */ + c->x = c->oldx = wa->x; + c->y = c->oldy = wa->y; + c->w = c->oldw = wa->width; + c->h = c->oldh = wa->height; + c->oldbw = wa->border_width; + + updatetitle(c); + if (XGetTransientForHint(dpy, w, &trans) && (t = wintoclient(trans))) { + c->mon = t->mon; + c->tags = t->tags; + } else { + c->mon = selmon; + applyrules(c); + } +// ... +// skipped lines +// ... + c->bw = borderpx; + + if (!strcmp(c->name, scratchpadname)) { + c->mon->tagset[c->mon->seltags] |= c->tags = scratchtag; + c->isfloating = True; + c->x = c->mon->wx + (c->mon->ww / 2 - WIDTH(c) / 2); + c->y = c->mon->wy + (c->mon->wh / 2 - HEIGHT(c) / 2); + } + + wc.border_width = c->bw; + XConfigureWindow(dpy, w, CWBorderWidth, &wc); +// ... +// skipped lines +// ... +``` + +`manage()` gets a `Window` type (which is an `unsigned long` type underneath) which is an id of the window. It also gets a `XWindowAttributes` type which is a structure defining several attributes like `x`, `y` coordinates, `width`, `height`, `border_width`, etc. + + We see that a new client structure gets allocated and its fields are populated with relevant info—some coming from `XWindowAttributes *wa` and some being calculated. At the end of the function we see a call to `attach(c)` which prepends the client to the linked list of clients of the monitor it's on. So this tells us the purpose of the function is indeed to create a client (which is just a window representation within dwm) and assign it to a monitor. ```c@@ -277,7 +302,7 @@
Down in this function I see this line `selmon->tagset[selmon->seltags] &= ~scratchtag;`. `selmon` is the current selected monitor and is a global static variable of `Monitor` type. -A `tagset` is an int set that uses an unsigned int and represents a set of the current selected tags of the monitor. Only one of the index of `tagset` is the current selected `tagset` which is pointed by `setltags` and the other is the previous set of selected tags. This is to implement an Alt+Tab like functionality for switching between tags. The line `selmon->tagset[selmon->seltags] &= ~scratchtag;` is simply removing the scratchpad's tag from the tag set. `scratchtag` holds the value 32 (0b100000). I have 5 defined tags and scratchpad's tag is simply the 6th one. The line sounds to be as if telling we want to only have scratchpad in the scratchtag and no other window, which is also apparent by the lines that follow it: +A `tagset` is an int set that uses an unsigned int and represents a set of the current selected tags of the monitor. Only one of the index of `tagset` is the current selected `tagset` which is pointed by `setltags` and the other is the previous set of selected tags. This is to implement an Alt+Tab like functionality for switching between tags. `c->tags` is the set of tags the client is assigned to. The line `selmon->tagset[selmon->seltags] &= ~scratchtag;` is simply removing the scratchpad's tag from the tag set. `scratchtag` holds the value 32 (0b100000). I have 5 defined tags and scratchpad's tag is simply the 6th one. The line sounds to be as if telling we want to only have scratchpad in the scratchtag and no other window, which is also apparent by the lines that follow it: ```c selmon->tagset[selmon->seltags] &= ~scratchtag;@@ -290,10 +315,13 @@ }
``` Only if the new window has a title of "scratchpad" (value of `scratchpadname`) do we allow it to have the scratchpad tag. -By removing the scratchpad tag before a new window is being mapped (wants to be displayed), the patch author made sure that the scratchtag is is not active when a new window comes in as we don't want any other window in the scrath tag other than the one that's named "scratchpad" and I think it's there exactly for the reason for the problem I am facing so that we don't get a new window in the scratch tag as well, then why does that still happen? +By removing the scratchpad tag before a new window is being mapped (wants to be displayed), the patch author made sure that the scratchtag is is not active when a new window comes in as we don't want any other window in the scrathtag other than the one that's named "scratchpad". It seems like the purpose of that line is exactly to prevent the problem I am facing—to have a window spawn in the scratch tag when the scratchtag is active—why then does that still happen? + +Now, this is a big function and you can understand only so much by just reading the code. We need to be able to debug it and be able to step over the code as dwm runs to learn more about what it does. + ## Firing up the GNU debugger -Now, this is a big function and it's not easy to understand what's going on by just reading the code. We need to be able to debug dwm and be able to step over the code as dwm runs. So I started looking at how we could debug dwm and I learnt about [Xephyr](https://wiki.archlinux.org/title/Xephyr). Xephyr is a nested X server that runs as an X application. It would allow me to start another X server and run dwm on it and then I could debug dwm. + So I started looking at how we could debug dwm and I learnt about [Xephyr](https://wiki.archlinux.org/title/Xephyr). Xephyr is a nested X server that runs as an X application. It would allow me to start another X server and run dwm on it and then I could debug dwm. Now to debug it we need to compile dwm with debugging enabled so that gdb can look up symbols and make debugging easy. Adding the `-g` in `CFLAGS` in `config.mk`:@@ -303,6 +331,7 @@ -CFLAGS = -std=c99 -pedantic -Wall -Wno-deprecated-declarations -Os ${INCS} ${CPPFLAGS}
+CFLAGS = -g -std=c99 -pedantic -Wall -Wno-deprecated-declarations -Os ${INCS} ${CPPFLAGS} ``` +and then running dwm in Xephyr using gdb: ``` $ Xephyr -br -ac -noreset -screen 800x600 :2 &@@ -318,7 +347,7 @@ Here's a video of me reproducing the same problem with Xephyr and gdb
{{< video src="https://m.prithu.dev/dwm-debug-3-dwm-xephyr-gdb.mp4" type="video/mp4" loop=true autoplay=true >}} - +### gdb session First I want to confirm whether the new window being launched when the scratchpad is open, does have the scratchpad tag. From the Xephyr X instance, I open a scratchpad and run `eog ~/pictures/someimage.jpg` from the scratchpad terminal. I then send a SIGINT by pressing Ctrl-C in gdb window to get a gdb prompt. We can see now print the `selmon->clients->tags` value. Which will show us the tags of the last spawned window—the latest client managed under dwm.@@ -346,11 +375,9 @@
And yes, indeed we do see the value 33 (0b100001) which means that the client is on the scratchpad tag (0b100000) and tag 1 (0b000001). Now to find out why does that happen even though we have the line `selmon->tagset[selmon->seltags] &= ~scratchtag;` as a failsafe which makes sure we don't spawn any windows in the scratch tag? Well this is where stepping through the code line by line will help. We need to check the value of `c->tags` and what changes it during the run. -I open a new debug session and set a breakpoint at the line `c = ecalloc(1, sizeof(Client));` in `manage()`. When a new window is created (mapped) by launching a GUI application, we should hit the breakpoint as dwm tries to add the window in the list of managed clients. I open a scratchpad again and the breakpoint is hit, because the and run `eog ~/pictures/someimage.jpg` and this time we hit the breakpoint once for scratchpad terminal when It spawns for the first time; I just `continue`, and the second time the breakpoint is hit for the launch of the `eog` window. - +### debugging manage() ``` - ~/src/dwm (mybuild) › gdb ./dwm GNU gdb (GDB) 14.1 Copyright (C) 2023 Free Software Foundation, Inc.@@ -365,6 +392,10 @@ <https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) y [Detaching after fork from child process 4106464] ``` + +I start a new debug session and set a breakpoint at the line `c = ecalloc(1, sizeof(Client));` in `manage()`. When a new window is created (mapped) by launching a GUI application, we should hit the breakpoint as dwm tries to add the window in the list of managed clients. I open a scratchpad and run `eog ~/pictures/someimage.jpg &` and we hit a breakpoint! + + ``` Breakpoint 1, manage (w=4194310, wa=0x555555564020 <wa>) at dwm.c:1306@@ -373,15 +404,14 @@ (gdb) c
Continuing. ``` -We hit the first breakpoint. This is when I launch the scratchpad for the first time. That's when the terminal window is created. +This breakpoint is hit when I launch the scratchpad for the first time. That's when the terminal window is created. Let's continue. ``` Breakpoint 1, manage (w=6291463, wa=0x555555564020 <wa>) at dwm.c:1306 1306 c = ecalloc(1, sizeof(Client)); (gdb) n -1309 c->x = c->oldx = wa->x; ``` -The second breakpoint is hit when I launch `eog ~/pictures/somepic.jpg &`. The first line (1306) simply allocates space for the new client. +The second breakpoint is hit when I run `eog ~/pictures/somepic.jpg &`. This is when the image viwer window is created. The first line (1306) simply allocates space for the new client. ``` (gdb) display c->name 1: c->name = '\000' <repeats 255 times>@@ -393,6 +423,7 @@ ```
I use the `display` command here (Which I learnt in this process) to always print the values I am interested in after each line executes—`c->name` (Name of the client:X Window title), `c->tags`(The tags the client get's assigned, `selmon->tagset` (The current active tags of the current selected monitor: recall that the new window gets assigned the tags of the scratchpad and the tag that is active along with the scratchpad too) ``` +1309 c->x = c->oldx = wa->x; (gdb) n 1310 c->y = c->oldy = wa->y; 1: c->name = '\000' <repeats 255 times>@@ -450,7 +481,7 @@ 1: c->name = "20230903_153036.jpg", '\000' <repeats 236 times>
2: c->tags = 33 3: selmon->tagset = {33, 2} ``` -And here we have it, our culprit! After the call to `applyrules(c)` we have c->tags change value to `selmon->tagset[selmon->seltags]` which is 33 (`0b100001`) +**And here we have it—our culprit!** After the call to `applyrules(c)` we have `c->tags` change its value to `33` (`0b100001`) which is the value of `selmon->tagset[selmon->seltags]` as well. ``` (gdb) n@@ -480,7 +511,7 @@ 2: c->tags = 33
3: selmon->tagset = {1, 2} ``` -We don't enter the scratchpad loop because this isn't a scratchpad window. It's +We don't enter the scratchpad loop because this isn't a scratchpad window—it's the eog image viewer. The line `selmon->tagset[selmon->seltags] &= ~scratchtag` is too late. The client has already been assigned the scratchpad tag.@@ -496,10 +527,9 @@ ...
``` And as I go through the whole function, I find that `c->tags` isn't changed anywhere else. -I learnt about the `display` command in this process which I thought what `watch` actually was. `watch` breaks when a variable's value changes, while display just prints the value of the variable after each step. -TL;DR -There's a function `applyrules(c)` that takes `Client` type add modifies the client `c`—which I completely skipped over while reading the code. I didn't bother to look at what it did. But when I saw the value change, everything clicked! The `c->tags` value was being changed by `applyrules(c)` way before the line `selmon->tagset[selmon->seltags] &= ~scratchtag` is executed. I took a look at `applyrules(c)` but already guessed what it does. It is responsible for applying some rules to the new client but also adds tags to new clients, which I didn't suspect during my first read. +### applyrules(c) is the culprit +This function is what modifies the `c->tag` value in `manage()`. It takes `Client` type add modifies the client `c`—which I completely skipped over while reading the code. I didn't bother to look at what it did. But when I saw the value change, everything clicked! The `c->tags` value was being changed by `applyrules(c)` way before the line `selmon->tagset[selmon->seltags] &= ~scratchtag` is executed. I took a look at `applyrules(c)` but already guessed what it does. It is responsible for applying some rules to the new client but also adds tags to new clients, which I didn't suspect during my first read. ```c@@ -540,14 +570,25 @@
``` -`applyrules()` does some rule matching which is a feature that comes default in dwm config, where you can specify rules for specific windows. For example, let's say you wanted the Gimp Window to always open in tag 2—that sort of thing. We don't have any rules setup for the eog file viewer so this shouldn't affect it? Right? But, in `applyrules(c)` we see that `c->tags` is actually set to 0 first and then at the very end (after gone through the rules), it actually sets the tags if `c->tags` isn't already set by any of rules. The line `c->tags = c->tags & TAGMASK ? c->tags & TAGMASK : c->mon->tagset[c->mon->seltags];` reads "If there are no tags set yet for this client, then set them to the same tagset the client's monitor has" so the client's tags equal `c->mon->tagset[c->mon->seltags]` and we know that `c->mon` is `selmon` from the caller function just before the call to `applyrules()`— `c->mon = selmon` +`applyrules()` does some rule matching which is a feature that comes default in dwm config, where you can specify rules for specific windows. For example, let's say you wanted the Gimp Window to always open in tag 2—that sort of thing. We don't have any rules setup for the eog file viewer so this shouldn't affect it? Right? But, in `applyrules(c)` we see that `c->tags` is actually set to 0 first and then at the very end (after gone through the rules), it actually sets the tags if `c->tags` isn't already set by any of rules. The line `c->tags = c->tags & TAGMASK ? c->tags & TAGMASK : c->mon->tagset[c->mon->seltags];` reads "If there are no tags set yet for this client, then set them to the same tagset the client's monitor has" so the client's tags equal `c->mon->tagset[c->mon->seltags]` and we know that `c->mon` is `selmon` from the caller function just before the call to `applyrules()`— `c->mon = selmon`. There's our problem! + +## The solution + +The solution is put this assignment `selmon->tagset[selmon->seltags] &= ~scratchtag` before the call to `applyrules()`. That's it! -There's the problem and the solution is put this assignment `selmon->tagset[selmon->seltags] &= ~scratchtag` before the call to `applyrules()`. That's it! +All this effort just to get the following patch—I wish it was a little more complicated than just this :D -All this to get this diff: ```diff -@@ -1304,6 +1313,11 @@ manage(Window w, XWindowAttributes *wa) +diff --git a/dwm.c b/dwm.c +index e20a4ba..591f38a 100644 +--- a/dwm.c ++++ b/dwm.c +@@ -1309,14 +1309,15 @@ manage(Window w, XWindowAttributes *wa) + c->x = c->oldx = wa->x; + c->y = c->oldy = wa->y; + c->w = c->oldw = wa->width; + c->h = c->oldh = wa->height; c->oldbw = wa->border_width; updatetitle(c);@@ -555,11 +596,15 @@ + selmon->tagset[selmon->seltags] &= ~scratchtag;
if (XGetTransientForHint(dpy, w, &trans) && (t = wintoclient(trans))) { c->mon = t->mon; c->tags = t->tags; - } else { - c->mon = selmon; - applyrules(c); - } -@@ -1322,7 +1332,6 @@ manage(Window w, XWindowAttributes *wa) + } else { + c->mon = selmon; + applyrules(c); + } +@@ -1327,15 +1328,14 @@ manage(Window w, XWindowAttributes *wa) + c->y = c->mon->my + c->mon->mh - HEIGHT(c); + c->x = MAX(c->x, c->mon->mx); + /* only fix client y-offset, if the client center might cover the bar */ + c->y = MAX(c->y, ((c->mon->by == c->mon->my) && (c->x + (c->w / 2) >= c->mon->wx) && (c->x + (c->w / 2) < c->mon->wx + c->mon->ww)) ? bh : c->mon->my); c->bw = borderpx;@@ -567,8 +612,15 @@ - selmon->tagset[selmon->seltags] &= ~scratchtag;
if (!strcmp(c->name, scratchpadname)) { c->mon->tagset[c->mon->seltags] |= c->tags = scratchtag; c->isfloating = True; - + c->x = c->mon->wx + (c->mon->ww / 2 - WIDTH(c) / 2); + c->y = c->mon->wy + (c->mon->wh / 2 - HEIGHT(c) / 2); + } ``` ## What I learnt -- +- Don't hesitate to read the source code\ + I feel this is the biggest take away. Just in about 30-45 mins I was able to go from zero knowledge of how dwm worked to figuring out that the problem was in the `manage()` function. Also owing to the fact that dwm has simple codebase, and that's the suckless philosophy—because of which someone like me who had last read and written C in college about ~5 years ago, was able to figure it out and make changes to it. It made me realise C doesn't have to be as daunting as it seemed in my head to be. +- Learnt that something like Xephyr exists, which is pretty cool! +- Learnt about [ptrace_scope](https://www.kernel.org/doc/Documentation/security/Yama.txt) again when I initially tried doing `gdb -p $(pgrep dwm)` in my main X session. +- picked up some more useful gdb commands. +- Reading dwm's source gave me the confidence to finally write new features and make changes which I wish it had.