If a passive enter or focus in grab activates, send additional enter or
focus events with mode XIPassiveGrabNotify to the grabbing client.
Likewise, if the grab deactivates, send additional leave or focus out
events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Enter grabs are checked for in CheckMotion(), each time the sprite window
changes the current grab is deactivated (if applicable) and the new grab is
activated (if applicable). Exception - if the grab is on a parent window of
the current window since we keep the grab across descendants.
Since CheckMotion() may change the grab status of a device, we mustn't get
"dev->deviceGrab.grab" in ProcessOtherEvents until after CheckMotion().
FocusIn grabs are checked in much the same manner.
The event delivery for grabs replaces the NotifyNormal on window change with
a NotifyGrab on window change. Note that this happens before the grab
activates, so the EnterNotify(NotifyGrab) is still delivered to the window,
not to the grabbing client. This is in line with the core protocol semantics
for NotifyGrab events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Copying all classes into the master device has drawbacks for hybrid devices
(devices that are both mice and keyboards). If such a device posts an event,
it's key classes are moved into the VCP. The key event itself is unaffected
by keyboard grabs and the like.
Partial class copying copies depending on the event and copies the classes
into the right master device (i.e. the VCK for key events, the VCP for
pointer events).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For hybrid devices (keys + buttons/axes) the attached master device is
generally the wrong one. One shouldn't post a button event through a
keyboard and vice versa.
GetMaster(dev) returns the right master device for the given type needed.
This may be the MD paired with this device's MD.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
ChangeDeviceId would actually overwrite the flags field if deviceid wasn't
present. Aside from the event of course not telling which device generated
it in the first place.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's no need for internal events to be a struct with a single nested
union, we might as well make the union itself the InternalEvent.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
isMaster is not enough as long as we differ between master pointers and
keyboard. With flexible device classes, the usual checks for whether a
master device is a pointer (currently check for ->button, ->valuators or
->key) do not work as an SD may post an event through a master and mess this
check up.
Example, a device with valuators but no buttons would remove the button
class from the VCP and thus result in the
IsPointerDevice(inputInfo.pointer) == FALSE.
This will become worse in the future when new device classes are introduced
that aren't provided in the current system (e.g. a switch class).
This patch replaces isMaster with "type", one of SLAVE, MASTER_POINTER and
MASTER_KEYBOARD. All checks for dev->isMaster are replaced with an
IsMaster(dev).
dev->u.lastSlave was not signal safe since it was accessed by the DIX and
during signal handling.
Replaced with:
'dev->last.slave' for the signal handler's lastSlave (used to generate
DeviceChangedEvents), .
'dev->u.lastSlave' for the DIX lastSlave (currently only used in
change_modmap)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This type is only used in XI to give a hint of what type this device may be.
Call it xinput_type for clarity.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This approach is broken anyway. DIPT only checked for the XInput type
"MOUSE" and the only user of this is xf86ActivateDevice when it sets the
Activate/DeactivateGrab functions.
Since synaptics and wacom set their own types, evdev only sets MOUSE for,
well, mice half the devices didn't have this set correctly anyway.
Instead, ActivatePointerGrab should be merged together with
ActivateKeyboardGrab.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's only two reasons for hierarchy events:
- device is added, removed, etc. In this case we want to send the event as
it happens.
- devices are added in a XIChangeDeviceHierarchy request. In this case we
only want one event cumulating all changes.
This is a shorthand for disabling acceleration, while retaining the
possiblity to use constant deceleration. If constant deceleration is
also unused, it will optimize motion processing.
Other possiblities to deactivate acceleration were quite hidden,
and didn't always work as expected. E.g. xset m 1 1 would retain
adaptive deceleration, while xset m 1 0 would not (in the default
profile).
Also removes the 'reserved' profile; it was unused and it's trivial
to add new ones anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With the Xtest virtual slave devices we have 4 devices for each MD
pointer/keyboard pair, plus the AllDevices and AllMasterDevices reserved
deviceids. It's quite easy to hit the current limit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With the Xtest virtual slave devices we have 4 devices for each MD
pointer/keyboard pair, plus the AllDevices and AllMasterDevices reserved
deviceids. It's quite easy to hit the current limit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All other functions are pushed into where they seemed to fit.
main.c is now linked separately into libmain.a and linked in by the various
DDXs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All other functions are pushed into where they seemed to fit.
main.c is now linked separately into libmain.a and linked in by the various
DDXs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For embedded use, it's convenient to be able to disable the cursor
completely, without having to audit and fix up all your third-party
code (e.g. Mozilla Firefox).
Add -nocursor and -cursor server options to enable and disable the
cursor. The default is still -cursor, but embedded users can run the
server with -nocursor to hide the cursor regardless of what
application developers do.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A XTest virtual slave device pair (kbd/ptr) exists for every master
device pair. This is so XTest events are correctly propogated via slave
devices up to Master devices and the classes are correctly changed along
the way. We add the XTest slave device pair to the Virtual Core pointer
and provide a simple way of creating the devices.
A XTest Slave Device is identified by the XTstDevicePrivateKey property
being set in the devices devProperties
XI events are still propagated through the matching device, in the hope the
client knows what it is doing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Allocating a slave device is essentially the same as allocating a master device.
Hence we rename AllocMaster to AllocDevicePair and provided the ability to
indicate if a master or slave device pair is required.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No traces of FID in the xserver nor in the modules listed in
util/modular/xorg.modules
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Yes, this means we have even more arguments to GrabDevice. But it beats having
a copy of most but not all of GrabDevice in ProcGrabPointer.
Also, reshuffle the order of parameters, the CARD* status is a return value
and should be last.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Split ChangeMasterDeviceClasses into an extra XISendDeviceChangedEvent that
assembles the XI2 wire event for the DeviceChanged event. Re-use this when
detaching the last SD.
Not quite perfect yet, we still copy the device classes from the slave now
rather than from the data we had when the event occured. But it's a start.
(We can now unexport SizeDeviceInfo and CopySwapDevices, not needed anymore)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The masks were originally designed to generically handle event masks for
extensions. Since all that is in-server anyway, it's much better writing
custom event masks for those extensions that need it and not providing a
unified mechanism.
XI2 needs more than the current implementation, which is already too complex
for most other extensions. good riddance.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Best to FatalError if a wrong event comes in. At least that forces me to fix
it really quickly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Replace multi-stage filtering with simple linear velocity,
tracked several instances backwards. A heuristic ensures
only approximately linear motion is considered, so velocity
remains valid in any case. Numerical stability is much
better, and nothing changes to people who didn't tune the
advanced features of the previous algorithm.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Requires libselinux 2.0.79 or newer. Without this, libselinux will
check for policy updates on the netlink socket on basically every policy
lookup. Statistically speaking, they never happen, and the check
translates to at least one more syscall on basically every operation.
Instead, take control of the fd from the library, and check it in
WakeupHandler if it polls readable.
dixLookupResource attempted to automatically detect whether the caller
wanted a lookup by-type or by-class, unfortunately, it guessed wrong for
RT_NONE. Instead of trying to make the guess better, this patch just reverts
the unification and creates separate functions for each operation.
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>
