A missing comma at the end of the STRINGIFY line was causing builds with
clang to have segfaults with the default configuration. It turned out
that due to the missing comma, the N_("Unknown LED state %d") and
N_("off") parameters were getting merged into a single parameter by
clang, but interestingly, not by GCC.
As a result, when building with clang, the array is "on", "red",
"amber", "green" - note the missing "off" at the beginning of the array.
This causes clang generated builds to segfault when attemping to log a
trace message when configuring LED A (which defaults to green, and the
index of LIBX52_LED_STATE_GREEN exceeds the array bounds).
This uses the published device IDs for the Saitek X52 (non-Pro) model.
However, based on my knowledge, the X52 uses single color LEDs compared
to the X52 Pro's tri-color LEDs (Red/Amber/Green). For the time being,
until we can determine the actual control messages being sent to the
X52, setting the LED state will not be supported.
This commit also operates on the assumption that the other controls are
the same as the X52 Pro, specifically the following:
- Setting MFD/LED brightness
- Setting MFD text
- Setting blink and shift
- Seting time and date on the MFD clock
Issue: #11
This is used by an application to check if it needs to call
libx52_update. If libx52_set_clock returns 0, it can be assumed that the
clock did change values that require an update, but any other value
indicates that an update is not required.
Compare the stored clock value against the requested value and only
send the USB vendor control messages if necessary. This should reduce
the number of messages from 5 for every clock update to 1-3, depending
on whether the date has changed or not. Only if the timezone of the
default clock changes should the additional 2 messages for the offset
clocks be sent.
This file is parsed during compilation time to generate a static lookup
table which is used to convert UTF-8 text to a character supported by
the X52 MFD.
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.
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.
nirenjan
Ryan Drake