You are not logged in.

#1 2014-01-30 16:30:27

cmtptr
Member
Registered: 2008-09-01
Posts: 135

[SOLVED] [PATCH] xorg-server 1.15 breaks wmii

Has anyone else noticed this?  Since upgrading xorg-server from 1.14.5-2 to 1.15.0-5, wmii now has an intermittent problem that when changing focus, the previously-focused window's border sometimes isn't updated.  So over time, it looks like I have two or three windows focused simultaneously.

Any suggestions?  It's a shame the window managers I always like keep going abandoned...

Last edited by cmtptr (2014-02-10 00:39:57)

Offline

#2 2014-02-03 21:05:12

bwv549
Member
Registered: 2013-12-13
Posts: 11

Re: [SOLVED] [PATCH] xorg-server 1.15 breaks wmii

Any suggestions?  It's a shame the window managers I always like keep going abandoned...

I switched from wmii to i3 and have been very happy.  Same generally philosophy as wmii, but i3 seems far more solid.

Offline

#3 2014-02-07 15:30:48

cmtptr
Member
Registered: 2008-09-01
Posts: 135

Re: [SOLVED] [PATCH] xorg-server 1.15 breaks wmii

I tried that, because I keep hearing i3 is wmii but better.  My conclusion is that this simply isn't true.  i3 is great if you use the out-of-the-box config.  If you want to do anything with it beyond that, it's extremely limiting.

What I lose with i3:
* A stacking mode where the title bars are attached to their windows, as in wmii.  i3's stacking mode confuses the hell out of me, and there's no option to change it.
* Title bars over windows even in tiled mode.
* The appearance and history that I was able to get out of wimenu.  I can't even get dmenu to fit correctly over the i3bar so that it looks right.
* The ability to put a window on multiple tags.
* The 9p interface, which to me was a large portion of the spirit of wmii.  It allows me to write my config in any language of my choice (I chose Lua), and it's easy to debug (wmiir read), and easy to change on the fly (wmiir write).

what I gain with i3:
* The concept of splitting containers for more direct control over window placement.  I liked this, but even it's crippled because I can't do the reverse.  Once I create a container, even if I reduce its children to only one window I have to move that window out of the container to destroy the container.
* Apparently better multi-monitor support.  I wouldn't know because I have only one monitor, and why do you even need several monitors if you're using a tiling window manager?  You have workspaces!
* They tell me it's faster.  But seeing as how we're all using computers built after 1980, I don't know how anyone can tell just by looking at it.  It's a window manager, for god's sake.  I'm not using it to crack the human genome!

In conclusion: i3 takes the most superficial aspect of wmii (tiling window manager) and completely diverges from there. It sacrifices customization for eye candy and fancy features that really aren't all that important (and could have been implemented in the user's config if it had expanded wmii's model).  It even says on the i3 website, "i3 is primarily targeted at advanced users and developers," and boasts that one of its primary design goals is clear documentation, yet it's configured from a static, non-standard config file with no programmability and its documentation is just a "User Guide" that is basically a how-to for tweaking superficial aspects of the shipped config.  As far as I can tell, there is no comprehensive documentation on the keywords recognized by this config, or even an explanation of its syntax!

So that's my rant on i3.  I haven't switched to it because it's shitty.

Last edited by cmtptr (2014-02-07 15:34:55)

Offline

#4 2014-02-09 10:57:36

wirr
Member
Registered: 2009-10-25
Posts: 68

Re: [SOLVED] [PATCH] xorg-server 1.15 breaks wmii

Have you tried to rebuild wmii, maybe from the aur?

I choosed to not install wmii on my new desktop so I did not test that. You should try to fix wmii since there is no other wm like wmii smile But if you still want to try others then I have to mention herbstluftwm even though you don't have 'title bars in tiling mode' or 'the ability to put a window on multiple tags'.

My problem with most other wms is the fact that only wmii has this two dimensional array of windows with the keys h,l left,right and k,l up,down. The others are not shitty but wmii has some very simple, clean and well thought out paradigms that are also somehow limiting or overcharging for other people.

