GoogleCodeExporter
commented
9 years ago Another part of this problem is handling missed key events (e.g., user puts key
down,
changes focus, and then releases the key -- we only see the key down, not the
key up).
Initial report:
http://thread.gmane.org/gmane.comp.window-managers.parti.general/22
Background: the source of the problem here is that the xpra client receives a
key-down event for Alt_L, but never receives a key-up event. That's fine; apps
never
care whether they see both halves of this kind of event -- some apps (e.g. OOo)
look
for Alt like a normal key, so if they get the event they do something (like
activate
the menu) but if they don't then eh, and some (all) apps care whether the
modifier
bits are set on other key events they receive, but no-one actually needs to
match up
the beginning and end of things like Alt presses.
For xpra's purposes, this is tricky because: we do want to forward keys like
Alt_L,
to make things like OOo's menu access functionality work. But, having forwarded
the
key-down, we *have to know that that key is down and that that's why the meta
bit is
set* because later on, when we receive a key event *without* the meta bit set,
the
only way we can disable the meta bit is to synthesize an unpress of Alt_L. (And
ideally doing something to prevent any app from getting that synthetic event
and like
activating the menu or something -- maybe grab the keyboard before issuing the
fake
event.) Currently we detect that the meta bit should be released, and we try to
do
that, but we do it by unpressing the key that *we* would have used to enable
the meta
bit, which doesn't help because the X server doesn't think that that key is down
anyway. We have to unpress the *actual* key that enabled the meta bit.
I don't see how to do this without some very careful tracking of which keysyms
activate which bits in the modifier state vector, and really the modifier map
on the
client and server will have to match, ugh.
Option 1: fully mirror all X keyboard-fu from the client whenever a client
connects
(or has its keyboard reconfigured). This is even probably-not-that-hard if we
only
have to worry about core keyboard handling; if we have to handle Xkb then
AIEEEEE.
Then build some sort of keyboard state tracking machinery ourselves to figure
out
what's going on. This state tracking machinery has to exactly match that in the
X
server AIEEEEEEEEE.
Option 2: simply do not forward modifier keypresses from the client to the
server (or
have the server ignore them, not sure which is cleaner). Make the server's
synthetic
modifier handling be the *only* modifier handling. This breaks the case where
tapping
Alt_L activates the menu in OOo, and I'm sure that will annoy someone sooner or
later; I'm not sure I care. Also, we can't filter out Shift at the moment
without
breaking everything -- so the problem will persist for Shift. Sigh.
Question: is it possible to ask the X server which keys are depressed? If so,
then
that's both good and bad -- good because it would allow us to sync up state
occasionally by having the client query and then tell the server, bad because it
would require state tracking for *all* keys to make things fully correct on the
server side. (Hmm, but if it's possible, then maybe there's a radically
different
approach to keyboard handling: whenever the client receives a key event of any
sort,
it ignores what the event actually says and instead just deltas the new keyboard
state against the previously-sent keyboard state and sends *that* to the
server. That
might be nice... it also requires the ability to package up keyboard
configuration
and send it over, though.)
Original comment by njsmith@ucsd.edu on 7 Nov 2009 at 5:15
Original issue reported on code.google.com by
njsmith@ucsd.eduon 7 Nov 2009 at 5:13