Add CI jobs for building on debian-i386 (just had amd64 yet), so we can
also test 32bit targets.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Adding a gitlab pipeline building this driver against Xserver major releases
since 1.18, including current master branch, on FreeBSD and Debian.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Adding a bunch of common scripts for building xorg drivers on different
platforms (for now Debian and FreeBSD) against different server versions.
Also designed to be executed locally (eg. within a VM), so one doesn't
always have to employ f.d.o gitlab.
For now, these are synced manually across various driver repos, until we've
found a viable solution for a central place.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
/usr/include/xorg/xf86_OSproc.h:115:23: error: type of 'xf86EnableIO' does not match original declaration [-Werror=lto-type-mismatch]
115 | extern _X_EXPORT Bool xf86EnableIO(void);
| ^
vmmouse_iopl.c:125:6: note: return value type mismatch
125 | bool xf86EnableIO(void)
| ^
Tested with FreeBSD, but changes affect also OpenBSD and NetBSD to fix
compiling and linking with the relevant system libraries.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Acked-by: Sinclair Yeh <syeh@vmware.com>
The access restrict command, if implemented, restricts vmmouse port
access to the indicated level.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Michael Banack <banackm@vmware.com>
Many distros already include patches to do this in various more or less
hackish ways. Since VMware now is about to restrict access to the VMmouse
backdoor, let's try to support it officially.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Acked-by: Sinclair Yeh <syeh@vmware.com>
xf86_OSproc.h cannot be included without first including xorg-server.h.
Without this the build fails on systems with the latest glibc,
throwing this error:
In file included from /usr/include/string.h:634:0,
from /usr/include/xorg/os.h:53,
from /usr/include/xorg/misc.h:115,
from /usr/include/xorg/window.h:50,
from /usr/include/xorg/globals.h:7,
from /usr/include/xorg/opaque.h:34,
from /usr/include/xorg/xf86_OSproc.h:127,
from vmmouse_client.h:42,
from vmmouse_client.c:38:
/usr/include/xorg/os.h:579:1: error: expected identifier or '(' before '__extension__'
strndup(const char *str, size_t n);
This is caused by HAVE_STRNDUP not being set (it is set from xorg-server.h),
causing os.h to redefine it.
Signed-off-by: Stefan Dirsch <sndirsch@suse.de>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Thomas Hellstrom <thellstrom@vmware.com>
If a vmmouse kernel driver is active, vmmouse input is handled by the Xorg
evdev driver and not by the vmmouse driver, so make sure the vmmouse_detect
utility doesn't detect a vmmouse if a kernel driver is active.
v2: Change the vmmouse kernel device name, fix comment.
v3: Fix up libudev error handling.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Wheel is using buttons 4/5, but btn_labels array is 0-based.
It matches mouse and evdev drivers, and fixes wheel in Qt5.3.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This fixes some build warnings about CSRG_BASED being redefined due to
incorrect header include ordering.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
The location of the udevdir is obtained from pkg-config. This is generally
/lib/udev. Most people run their build scripts as non-root and do not want to
overwrite or add files on their workstation system.
This was not the behaviour in release 12.8.0. The code in configure.ac set
udevdir based on common installation prefixes /usr or /usr/local for which
the user would probably have root permission anyway. Other prefixes would
be assigned a udevdir value under the given $prefix.
The patch proposes the default location $libdir/udev/rules.d and no longer
seeking it's value from pkg-config, just like what was done for hal.
The expectation is that the xorg source tree can be built from top to bottom
out of the box without tweaks or workarounds. A developer need to
manually install a rule under development and run an admin command for it to
take effect. Unlike binaries or libraries, there is no "path" style
variable to append a rule in development from a different location.
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
If the device fails PreInit, UnInit is still called by pMse may be NULL.
Dereferencing it is a bad idea.
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unable to create a tar file for the vmmouse package or run distcheck for that
matter. In tools, when the dev package is not installed, the makefile code
under HAS_UDEV_RULES_DIR is commented out. That leaves $(udev_DATA) empty
which causes EXTRA_DIST to be missing a file.
The solution is to spell out the file name. The name can never change as the
content of the tarball must be the same for everyone creating a tar file from
git, regardless of their workstation configuration.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
All other X.Org modules and mainly the server are using C99 compiler.
Currently the compiler gets initialized twice, once to C99 from
util-macros and once to C89 from configure.ac.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
xf86DeleteInput() will free pInfo->private, but not the one hanging off
that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Zack Rusin <zackr@vmware.com>
vmmouse.c: In function 'MouseCommonOptions':
vmmouse.c:732:16: warning: variable 'from' set but not used
[-Wunused-but-set-variable]
vmmouse.c: In function 'MouseCommonOptions':
vmmouse.c:733:8: warning: variable 'origButtons' set but not used
[-Wunused-but-set-variable]
vmmouse.c: In function 'VMMouseDeviceControl':
vmmouse.c:838:19: warning: variable 'mPriv' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
This reverts commit 189dc266a6.
It seems that for some reason the device routing is breaking with this.
Possibly related to Win7 x64 hosts because it's not reproducible on
GNU/Linux hosts. Semantially we'd still like to match only on mouse
kernel but for the time being this seems to cause more problems
than it solves. Hence the revert.
Moved up in the autoconf init section.
It has been removed from Automake 1.12.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Signed-off-by: Zack Rusin <zackr@vmware.com>
Vmmouse driver uses outl calls but never requests hardware access.
In case there are no other drivers that requests it, vmmouse
initialization will fail. (Found on KVM virtual machine with fbdev
graphics driver and vmmouse input driver.)
Request hardware access in same way xf86-input-keyboard does.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Some distros (most notable OpenSuSE) are unable to match on the
'event' devices, since we should be using 'mouse' kernel anyway
(because that's what the 'udevadm info' reports) switch to it in the
rules file.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
