Mostly the same buttons as defined by linux/input.h, with five exceptions:
"Button Unknown" for a button that cannot be labelled.
"Button Wheel Up", "Button Wheel Down" for buttons 4/5, traditionally the
wheel buttons.
"Button Horiz Wheel Up", "Button Horiz Wheel Down" for buttons 6/7,
traditionally the horiz. wheel buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Don't pass xEvent* and count through to processing, pass a single
InternalEvent.
Custom handlers are disabled for the time being. And for extra fun,
XKB's pointer motion emulation is disabled. But stick an error in there so
that we get reminded should we forget about it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With the API change, we can now purge the XI conversion from POE.
Note: this commit breaks DGA even more.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
deviceGrab.sync.event is now an internal event, and CheckDeviceGrabs and
friends is changed over.
Note that this currently breaks some frozen grabs. See towards the end of
ComputeFreezes().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Note that we're only partially switched to internal events. The event in the
devices' event queue (dev->deviceGrab.sync.event) is still an XI event. The
events in syncEvents are InternalEvents only now.
This also implies fixing CheckVirtualMotion to work with internal events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Get rid of the deviceValuator processing and a few other things, but still
drop back into XI before checking device grabs or doing anything else.
NoticeEventTime now needs to take InternalEvents, and while we're at it,
change NoticeTime from a macro to a function.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Note that this breaks DGA. Life is tough.
EnqueueEvent is a somewhat half-baked solution, we immediately drop back into
XI and store them. But it should in theory work.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't let the dcce be random data.
Before dropping down into the DIX, convert back into XI events. This is a
temporary solution only, until the DIX is capable of handling InternalEvents
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This gets rid of the nevents parameter, InternalEvents are always a single
item per event. Also remove the special DeviceValuator handling in both
enqueueing and dequeueing.
Custom callback handlers are now broken until fixed.
For bisectability, we copy the InternalEvent back into the XI required during
POE and friends. Consider this a temporary solution.
Note: Because of misc linker bonghits, Xvfb won't link in this revision.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Convert from an InternalEvent type to the matching core/XI type. Currently
only for a few events, those we actually need in the server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the event we want to feed into the EQ and process on the way through.
Only applies for input events for now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather, modify the two callers to call separately for the two different.
events. Unexport SetMaskForEvent too.
And while we're at it, get rid of the MotionFilter macro, because it's one
half confusing and one half pointless.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
They end up being the same anyway on startup, so let's not have a dynamic mask
assignment mechanism and instead just hardcode them already.
Also unexport SelectForWindow and remove the valid_masks parameter. We can
check that before calling, since there's only one caller anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The algorithm is split in a 2D-specific and a general part.
This potentially allows to accelerate more than just screen motion.
A state machine is intoduced to make code more explicit and readable.
It also improves handling of 'phase 1' mickeys when axial correction
kicks in (corner case).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Changes MakeAtom to take a const char * and NameForAtom to return them,
since many callers pass pointers to constant strings stored in read-only
ELF sections. Updates in-tree callers as necessary to clear const
mismatch warnings introduced by this change.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
This is copied from linux/input.h, presumably that's the ones at least the
Linux kernel can give us for any device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This mirrors that in KeyClassRec: the state of the buttons as posted to
GetPointerEvents, rather than the state of the buttons as processed by
ProcessOtherEvent and friends.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Everything goes through XKB's Process{Keyboard,Pointer}Event on its way
through to ProcessOtherEvent now, so get rid of the old, useless functions.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
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 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>
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>
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>