Previously, an active grab on an attached slave device would send the device
floating for the duration of the grab. This breaks existing XI applications
(e.g. the GIMP) since they grab all devices automatically - resulting in the
loss of control over the VCP.
The behaviour of extended input devices during a grab in relation to the
core pointer is not specified in the XI protocol specification.
The removal of the temporary detachment restores the behaviour of extended
input devices as present in currently released servers - even if a device is
grabbed, an event from this device will result in an event from the core
pointer.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Presumably, some intelligent, XI2-aware management app will be calling
XISetClientPointer on behalf of other clients; this check makes sure
the target client has permission on the device.
Requires changing the prototype to return status code instead of Bool.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
event->type is always GenericEvent for XI2 events. Instead, XI_ButtonPress
(the generic event's evtype must be stored.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
GetMaster is more reliable than GetPairedDevice, it always returns the
keyboard/pointer if desired, even if the wrong device was passed in.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let EventToXI, EventToCore and EventToXI2 return BadMatch if there's no
matching event for this protocol spec.
Adjust the delivery paths to cope with BadMatch errors (and clean them up on
the way).
As a side-effect, this fixes server crashes on proximity events for a
grabbed device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For proximity events, the XI2 type is 0 and inputMasks never got set in the
preceding condition. As a result, proximity events got never delivered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These grabs are suported through two fake devices inputInfo.all_devices and
inputInfo.all_master_devices. These devices are not part of the device list
and are only initialised for their device id, nothing else.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A passive XI2 grab always uses the paired master device as a modifier
device. After issuing a passive grab, the slave may be reattached to a
different master and hence the modifier device may change.
Rework addresses two issues:
- storing the master device's pointer is a bad idea, we need to store the ID
of the device in case it disappears during the grab.
- restoring the old master did not actually reattach the device. Fixed now.
grab->type is the device type and XI2 types overlap with core events (being
less than GenericEvent). Thus, for passive grabs the grab device would be
overwritten with whatever device was activating it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Extension devices have ActivateKeyboardGrab as their grab activation
function, hence we need to ensure the implicit passive grab flag is set
accordingly in the grab for further event delivery.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If an implicit passive grab is active, the XI event mask is in
grab->deviceMask. Otherwise, for explicit grabs, the XI event mask is in
grab->eventMask.
Reported-by: Thomas Jaeger
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
There's devices (e.g. some barcode readers) that have axes but no buttons.
When such a device sends a motion event, the valuator and button class is
copied into the master pointer (i.e. removing the button class).
So we need a couple of extra sanity checks for the button class to exist.
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).
Add a proper access mode, and reverse the logic of the return value.
Zero ("Success") is returned on success from the hook calls.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Error: Write outside array bounds at Xext/geext.c:406
in function 'GEWindowSetMask' [Symbolic analysis]
In array dereference of cli->nextSib[extension] with index 'extension'
Array size is 128 elements (of 4 bytes each), index <= 128
Error: Buffer overflow at dix/events.c:592
in function 'SetMaskForEvent' [Symbolic analysis]
In array dereference of filters[deviceid] with index 'deviceid'
Array size is 20 elements (of 512 bytes each), index >= 0 and index <= 20
Error: Read buffer overflow at hw/xfree86/loader/loader.c:226
in function 'LoaderOpen' [Symbolic analysis]
In array dereference of refCount[new_handle] with index 'new_handle'
Array size is 256 elements (of 4 bytes each), index >= 1 and index <= 256
These bugs were found using the Parfait source code analysis tool.
For more information see http://research.sun.com/projects/parfait
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-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>
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>
0 is now reserved for the "AllDevices" virtual device.
1 is now reserved for the "AllMasterDevices" virtual device.
This also means that wherever we passed in (mskidx = 0), we now need to pass
in the deviceid.
Don't let everyone acces the filters[] array directly. This is necessary once
we start dealing with GenericEvents, where the filters are a bit more
complicated.
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>
This did access the wrong device's sync state, potentially freezing or not
thawing the actual device that was supposed to be thawed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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.
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>
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>
Yes, this is an ugly piece mess of #ifdefs, but it beats having two nearly
identical functions.
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>
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>
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>
If the MD's lastSlave was a devices with custom axes ranges, then a
WarpPointer would position the cursor at the wrong location. A WarpPointer
request provides screen coordinates and these coordinates were scaled to the
device range before warping.
This patch consists of two parts:
1) in the WarpPointer handling, get the lastSlave and post the event through
this device.
2) assume that WarpPointer coordinates are always in screen coordinates and
scale them to device coordinates in GPE before continuing. Note that this
breaks device-coordinate based XWarpDevicePointer calls (for which the spec
isn't nailed down yet anyway) until a better solution is found.
X.Org Bug 19297 <http://bugs.freedesktop.org/show_bug.cgi?id=19297>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit moves the focus handling from events.c into enterleave.c and
implements a model similar to the core enter/leave model.
For a full description of the model, see:
http://lists.freedesktop.org/archives/xorg/2008-December/041740.html
This commit also gets rid of the focusinout array in the WindowRec, ditching
it in favour of a local array that keeps the current focus window for each
device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A grep on xorg/* revealed there's no consumer of this define.
Quote Alan Coopersmith:
"The consumer was in past versions of the headers now located
in proto/x11proto - for instance, in X11R6.0's xc/include/Xproto.h,
all the event definitions were only available if NEED_EVENTS were
defined, and all the reply definitions required NEED_REPLIES.
Looks like Xproto.h dropped them by X11R6.3, which didn't have
the #ifdef's anymore, so these are truly ancient now."
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Save in a few special cases, _X_EXPORT should not be used in C source
files. Instead, it should be used in headers, and the proper C source
include that header. Some special cases are symbols that need to be
shared between modules, but not expected to be used by external drivers,
and symbols that are accessible via LoaderSymbol/dlopen.
This patch also adds conditionally some new sdk header files, depending
on extensions enabled. These files were added to match pattern for
other extensions/modules, that is, have the headers "deciding" symbol
visibility in the sdk. These headers are:
o Xext/panoramiXsrv.h, Xext/panoramiX.h
o fbpict.h (unconditionally)
o vidmodeproc.h
o mioverlay.h (unconditionally, used only by xaa)
o xfixes.h (unconditionally, symbols required by dri2)
LoaderSymbol and similar functions now don't have different prototypes,
in loaderProcs.h and xf86Module.h, so that both headers can be included,
without the need of defining IN_LOADER.
xf86NewInputDevice() device prototype readded to xf86Xinput.h, but
not exported (and with a comment about it).
This is the biggest "visibility" patch. Instead of doing a "export"
symbol on demand, export everything in the sdk, so that if some module
fails due to an unresolved symbol, it is because it is using a symbol
not in the sdk.
Most exported symbols shouldn't really be made visible, neither
advertised in the sdk, as they are only used by a single shared object.
Symbols in the sdk (or referenced in sdk macros), but not defined
anywhere include:
XkbBuildCoreState()
XkbInitialMap
XkbXIUnsupported
XkbCheckActionVMods()
XkbSendCompatNotify()
XkbDDXFakePointerButton()
XkbDDXApplyConfig()
_XkbStrCaseCmp()
_XkbErrMessages[]
_XkbErrCode
_XkbErrLocation
_XkbErrData
XkbAccessXDetailText()
XkbNKNDetailMaskText()
XkbLookupGroupAndLevel()
XkbInitAtoms()
XkbGetOrderedDrawables()
XkbFreeOrderedDrawables()
XkbConvertXkbComponents()
XkbWriteXKBSemantics()
XkbWriteXKBLayout()
XkbWriteXKBKeymap()
XkbWriteXKBFile()
XkbWriteCFile()
XkbWriteXKMFile()
XkbWriteToServer()
XkbMergeFile()
XkmFindTOCEntry()
XkmReadFileSection()
XkmReadFileSectionName()
InitExtInput()
xf86CheckButton()
xf86SwitchCoreDevice()
RamDacSetGamma()
RamDacRestoreDACValues()
xf86Bpp
xf86ConfigPix24
xf86MouseCflags[]
xf86SupportedMouseTypes[]
xf86NumMouseTypes
xf86ChangeBusIndex()
xf86EntityEnter()
xf86EntityLeave()
xf86WrapperInit()
xf86RingBell()
xf86findOptionBoolean()
xf86debugListOptions()
LoadSubModuleLocal()
LoaderSymbolLocal()
getInt10Rec()
xf86CurrentScreen
xf86ReallocatePciResources()
xf86NewSerialNumber()
xf86RandRSetInitialMode()
fbCompositeSolidMask_nx1xn
fbCompositeSolidMask_nx8888x0565C
fbCompositeSolidMask_nx8888x8888C
fbCompositeSolidMask_nx8x0565
fbCompositeSolidMask_nx8x0888
fbCompositeSolidMask_nx8x8888
fbCompositeSrc_0565x0565
fbCompositeSrc_8888x0565
fbCompositeSrc_8888x0888
fbCompositeSrc_8888x8888
fbCompositeSrcAdd_1000x1000
fbCompositeSrcAdd_8000x8000
fbCompositeSrcAdd_8888x8888
fbGeneration
fbIn
fbOver
fbOver24
fbOverlayGeneration
fbRasterizeEdges
fbRestoreAreas
fbSaveAreas
composeFunctions
VBEBuildVbeModeList()
VBECalcVbeModeIndex()
TIramdac3030CalculateMNPForClock()
shadowBufPtr
shadowFindBuf()
miRRGetScreenInfo()
RRSetScreenConfig()
RRModePruneUnused()
PixmanImageFromPicture()
extern int miPointerGetMotionEvents()
miClipPicture()
miRasterizeTriangle()
fbPush1toN()
fbInitializeBackingStore()
ddxBeforeReset()
SetupSprite()
InitSprite()
DGADeliverEvent()
SPECIAL CASES
o defined as _X_INTERNAL
xf86NewInputDevice()
o defined as static
fbGCPrivateKey
fbOverlayScreenPrivateKey
fbScreenPrivateKey
fbWinPrivateKey
o defined in libXfont.so, but declared in xorg/dixfont.h
GetGlyphs()
QueryGlyphExtents()
QueryTextExtents()
ParseGlyphCachingMode()
InitGlyphCaching()
SetGlyphCachingMode()
Device events always need to be delivered, core events only in some cases.
Let's keep them completely separate so we can adjust core event delivery.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
We need them for each window, every time a window is allocated. Storing them
in a devPrivate is the wrong thing to do.
This also removes the unused ENTER_LEAVE_SEMAPHORE_ISSET macro.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
grab == devgrab anyway, this is a leftover from the time when we had two
different grabs per device (core and XI grab).
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Really, this was a bad idea. It's not security, the UI features that would
have been cool (e.g. clicking through windows) aren't implemented anyway, and
there's nothing you can't achieve just by using plain XI anyway.
Requires inputproto 1.9.99.6.
Two corrections
1. the "detail" field has NotifyVirtual, etc., not the "mode" field. This was
a clear bug.
2. don't set/unset the flags for NotifyGrab or NotifyUngrab. Clients are
expected to deal with multiple enter/leave events per window if the mode is
not NotifyNormal.
Testable with TCL menu boxes (such as used in gitk):
tk_optionMenu .menu globVar Val1 Val2 Val3 ValJunk
pack .menu
Thanks to Michel Dänzer for pointing this out.
This fixes a severe issue - when the client died the event mask didn't get
unregistered and a future event would dereference dangling pointers. By
storing the event masks in the resource system we can free them when the
client dies.
Dereferencing into dev->valuator could crash the server, although it looks
like I could only reproduce this by having a keyboard send an event after it
was created and the WM was still replaying. Or so.
device->button->down used to be a 32-byte bitmask with one bit for each
button. This has changed into a 256-byte array, with one byte assigned for
each button. Some of the callers were still using this array as a bitmask
however, this is fixed with this patch.
Thanks to Keith Packard for pointing this out. See also:
http://lists.freedesktop.org/archives/xorg/2008-June/036202.html
RealizeCursor should be called when the cursor is allocated. However, when the
root cursor is allocated, no devices exist yet, and thus RealizeCursor is
never called. This may lead to segfaults lateron in DDXes like Xnest that
actually need to do something for each cursor, and lateron rely on that
DDX-specific data for each cursor has been initialized.
Instead of a simple counter, use bits to keep track of which device is where
etc. When device enters a window (or sets focus), the bit matching the device
is set, when it leaves again, it is unset. If there are 0 bits set, then
Leave/Enter/Focus events may be sent to the client.
Same theory as before, but this should get around the insanity with
Grab/Ungrab special cases. Those cases are basically untested though.
If an pointer event is being processed during a device grab, don't deliver it
to the focus window, even if the device has a focus class. Reason being that
some pointers may have a focus class, thus killing drag-and-drop.
Add Prox events to the if-clauses with the other events
that are usually sent from the input devices.
Ensure that the event deliverers won't try to deliver
events of type '0' (some extended events doesn't have
an equivalent core-type)
Small modification by Peter Hutterer.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
The latter is used to increase the amount of allocated memory for the event
list. This will be needed for ClassesChangedEvents that can be of more or less
arbitrary size (larger than 32 anyway).
Rather than letting the DDX allocate the events, allocate them once in the DIX
and just pass it around when needed.
DDX should call GetEventList() to obtain this list and then pass it into
Get{Pointer|Keyboard}Events.
The correct thing would be to return the ClientPointer. However, if the client
for some reason has a core grab on another device (e.g. as result of a passive
grab), return the coordinates of the grabbed device instead.
This makes the use of nautilus a bit saner.
If the window being changed is set as the motion hint window for any device,
the device's motion hint window is set to NULL. Which is kinda what the old
code did, except that it did it with only the VCP.
This is a significant shift in how input events are perceived. The common
approach was to treat a core event as a different entity than the XI event.
This could result in the XI event being delivered to a different client than
the core event. This doesn't work nicely if they come from the same device.
Instead, we treat an input event as a single event, that is delivered through
two separate APIs. So when delivering an event, we first try the XI event,
then the core event. If the window want's neither, we go to the parent and
repeat. Once either core or XI has been delivered, the processing stops.
Important: Different to the previous method, if a client registers for core
button events, the parent window will not get XI events. This should only
cause problems when you're mixing core and XI events, so don't do that!
Generic events don't fit into this yet, they cause me headaches.
This should restore the correct passive grab processing. When checking for
passive grabs, the core event is emulated and we check first for XI grabs on
the window, then for core grabs. Regardless of which event activates the grab,
the XI event is stored in the device's EQ.
When replaying the event, we take the XI event and replay it on the next
window, again including the emulation of the core event.
If we have one global filter, one pointer may change the filter value and
affect another pointer.
Reproduceable effect:
blackbox and xterm, start dragging xterm then click anywhere with the other
pointer (attached to different masterd device!). The button release resets
the filter[Motion_Filter(button)] value, thus stopping dragging and no event
is sent to the client anymore.
Having the filters set per device gets around this.
In some cases (e.g. using x2x) the previous model broke, with a window ending
not counting down to 0 anymore. Special treatment for NotifyUngrab seems to
help here.
Current solution: If a NotifyGrab is to be sent ignore it. If a NotifyUngrab
enter is sent, only adjust the semaphore if it is on 0. Likewise, do the same
for a NotifyUngrab leave if the semaphore is on 1. This seems to work alright
so far.
This can happen if we check for a passive core grab and our device is a
floating slave device. Doesn't really change anything as SDs can't send core
events but it stops the server from segfaulting.
FixKeyState needs to be able to handle XI events, otherwise we get "impossible
keyboard events" on server zaps and other special key combos.
(cherry picked from commit 5ee409794e)
In some cases a button press may activate a passive core grab. If the client
owning the passive grab already has a core grab on another device, don't
actually activate it. Otherwise the client gets two simultaneous passive
core grabs, and may never ungrab the device again (only if the other grab uses
GrabModeSync).
Reproducable: fire up gnome-session, open up gnome-terminal. Click with the
ClientPointer onto the window decoration, then click with another pointer onto
an application icon in the panel. Drag the icon out, release the button and
voila - you just lost your second mouse.
This is a half-assed attempt at getting rid of some enter-leave problems. When
a grab is activated, the events didn't get sent before, leading to interesting
results. This commit papers over it but doesn't actually fix it properly. The
whole enter/leave (focusin/out) structure needs to be ripped out and changed
for multiple devices.
* dix/events.c, include/dix.h:
(UpdateSpriteForScreen): added this to update the mouse sprite context
when we switch from a pScreen to another.
* mi/mipointer.c:
(miPointerWarpCursor): as we are switching to a new pScreen,
don't forget to update the mouse sprite context.
Let the drivers only generate XI events and put those into the event queue.
When processing events, generate core events as needed. This fixes a number of
problems with XKB and the DIX in general.
The previous approach was to put core events and XI events as separate events
into the event queue. When being processed, the server had no knowledge of
them coming from the same device state change. Anything that would then change
the state of the device accordingly was in danger of changing it twice,
leading to some funny (i.e. not funny at all) results.
Emulating core events while processing XI events fixes this, there is only one
path that actually changes the device state now. Although we have to be
careful when replaying events from synced devices, otherwise we may lose
events.
Note: XI has precedence over core for passive grabs, but core events are
delivered to the client first.
This removes the wrapping added in 340911d724
We need it unconditionally in a few places, and the rest checked for NULL and
then set it to VCK anyway. So, fixing up all callers to appreciate the defined
return value.
GenericEvents can't be parsed to keyButtonPointer, and there's no guarantee
that it has a time field anyway. PlayReleasedEvent needs to store the millis
when we know it (core events, XI event) and just re-use them for GenericEvents.
Yes, this is a hack. But it looks like the time has zero significance anyway.
The device state needs to be changed while processing the XI event. Core
events are always processed after XI, so by then the device is already set up
properly. However, we now rely on DeviceButtonMotionMask to be equal to
ButtonMotionMask. It already is, but stick a big fat warning in so nobody
attempts to change it.
This commit disables XKB for the VCK, thus essentially for all devices.
Temporarily anyway.
delivery of events to windows and clients.
This is tentative. It's likely that an additional last-resort hook will
be necessary for code that calls TryClientEvents or WriteEventsToClient
directly. It's also possible that new xace machinery will be necessary
to classify events and pull useful resource ID's out of them.
The failure case also needs some thinking through. Should event delivery
"succeed" or should it report undeliverable?
Finally, XKB appears to call WriteToClient to pass events. Sigh.
We shouldn't be able to restrict events like Expose, etc. with device based
ACLs. So we just ignore all non-input events when checking for permissions.