This happens if any of the vendor-specific reports is used.
SDL triggers the mode switch when calling SDL_GameControllerSetSensorEnabled()
on supported devices.
This is a one-way transition, i.e. cannot be undone without restarting
the controller, so it's fine to have it tied to lifetime of winebus.
Signed-off-by: Arkadiusz Hiler <ahiler@codeweavers.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This partially reverts b431dceeca, which
followed some misleading SDL comment, as well as the original dinput
evdev backend code, and resulted in inverted directions instead.
On the Linux drivers side, both in the PID driver or the I-Force driver,
the evdev direction is simply rescaled and passed to the device. It is
then very likely that we should pass through the PID reports direction.
In some other drivers, the sine of the angle is used to modulate the
force magnitude, although that doesn't really tell anything about the
orientation of the direction itself.
The SDL comment is incorrect, and its code isn't actually doing any kind
of conversion other than the rescaling. We now do the same here, and end
up with identical values being sent to evdev, whether we use it directly
or through the SDL library.
It's also been confirmed with hidraw PID capable devices, that with this
change, the direction values in the hardware PID reports are consistent
between the three backends (SDL, evdev, and hidraw).
If some devices are expecting inverted directions then it probably is
something that will need to be solved on the Linux driver level.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51922
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The first direction in HID PID reports seems to be in polar space,
rotated by 90° compared to the spherical coordinate space used in
dinput. We need to fixup the directions to match Linux FF or SDL
direction coordinate space.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51922
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
DInput will only send the output reports that have been modified, we
need to support sparse effect updates.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52061
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Fixes the device names appearing with the first words in joy.cpl
and probably in games, when the UDEV bus is used in HIDRAW mode.
Signed-off-by: Ivo Ivanov <logos128@gmail.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
In a container with a non-trivial user namespace, we cannot rely on
libudev communicating with udevd as a way to monitor device nodes,
for the following reasons:
* If uid 0 from the host is not mapped to uid 0 in the container, libudev
cannot authenticate netlink messages from the host, because their sender
uid appears to be the overflowuid. Resolving this by mapping uid 0 into
the container is not allowed when creating user namespaces as an
unprivileged user, and even when running as a privileged user, it might
be desirable for the real uid 0 to not be mapped as a way to harden the
security boundary between container and host.
* Depending on the container configuration, initial enumeration might
not be able to read /run/udev from the host system. If it can't, sysfs
attributes will still work because those are read directly from the
kernel via sysfs, but udev properties coming from user-space rules
(in particular ID_INPUT_JOYSTICK and friends) will appear to be missing.
* The protocols between udevd and libudev (netlink messages for monitoring,
and /run/udev for initial enumeration) are considered to be private to
a particular version of udev, and are not a stable API; but in a
container, we cannot expect that our copy of libudev is at exactly the
same version as udevd on the host system.
Sidestep this by adding a code path that continues to use libudev for
the parts that work regardless of whether udevd is running or can be
communicated with.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
As per https://github.com/systemd/systemd/blob/v247-rc1/NEWS#L5
there are more kernel uevent types than just "add" and "remove",
and we should be treating everything other than "remove" as being
potentially an "add".
To cope with this, try_add_device() now checks whether the same device
was already added. If so, we ignore it.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Based on a Proton patch from Andrew Eikum <aeikum@codeweavers.com>.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
These contain the bluetooth dongle VID / PID instead.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This avoids keeping two copies of each string.
It also fixes a regression on macOS from commit 9d4b70473c
that incorrectly treated a CFStringRef as a char ptr.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Advertising support of the periodic effect types only for now.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
And include it in the HID report descriptor when SDL device has support
for any haptic effect, or when UDEV lnxev device has any FF bit set.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
To keep lnxev_device functions and related helpers all together.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
commit 40a9f69a1d
winebus.sys: Rename UDEV bus device variables to be consistent.
Introducing a struct base_device, and hidraw_device / lnxev_device
depending on the sub-type of the device.
moved an existing use of ABS_VOLUME that was guarded by
#ifdef HAS_PROPER_INPUT_HEADER
outside that guard, breaking the build on non-Linux platforms.
Address this by putting appropriate guards in place.
Signed-off-by: Gerald Pfeifer <gerald@pfeifer.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Rémi Bernon