setborderpx patch doesn't appear to work

[mitchdotnet]

With the setborderpx patch enabled I can decrease the borders, including to 0 to eliminate them, but increasing them does not work at all. I thought this might be an issue with my build and some kind of conflict with one of the other patches I'm using but I tried with an unmodified freshly cloned copy of master and enabled only the setborderpx patch the results were the same.

There is, incidentally, some kind of conflict going on with the patches I have enabled and setborderpx because on my actual build, after decreasing the borders to 0px trying to increase them again causes dwm to crash. I'll worry about that once the patch is actually working though.

[bakkeby]

Have you tried changing the keybindings? Are you using the default?

[mitchdotnet]

This was with the default keybindings so I hadn't even thought to try something different, though I did make sure that it didn't conflict with anything else in my config or st's. I also tried it with clients other than st terminals just to be sure and the result was the same. However, changing it to something else (in this case MODKEY|ControlMask XK_m and MODKEY|ControlMask XK_n) has it working as expected. I am still getting a crash if accidentally attempting to lower the borders below 0.

[bakkeby]

However, changing it to something else (in this case MODKEY|ControlMask XK_m and MONDKEY|ControlMask XK_n) has it working as expected.

Some key combinations may not work as it may depend on a variety of things, particularly laptops can be troublesome where it may hijack certain key combinations and send through something else. For example the function (fn) key + a number may interfere with e.g. Super+Shift+number or Alt+Shift+number, and it ends up sending through XF86XK_MonBrightnessUp instead.

I am still getting a crash if accidentally attempting to lower the borders below 0.

That is odd. The code caps the borderpx at 0 with the MAX here:

dwm-flexipatch/patch/setborderpx.c

Lines 10 to 14 in 03ede82

	m->borderpx = arg->i
	? MAX(m->borderpx + arg->i, 0)
	: m->borderpx == borderpx
	? 0
	: borderpx;

I tried this running dwm in Xephyr and I could not replicate the crash, maybe something else going wrong?

[mitchdotnet]

Some key combinations may not work as it may depend on a variety of things, particularly laptops can be troublesome where it may hijack certain key combinations and send through something else. For example the function (fn) key + a number may interfere with e.g. Super+Shift+number or Alt+Shift+number, and it ends up sending through XF86XK_MonBrightnessUp instead.

True, though I was getting the same result on both my desktop and my laptop.

That is odd. The code caps the borderpx at 0 with the MAX here:

dwm-flexipatch/patch/setborderpx.c

Lines 10 to 14 in 03ede82

	m->borderpx = arg->i
	? MAX(m->borderpx + arg->i, 0)
	: m->borderpx == borderpx
	? 0
	: borderpx;

I tried this running dwm in Xephyr and I could not replicate the crash, maybe something else going wrong?

I'll have to poke around some more and see if I can find exactly what's causing this for me. In the meantime, reverting the setborderpx function in patch/setborderpx.c back to the stock patch from the dwm site fixes the crashing issue. For whatever reason the way it handles borderpx values of less than 0 works for me.