While the original idea was to have a consistent reporting order between
the X52 and X52 Pro, it causes issues in applications like Wine. This
commit updates the reporting such that it sends the exact same report as
the kernel with the quirks enabled.
Addresses: #51
This commit adds the kernel driver for the Saitek X65F joystick. This is
necessary, since it has the same limitation with the thumbstick not
getting recognized on older kernels. The quirks fix has been pushed to
newer stable kernels, and therefore do not require this driver.
The X52 and X52 Pro report the buttons in different orders, e.g., the
mouse primary button is button 30 on X52, but is button 15 on the Pro.
This change ensures that the reported values is consistent between the
different devices.
This workflow runs only if there is a change to the kernel_module path.
Consequently, commits that only impact the kernel_module will be ignored
for the standard userspace driver build.
This commit also updates the CodeQL workflow to only run on a scheduled
basis and on pull requests, but not on every push, since this is a
fairly slow script.
Finally, this commit also removes the obsolete kernel module sources,
since they are no longer maintained, and it also provides a hook for
Github actions to pick up and execute the kernel workflow.
This change replaces the old USB driver with a more modern HID driver.
This uses the HID framework, which means that we don't have to deal with
the USB transport, and only have to parse and report input events.
[skip ci]
Previous commit used pr_err/pr_debug because it mistakenly assumed that
the device pointer was not available. This ensures that the driver uses
the dev_err and dev_dbg functions wherever it can.
err macro has been removed entirely from the Linux kernel starting from
around v3.5, while the dbg macro has been deprecated. Since the lines
that were using err/dbg did not have access to the device, simply log as
a generic kernel log.
The le32_to_cpu function doesn't quite work for some reason. Manually
writing the 32-bit conversion seems to fix the axes reporting for
ABS_X, ABS_Y and ABS_RZ.
This still could use a bit of investigation to see why
input_set_abs_params called with non-zero values for fuzz and flat
causes axis motion to be ignored, although it may be a driver
subsystem issue in Linux.
Due to plans to scrap the kernel module approach and go with a full-fledged
userspace application, this commit renames the driver folder to kernel_module
so the folder contents are clear.