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.
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>
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
If the monitor isn't reduced-blanking (either through EDID logic, or
config file setting), then remove RB modes from the default pool. Any
RB modes from the driver and config file pools will stick around though;
you asked for them, you got them.
Seeing as this code seems to be specific to OpenBSD I don't think
__x86_64__ should have been added there at all. It appears to have
been added wherever __amd64__ existed before which is wrong. I
think that part of the commit should be reverted but also all four of
the checks should be __OpenBSD__ && __amd64__ instead of two one
direction and two flipped.
The first guess used to be "is the preferred mode for one output the
preferred mode on all outputs". Instead, do "find the largest mode that's
preferred for at least one output and available on all outputs".
Old logic was just the first one that happened to have an associated
CRTC. The new logic tries to find one that's definitely connected, has
probed modes, and has the largest candidate mode.
Most of these drivers didn't work. ati was the only one that even came
close. The igs, ipaq, itsy, pcmcia, savage, sis530, trident, trio, ts300,
and vxworks directories have never built since modularisation, so clearly
no one can miss them.
Peter Hutterer
Magnus Vigerlöf
Adam Jackson
Jeremy Huddleston
Julien Cristau
Dave Airlie
Brad Smith