In other words I managed to migrate away from wmii but thats not easy. You have to be patient.

Offline

#5 2014-02-09 14:54:40

cmtptr
Member
Registered: 2008-09-01
Posts: 135

Re: [SOLVED] [PATCH] xorg-server 1.15 breaks wmii

wirr wrote:

Have you tried to rebuild wmii, maybe from the aur?

Yes, I thought of that, too.  Rebuilding it doesn't help.

wiir wrote:

You should try to fix wmii since there is no other wm like wmii smile

Yesterday morning I decided to take it upon myself to find the root cause and make an attempt at a patch.  The problem seems to come down to that sometimes focusout_event gets called before client_focus.  It seems like wmii's sloppy focus is implemented by never updating an unfocused client's border until a new one is focused with client_focus.  The problem is that if focusout_event fires first, it clears the global focus pointer (assigns disp.focus = c_magic), so by the time client_focus is called it's already forgotten about the client that recently had focus so it can't redraw its border.

Unfortunately I'm no expert in X programming, but it seems to me the problem is some race condition either in the order messages arrive or in how they're handled.  I haven't given up yet, but I do have a day job so I'm looking at it whenever I get a chance (and I'm not too sick of staring at code from work).

Offline

#6 2014-02-09 22:11:48

cmtptr
Member
Registered: 2008-09-01
Posts: 135

Re: [SOLVED] [PATCH] xorg-server 1.15 breaks wmii

Apologies for the double-post, but I want to keep this thread updated with my progress in case anyone has any insight into my findings (as mentioned before, I'm no X expert, so I'm sort of stumbling through this as best as I can).

I believe the root cause is a bug in X 1.15.0.  I've managed to narrow it down to a very minimal method for reproducing it:

1) Tell wmii to listen to some random key with no function.  E.g.,

(wmiir read /keys; echo z) | wmiir write /keys

2) Ensure your config will either ignore unhandled keys or map this one to an empty function.  E.g.,

keys.z = function () end

3) Launch a terminal emulator and type "wmiir read /debug/focus".  Hit the key (in this example, 'z') several times,  In most cases you'll see only a focusin_event:

focusin_event() disp.focus:
	0xc0001c => 0xc0001c
	corey@sariss:~ => corey@sariss:~

Intermittently you'll see a focusout_event before the focusin_event, which is the bug:

focusout_event() disp.focus:
	0xc0001c => 0x0
	corey@sariss:~ => <magic>
focusin_event() disp.focus:
	0x0 => 0xc0001c
	 => corey@sariss:~

wmii can't handle the sporatic focusout_event.  This is where it updates its disp.focus variable to &c_magic (represents no selection), so when client_focus() is called it has already lost the previous client (0xc0001c in this example) and can't update its border.

UPDATE:

Actually, I probably should have been looking at /debug/event to see exactly what X events are received.  The success case:

39852 FocusOut             window=0xc00006 mode=NotifyGrab detail=NotifyAncestor
39852 KeyPress             window=0x251 root=0x251 subwindow=0x800026 time=0d_3h_4m_18.419s x=802 y=699 x_root=802 y_root=699 state=() keycode=52 (keysym 0x7a "z") same_screen=True
39852 FocusIn              window=0x251 mode=NotifyGrab detail=NotifyInferior
39852 KeyRelease           window=0x251 root=0x251 subwindow=0x800026 time=0d_3h_4m_18.558s x=802 y=699 x_root=802 y_root=699 state=() keycode=52 (keysym 0x7a "z") same_screen=True
39852 FocusOut             window=0x251 mode=NotifyUngrab detail=NotifyInferior
39852 FocusIn              window=0xc00006 mode=NotifyUngrab detail=NotifyAncestor

And the failure case:

