| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Using labels only to mark smooth scrolling axes disallows scrolling from
hardware events (e.g. a mouse wheel). If those axes are marked as scrolling
axes instead, the clients lose information which hardware axis this event
corresponds to.
For example, on Wacom devices, the client can benefit from smooth scrolling
on the strip or wheel event but may still require the knowledge whether the
axis is a vertical strip (e.g. Intuos3) or a absolute scrolling wheel (e.g.
Intuos4).
Thus, add a new class to XIQueryDevice that represents scrolling information
on a valuator. One of these ScrollClass may exist for each ValuatorClass if
that valuator is a scrolling valuator. The increment field of this class
removes the requirement for 1.0 == 1 unit of scrolling.
This isn't true in most cases, especially where physical scroll axes are
involved. Wacom Intuos4 scroll rings have a unit size of 3.0 and the driver
historically sent one scroll event per 3.0 increment or decrement. Mapping
one scroll event to 1.0 makes the ring mostly unusable through legacy
button events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The XIPointerEmulated flag on pointer events means that the event was
emulated from a smooth-scroll or touch event to support legacy events,
and the client may ignore this if it is listening to the other events.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
The matching commit in libXi is
e8531dd6a981c6cf19a1d256c29e886e34e8f51a
libXi-1.4.2-21-ge8531ddp
Add XI2 library-internal array offsets to XIint.h
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
No functional effect, just to improve readability of code.
It's not obvious what "True" or "False" stands for in a function with 11
arguments. Compare
XIGrabButton(dpy, deviceid, button, grab_window, cursor,
GrabModeAsync, GrabModeSync, True,
event_mask, num_modifiers, &modifiers);
vs.
XIGrabButton(dpy, deviceid, button, grab_window, cursor,
GrabModeAsync, GrabModeSync, XIOwnerEvents,
event_mask, num_modifiers, &modifiers);
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
|
|
XI 2.0 headers forced clients to mix XI2 specific constants with defines for
core input. Most notable here are the grab code which required GrabModeAsync
or GrabModeSync from core, but _not_ AnyModifier (XIAnymodifier !=
AnyModifier). This is a hard-to-debug cause for bugs.
Add defines for grab modes, grab return codes and property modes as well as
a define for the AnyPropertyType. These defines are identical to the ones
defined in core but stop the use of input-related defines from either core
or XI 1.x.
Clients must use the core defines None and CurrentTime where applicable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
|
|
The previous definition would give the wrong result for events that are
a multiple of 8.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Keysym grabs are tricky to get right for applications that are more
complicated than demo applications. otoh, we know keycode grabs are working.
So let's go with keycode grabs for now and add keysym grabs later when we've
sorted out the details.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
Add a flags member to DeviceEvent and DeviceKeyEvent; the only currently
defined flag is KeyRepeat, indicating a repeat event (a la XKB detectable
autorepeat), which is only valid for key events.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Instead of a single XI_RawEvent type with subtypes to represent the actual
event, split up the event into XI_RawButtonPress, XI_RawButtonRelease, etc.
This way clients can select for specific raw events only instead of all of
them at once.
Note that raw events may be selected on master devices too, the server will
route them through master devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
We use add/remove for slave devices, add/remove for the hierarchy changed
flags, so let's use add/remove to create a new device as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
If an enter/focus grabs activates (or deactivates), send an extra set of
enter/focus in (or leave/focus out) events to the grabbing client with mode
XIPassiveGrabNotify.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Same behaviour as button/keysym grabs but triggered on enter/leave and
focus in/out events.
|
|
XISetMask, XIClearMask, XIMaskIsSet serve to set, clear or check a bit in
the provided array.
XIMaskLen is a macro to get the minimum length of a mask for a given event
type.
They are expected to be common ways to deal with event masks, i.e. clients
will do:
unsigned char mask[XIMaskLen(XI_ButtonRelease)] = {0};
XISetMask(mask, XI_ButtonPress)
XISetMask(mask, XI_ButtonRelease)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
Anything with prefix XI is per-device anyway.
|
|
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Basically the same as XI 1.5, save the 16 bit deviceids.
|
|
Most notably XI2 provides keysym grabs instead of keycode grabs.
|
|
Basically the same as the core protocol AllowEvents.
|
|
|
|
|
|
|
|
|
