We only have one set of default rules options in xkb. When the second keyboard
is brought up with Xkb options specified, these new options overwrite the old.
In future server generations, the rules used for the VCK are a mixture of the
default ones and ones previously specified for other keyboards. Simply
resetting the xkb default rules to NULL avoids this issue.
Reproducable by setting XkbLayout "de" and XkbVariant "nodeadkeys". In the
second server generation, the VCK has "us(nodeadkeys)". This again produces a
SIGABRT when the first key is hit.
I could not figure out why the SIGABRT happens. This patch is avoiding the
issue rather than fixing it.
The core protocol requires absolute values and it's a bit hard to get them if
we only have relative ones in the history. Switch the motion history to
absolute, and if we really need the relative values, we can probably generated
them from the abs. ones in the future.
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.
Since we can't predict how many valuators may be in a future SD attached to an
MD, we need to preallocate a history buffer that is large enough to keep
MAX_VALUATORS coordinates per event.
In addition, the history buffer needs to memorize the coordinate ranges at the
time, thus requiring MDs to store (min_val, max_val, current_val, time)
instead of (current_val, time) for each motion history entry.
This commit only fixes the allocation.
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.
master->last.valuator[x] for x > 2 is undefined. For all other devices, it's
the respective device's last valuators.
If the lastSlave did not have a valuator that is to be updated now, it is
reset to 0.
In GPE, we don't care about the device mode. Let's put the absolute values
into the deviceValuator event and worry about relative valuators on the other
side of the EQ.
Assuming master->last.valuators is in screen coords, SD's are always in device
coordinates.
1. If an event comes in, scale masters->last to the device, drop into device's
last->valuators.
2. Apply motion from the actual event
3. Scale back to screen coords, check if we may need to cross screens
4. Drop screen coords into master->last
5. Rescale to device coords, drop into deviceValuator event and SD->last
6. Drop screen coords into ev->root_x/y
Whoopee...
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.
Changed all the checks for x&y valuator so the more complex
calculation is only made once.
Added TODOs for valuator/axis 2 and above for future correct
handling of relative reporting of these.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
valuators[] is passed from the DDX. Depending on the device mode, update it
with either absolute values or relative values. The deviceValuator event sent
to the client will then contain the respective values.
This isn't quite finished yet, but at least it gives us the ability to use a
tablet as a normal mouse - with all the scaling in place.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
Conflicts:
Xext/xprint.c (removed in master)
config/hal.c
dix/main.c
hw/kdrive/ati/ati_cursor.c (removed in master)
hw/kdrive/i810/i810_cursor.c (removed in master)
hw/xprint/ddxInit.c (removed in master)
xkb/ddxLoad.c
Sometimes we didn't have a cursor when coming back from suspend. Reason was
that the suspend caused the server to lose the device that was attached to the
VCP, and a RemoveDevice() would then set the cursor to NULL.
Solution: only set the cursor to NULL if we actually own the sprite.
We pass in the client that wants to create the device anyway, lets use the
parameter instead of hardcoding the serverClient.
Wow. I hope this is merge detritus, otherwise it'd be a sign that I didn't
have enough coffee that day.
XQuartz was crashing because the Appkit thread was trying to GetXXXEvents while the Xserver thread was exiting.
This adds some more sanity checks and avoids that crash
(cherry picked from commit 34ec4bd6ac)
When a new device is added, calculate the event size needed if a DCCE event is
sent and set the EQ's event size to this minimum. This avoids reallocs when a
event is sent (which may happen during a SIGIO).
This variable was used originally to determine which client is allowed to
change the pointer-keyboard pairing. For now, we just let anyone change it and
see how that works out.
(cherry picked from commit 4e2c6dbabdbbaaca213fd08edd422de15d0900cc)
required because of commit 7c0709a736,
which made requestingClient in dix specific to Xprint only.
Add to XPRINT_LIBS in hw/xprint/Makefile.am in front of
$(XSERVER_LIBS) to override definitions in libdix.la for standard xservers.
Follows 571206832d (providing -DXPRINT
to xprint subdirs).
Note it may be possible to restructure the code so that
requestingClient is stored elsewhere than in dix. See discussions
following http://lists.freedesktop.org/archives/xorg/2008-March/033844.html
If this is done it may be possible to revert this commit (if not 571206...).
Rather than freeing/allocing classes each time the device capabilities need to
swap, store them in the devPrivates system.
When a class is unused, it is pushed into the devPrivates, and later recovered
when needed again. This saves us a lot of memory allocations/frees, admittedly
on the cost of some memory.
The DDX (xfree86 anyway) maintains its own device list in addition to the one
in the DIX. CloseDevice will only remove it from the DIX, not the DDX. If the
server then restarts (last client disconnects), the DDX devices are still
there, will be re-initialised, then the hal devices come in and are added too.
This repeats until we run out of device ids.
This also requires us to strdup() the default pointer/keyboard in
checkCoreInputDevices.
X.Org Bug 14418 <http://bugs.freedesktop.org/show_bug.cgi?id=14418>
The device classes aren't deleted anymore on a class change, so there's no
need to store the MD's original classes. We should however restore the MD to
sane defaults when disconnecting the last device, consider this as TODO item.
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.
InitializeSprite won't create a new one if it already exists, with the result
of overwriting the master's sprite. This master sprite is then assigned to the
floating slave, and freed when the slave is reattached later.
Setting the sprite to NULL forces InitializeSprite to alloc a new one, and
this one can be freed without further repercussions.
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>
XkbFinishDeviceInit does the following:
xkbi->kbdProc= pXDev->kbdfeed->CtrlProc;
pXDev->kbdfeed->CtrlProc= XkbDDXKeybdCtrlProc;
If we directly copy the device classes for the VCK, pXDev->kbdfeed->CtrlProc
at the time of copying is still XbkDDXKeybdCtrlProc. So at some point
XkbDDXKeybdCtrlProc is called, and calls itself, and calls itself, and...
Setting the device's classes to NULL seems to fix things. The memory isn't
lost, it gets stored into the devPrivates and freed at device closing time.
To recap: the original XC-SECURITY extension disallowed background "None" if
the window was untrusted. XACE 1.0 preserved this check as a hook function.
XACE pre-2.0 removed the hook and first abolished background "None entirely,
then restored it as a global on/off switch in response to Bug #13683.
Now it's back to being per-window, via a flag instead of a hook function.
Before we enable the device through the driver, we size it up and make sure
that the events in the event list contain enough bytes for a possible
ClassesChangedEvent lateron.
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.
AllowAll is the last check before the parent window is checked. This allows
to override a DenyAll in the parent window in a simpler way than before (the
previous method required all devices to be in the permit list).
In the case that the device cursor was the first in the list of cursors
the window knew about, unsetting the cursor could lead to a segfault
due to pPrev being NULL. Instead catch the condition and correctly remove
the node from the list. Since there is no cursor now set on the device,
we simply return success as the parent windows cursor will propogate
down later.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
Relative events that generates both core and extention
events will have its axis cliped and screen changed by
miPointerSetPosition when the events are processed. For
absolute and non core-generating relative events the
axis must be clipped if we shouldn't end up completely
outside the defined ranges (if any).
Don't use a possitive value as a marker for if a max-value
is defined on the valuators. Use the existence of a valid
value range instead. This will also make it possible to
define arbitrary start and end-values for min and max as
long as min < max.
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.
Composite uses an unmap/map cycle to trigger backing pixmap allocation
and cliprect recomputation when a window is redirected or unredirected.
To avoid protocol visible side effects, map and unmap events are
disabled temporarily. However, when a window is unmapped it is also
removed from grabs and loses focus, but these state changes are not
disabled.
This change supresses the unmap side effects during the composite
unmap/map cycle and fixes this bug:
http://bugzilla.gnome.org/show_bug.cgi?id=488264
where compiz would cause gnome-screensaver to lose its grab when
compiz unredirects the fullscreen lock window.
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 two devices are attached to the same master device, pressing button 1 on
each of them leads to two button presses from the same device. Some apps
really don't like that.
So we just put a counter in place and only send the first press and the last
release.
(first_valuator + num_valuators) must never be larger than the number of axes,
otherwise DIX freaks out. And from looking at libXI, anything larger than 6 is
wrong too.
(cherry picked from commit 9f6ae61ad1)