39809 FocusOut             window=0xc00006 mode=NotifyGrab detail=NotifyAncestor
39809 FocusIn              window=0x251 mode=NotifyGrab detail=NotifyInferior
39809 KeyPress             window=0x251 root=0x251 subwindow=0x800026 time=0d_3h_4m_17.473s x=802 y=699 x_root=802 y_root=699 state=() keycode=52 (keysym 0x7a "z") same_screen=True
39831 NoExpose             drawable=0x800026 major_code=CopyArea minor_code=0
39831 KeyRelease           window=0x251 root=0x251 subwindow=0x800026 time=0d_3h_4m_17.647s x=802 y=699 x_root=802 y_root=699 state=() keycode=52 (keysym 0x7a "z") same_screen=True
39831 FocusOut             window=0x251 mode=NotifyUngrab detail=NotifyInferior
39831 FocusIn              window=0xc00006 mode=NotifyUngrab detail=NotifyAncestor
39852 NoExpose             drawable=0x800026 major_code=CopyArea minor_code=0

This output has me back to thinking it's a wmii problem, mishandling events if they arrive in the wrong order or with the wrong timing...

Last edited by cmtptr (2014-02-09 22:17:46)

Offline

#7 2014-02-10 00:39:34

cmtptr
Member
Registered: 2008-09-01
Posts: 135

Re: [SOLVED] [PATCH] xorg-server 1.15 breaks wmii

Last double-post.  I wrote a patch in case anyone's interested.  I've emailed it to the wmii maintainer and to the Arch package maintainer, but since there seems to be very little interest or activity in wmii I don't know whether it will receive any response.  So if anyone else finds this thread and wants a fix:

0001-Fix-color-updates-when-changing-client-focus-from-ke.patch

From 6883497fbd343b13d74f5ac182e7712fafdb184e Mon Sep 17 00:00:00 2001
From: Corey Thompson <<snip>>
Date: Sun, 9 Feb 2014 18:22:09 -0500
Subject: [PATCH] Fix color updates when changing client focus from key events

---
 cmd/wmii/event.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/cmd/wmii/event.c b/cmd/wmii/event.c
index 82a51eb..d2f84be 100644
--- a/cmd/wmii/event.c
+++ b/cmd/wmii/event.c
@@ -245,9 +245,10 @@ focusout(XFocusChangeEvent *ev) {
 	if(ev->mode == NotifyUngrab)
 		disp.hasgrab = nil;
 
-	if((ev->mode == NotifyGrab)
-	&& XCheckMaskEvent(display, KeyPressMask, &me))
-		dispatch_event(&me);
+	if(ev->mode == NotifyGrab) {
+		if (XCheckMaskEvent(display, KeyPressMask, &me))
+			dispatch_event(&me);
+	}
 	else if((w = findwin(ev->window)))
 		handle(w, focusout, ev);
 }
-- 
1.8.5.4

PKGBUILD

--- /var/abs/community/wmii/PKGBUILD	2014-02-09 18:07:21.695367083 -0500
+++ PKGBUILD	2014-02-09 18:38:51.292941696 -0500
@@ -12,14 +12,17 @@
 depends=('libxft' 'libxrandr' 'libxinerama' 'dash')
 options=('!makeflags')
 source=(http://dl.suckless.org/${pkgname}/${pkgname}+ixp-${pkgver}.tbz
-	'fix-freetype-include.patch')
+	'fix-freetype-include.patch'
+	'0001-Fix-color-updates-when-changing-client-focus-from-ke.patch')
 md5sums=('3d480502b7b1e2a405d941df67f16bcf'
-         '97febd4a1df80aa4afbd126de1f36496')
+         '97febd4a1df80aa4afbd126de1f36496'
+         '03c98da455f53a1c73833c90a1e8302d')
 
 build() {
   cd ${srcdir}/${pkgname}+ixp-${pkgver}
 
   patch -Np1 -i ${srcdir}/fix-freetype-include.patch
+  patch -Np1 -i ${srcdir}/0001-Fix-color-updates-when-changing-client-focus-from-ke.patch
 
   sed -i 's|PREFIX = /usr/local|PREFIX = /usr|' config.mk
   sed -i 's|ETC = $(PREFIX)/etc|ETC = /etc|' config.mk

And marking the thread as solved...

Offline

Board footer

Powered by FluxBB