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>
Those tables were once used to decide what symbols are visible to
modules, but they were outdated. The only real usage was that, since
it was taking the address of symbols, linkage should fail if the
symbols were not available.
Now the proper way to make symbols available to modules should
be to use the _X_EXPORT macro, or not compile with hidden symbols,
so that all symbols would be available.
All symbols in the tables were revised to ensure they are exported,
and only symbols that were not exported are ClientSleepUntil() and
DuplicateModule(), that were not in the sdk for quite some time
already, and should not have any users outside of the X Server
(and/or builtin modules).
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).
I merged the wrong patch. See correct patch at:
http://lists.freedesktop.org/archives/xorg/2008-November/040540.html
Not activating the device before attempting to enable it would leave the
sprite unset, crashing the server when enabling the real devices.
This reverts commit e078901a4e.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Adam Jackson <ajax@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>
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.
Add each event to the master's MH as well as to the SDs. In the MD, store
min/max and the actual value. When retrieving the MH, rescale all coordinates
to the current coordinate range and only post those valuators that are
currently active on the device.
With the MD/SD device hierarchy we need control over the generation of the
motion history as well as the conversion later before posting it to the
client. So let's not let the drivers change it.
No x.org driver currently uses it anyway, linuxwacom doesn't either so dumping
it seems safe enough.
During GetPointerEvents (and others), we need to access the last coordinates
posted for this device from the driver (not as posted to the client!). Lastx/y
is ok if we only have two axes, but with more complex devices we also need to
transition between all other axes.
ABI break, recompile your input drivers.
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.
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.
Turns out it's really really hard synchronising device state across multiple
duplicated events if they all share the same struct. So instead of doing so,
when the SD changes deep-copy all it's classes into the MD. The MD then has
the same capabilities, but the state can be set separately. This should fix
xkb, key state, repeat etc. problems.
Updating the device state allows us to remove the SwitchCoreKeyboard from the
event gathering, it's all done during event processing now.
Set isMaster for VCP/VCK.
Init sprites for master pointer devices.
Pair master kbds with master pointers (1:1 pairing!).
Attach other devices to VCP/VCK.
For now, we don't allow attaching slaves to other slaves, and we don't allow
pairing slaves with other slaves.
Pairing is for master keyboard->master pointer only.
Attaching is for slave device->master device only.
Removes "LookupKeyboardDevice" and "LookupPointerDevice" in favor of
inputInfo.keyboard and inputInfo.pointer, respectively; all use cases
are non-XI compliant anyway.
over to new system.
Need to update documentation and address some remaining vestiges of
old system such as CursorRec structure, fb "offman" structure, and
FontRec privates.
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.
Add RawDeviceEvent (pointers only for now).
This commit changes the event queue to use EventLists instead of xEvent
arrays. Only EQ is affected, event delivery still uses xEvent* (look for
comment in mieqProcessInputEvent).
RawDeviceEvents deliver driver information to the client, without clipping or
acceleration.