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>
This copies over the files generated from mesa/src/mesa/glapi. There's
a corresponding mesa commit that makes it easy to generate the glapi files
straight into the xserver tree when the XML definitions change.
The only few files that are copied from mesa but aren't generated are
glapi.[ch] and glthread.[ch]. Everything in there is technically DRI
driver API and the whole setup is still a bit fragile, but it's not a new
problem.
The --with-mesa-source configure option is still around since other
parts of the server (XGL and DMX - grep for MESA_SOURCE) need that,
but for common case of building with GLX and AIGLX support, that
option is no longer needed.
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.
