The problem happens if Monitor/Card combo doesn't provide EDID info,
and the XFree86-VidModeExtension extension is used.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
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.
Recording damage from other operations (e.g. creating a client damage record)
may confuse the migration code resulting in corruption.
Option "EXAOptimizeMigration" appears safe now, so enable it by default. Also
remove it from the manpage, as it should only be necessary on request in the
course of bug report diagnostics anymore.
GNU/kFreeBSD defines __FreeBSD_kernel__, but not __FreeBSD__.
Unify preprocessor conditionals between variable declaration and use.
Debian bug #482550.
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.
Event is always absolute, update the device's valuators (always absolute too),
and then change the deviceValuator event to reflect the device's reporting
mode.
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.
We can't rely on GPE to update device->valuators->axisVal. If a SIGIO occurs
during event processing this may have incoherent results.
This reverts commit f6645ddbf7.
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>
