The vendor command interface allows the user to write a vendor request
packet using the known vendor interface. However, it is not intended for
regular use, since the existing API is better suited to abstract it away
from the user. Rather, the prime goal is for a test harness interface
that can be used to debug problems seen during regular library accesses.
Sometimes the vendor control request failes with LIBUSB_PIPE_ERROR. Most
of the time a retry fixes it right away. To allow for a transient
failure, make the function retry the control transfer up to 3 times
before failing.
Report descriptor can be obtained from
/sys/bus/hid/devices/.../report_descriptor.
Once dumped in hex, the parser at
http://eleccelerator.com/usbdescreqparser/ can convert it to a human
readable format.
This is still a relative work-in-progress, since some of the functions
are being cleaned and enhanced to provide proper functionality similar
to the Windows driver.
The current contents of the libx52 folder contain all the source code
necessary to implement the X52 Pro vendor API. These have been tested,
although the committed test file does not list all the APIs.
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.
This brings in changes to make the kernel module act like an input
device. However, this version does have one flaw, in that the axes
input for all the centered axes does not work. This is most likely
due to a bug in the invocation of input_set_abs_params. Only the
throttle and slider axes work, as does the hat. The other (minor)
issue is that the hat values show up as -32767 and +32767 instead
of -1 and +1 like the usbhid driver.
Because the joystick type was never set, the input irq handler never
called the x52pro_decode_urb function. This fixes that issue, however,
it still needs verification that the changes work.
This change adds an input device for the Saitek X52 pro flight control
system. However, with this change, there is some bug which causes a
kernel crash. Still debugging, but committing so that I don't lose data.
This adds a list of supported devices with flags for each device.
The flags control whether the MFD and/or LED are supported for
each supported device.
This also changes the deadzone structure to be more compliant with
the fuzz and flat parameters for absolute input.
This change moves the common definitions to their own file so
that we can later rewrite the driver to accept the structure
as input.
A caveat with this approach is that it does prevent shell scripts
from updating the joystick, however, it eases the burden of
verification in the kernel, and it's not too hard to write
wrapper programs to write kernel structures to the files.
Earlier versions of the module could be rmmod'ed while the X52 joystick
was still plugged in and running. Unplugging the joystick after the
module was removed resulted in a kernel crash.
With this change, the X52 USB control API is moved to it's own
file in order to better separate the code and make it cleaner.
This change also renames the kernel module to saitek_x52.
This commit adds sysfs files to enable or disable the LEDs on the
X52 Pro joystick. This also fixes a minor bug with the brightness
API which was always complaining not-supported.
nirenjan
Nirenjan Krishnan