When the keyboard layout is modified via xmodmap, each single "change"
(line of input to xmodmap) causes an "the keyboard configuration
changed"-event to be sent. Awesome reacted to each of these events by
reloading the keyboard layout. Thus, awesome reloaded the keyboard
layout a lot and appeared to freeze.
Fix this by asynchronously update the keyboard state: When such an event
comes in, instead of reloading things immediately, we set a flag which
makes us update the state at the end of the main loop iteration. This
means that many events still cause only a single (or at least few)
re-quering of the layout. Thus, a lot of time is saved.
This commit removes the argument to the (undocumented!) signal
xkb::group_changed. Previously, the argument was the active group
number. Since this argument was unused and I'm lazy, I just removed it.
The alternative would be that it might be visible to Lua that some "the
active group changed"-events are dropped.
Fixes: https://github.com/awesomeWM/awesome/issues/1494
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of focusing the root window, we now create a "focus window" inside of
our frame window. This window is placed so that it is not visible, but we can
grab key bindings on it to simulate the window having the input focus.
Fixes: https://github.com/awesomeWM/awesome/issues/699
Signed-off-by: Uli Schlachter <psychon@znc.in>
The only remaining calls are for a window's opacity and in the DBus type
handling. Everything else wants integers, not something with a comma.
Signed-off-by: Uli Schlachter <psychon@znc.in>
A quote from the XKeyboard specification:
The server notifies interested clients of keyboard map changes in one of two
ways. It sends XkbMapNotify to clients that have explicitly selected them and
core protocol MappingNotify events to clients that have not. Once a client
requests XkbMapNotify events, the server stops sending it MappingNotify events
to inform it of keyboard changes.
This commit moves the code that we had for handling MappingNotify events to the
place where we handle XkbMapNotify events. This might even fix some bugs where
parts of awesome continued to use old key binding "stuff"!
Signed-off-by: Uli Schlachter <psychon@znc.in>
Imagine the following snippet is run:
keygrabber.run(function(mod, key, event)
gears.debug.dump{mod, key, event}
end)
The above starts a keygrabber and prints the events that are received.
Currently, when a key is pressed and held down, this prints a series of press
and release, because that's what the X11 server sends us.
This commit enables detectable autorepeat. This means that the X11 server only
sends us a series of press events for autorepeat and a single release when the
key really is released.
Testing this is a bit hard, because detectable autorepeat does not seem to work
with Xephyr. Instead, a "real" Xorg instance is needed.
We do not check the response to the PerClientFlags request, because it doesn't
really tell us anything useful. If the server does not support detectable
autorepeat, we could print a warning, but so what? As I just said, this does not
work in Xephyr and yet Xephyr announced to support this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In XCB, each request has a checked and an unchecked version. The checked version
can be used to check if the request caused any errors. Since the code here
doesn't do this check, it shouldn't use the checked versions of the requests.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This patch provides functions to get/set current keyboard layout.
Current implementation doesn't support any configuration of layout,
it's a merely a layout indicator and switcher, however layout
configuration can be set by tools like setxkbmap or by any third-party
tools.
Uli Schlachter
Julian Wollrath
Peter Junos
Aleksey Fedotov