Instead of always keeping two copies of the keymap, only generate the
core keymap from the XKB keymap when we really need to, and use the XKB
keymap as the canonical keymap.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Replace both core and Xi functions with one function that validates the
proposed map, and sends out both kinds of notification.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Keyboard map notifications are always generated from within XKB code,
which also takes care of copying the keysyms, etc. If you need to
mangle the keymap yourself, generate a new core keymap/modmap, and pass
it to XkbApplyMappingChange.
SendMappingNotify is renamed to SendPointerMappingNotify (and ditto its
Device variants), which still only _sends_ the notifications, as opposed
to also doing the copying a la XkbApplyMappingChange.
Also have the modmap change code traverse the device hierachy, rather
than just going off the core keyboard.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
XIShouldNotify just lets you know if you should send an event for a
keymap change (or similar) concerning a given device to a given client;
at the moment, this is only for devices which are sending events to that
client.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Turn two unsigned chars into one unsigned int for both vmods and the
vmod mask. As a bonus, remove broken unused accessor macro for setting
the vmods.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Turn four unsigned chars into one unsigned long.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Turn vmods from two unsigned chars into one int.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For some reason, we insist on having daft internal representations that
make no sense, that always have to be converted to be used. We should
really sort this one out.
Also, comment the hojillion members of XkbStateRec.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Rather than requiring a one-to-one correspondence between XKM and struct
formats in action data, explicitly fill the action data, so we can break
API.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't use them, as they're not up to the task. We'll get a better
solution someday, promise.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When we find something weird in the rules, don't stash it as an extra
freeform component, just state that the rules file is likely broken and
move on with our lives.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We support every XKB operation on Xi devices, so always report that we
support everything, and that nothing is ever unsupported.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have modmap (in the exact same format!) in XKB, so just use
that all the time, instead of duplicating the information.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since modifierKeyMap is generated from modifierMap, just remove it, and
only generate it when we need to send the modifier map to the client.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Modifiers get cleared by the XKB code when we drop down into core input
processing, so just delete the dead code path to simplify things a bit.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We already have state fully stored within XKB, so instead of duplicating it,
just generate the values to send to clients when required.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
XkbInitKeyboardDeviceStruct is now the only valid keyboard
initialisation: all the details are hidden behind here. This now makes
it impossible to supply a core keymap at startup.
If dev->key is valid, dev->key->xkbInfo->desc is also valid.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No more #ifdef XKB, because you can't disable the build, and no more
noXkbExtension either.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Prepare for the impending removal of the state field by disabling this hack
for a while: it's hell of nasty and I'm amazed it ever really worked.
Basically, on focus out, it should do as current DDXes do and fake releases
for all keys (not just mangle the core state) that are currently down;
buttons too. When focus comes back in, we already have a KeymapNotify that
lets us know what's currently down, so we can use this to fake the
appropriate keypresses, and send it through the event routing layer.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
For some reason, XKB allows clients to set a global (!) flag that simply
turns lock keys into state no-ops. Ignore this flag.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
XkbRMLVOSet is just a set of strings for rules, model, layout, variant
and options; use that in preference to XkbRF_VarDefsRec, which is a
hideously complicated monster that somehow managed to not include the
actual rules.
While we're at it, clean up xkbrules.h so it doesn't require xkbstr.h.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Humour the user if they run XkbCopyKeymap(foo, foo).
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we can't enable a device, bail out of NewInputDeviceRequest rather than
blithely continuing. Also, be more verbose when initialization failed. Also,
be more verbose when initialization failed. Also, be more verbose when
initialization failed. Also, be more verbose when initialization failed.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Core events aren't run through these functions, so don't bother testing
for them.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The device-walking code is still depressing, though.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of hardcoding base/pc105/us, allow users to change the defaults at
./configure time. Change the default model to be evdev on Linux.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Fix internal WM to notify X when the keyboard focus is lost to a pure Windows window in -multiwindow mode.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Fix internal WM so it only allows WM_MOUSEWHEEL messages to act on the client area of a focused window.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Fix internal WM to correctly parent XA_WM_TRANSIENT_FOR windows in -multiwindow mode when a windows window is created,
and to de-iconize parent windows when a child window acquires focus.
XXX: Perhaps we should also shuffle parent(s) forward through Z-order when a child acquires focus?
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Correct the tooltip text for the toolbar X icon to be strictly correct, 'display-number:screen' should be ':display-number.screen'.
Also for the default window title.
Adjust the style of the Windows title in XDMCP mode from 'Xming - hostname' to 'hostname:display-number.screen'.
Copyright (C) Colin Harrison 2005-2008
http://www.straightrunning.com/XmingNotes/http://sourceforge.net/projects/xming/
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
