[Xquartz-dev] State of modifier keys

Harald Hanche-Olsen hanche at math.ntnu.no
Wed Apr 30 13:57:39 PDT 2008


Hmm. I've suddenly discovered something new. Don't know if I've seen
it before, but the problem seems to be this: When X11 loses focus and
regains it, it assumes that the state of the modifiers is unchanged
since it last had focus.

This is easily demonstrated with an xev and (say) a Terminal window.

With the xev window having focus, press a modifer - say shift - and
hold it down while clicking on the Terminal window. Release the
modifier, click on xev again, and type a regular key. Check the State
field in the resulting xev output: 0x1 for the shift key, 0x4 for the
control key, 0x5 for both, and so on.

You may ask, why would someone do something as convoluted as this? But
I think it happens easily. It happened repeatedly to me before I
figured it out. I have set up Spaces so I change space using ctrl+alt
with arrow keys to move around. That makes it easy for X11 to lose
focus while the control key is down. An xterm that believes the
control key is down does not behave normally, I can now say with some
confidence.

I suppose there must be a way for an application to query the state of
the modifier keys, without keeping track of keypress/keyrelease
events? So that seems to be what X11 must do to, each time it loses
and regains focus - so it can adjust its own beliefs about current
state.

Since I cannot recall stumbling over this before, maybe it used to do
that, and this is a regression?

I run X11-2.2.1-rc2, Xquartz-1.4.0-apple5, and Ben's quartz-wm.

- Harald


More information about the Xquartz-dev mailing list