x52test doesn't perform any checks to see if the connected device
supports setting individual LEDs. Therefore, if an X52 (non-Pro) was
connected when running x52test, it would fail when running the LED
tests, and not perform any of the subsequent tests.
By moving the LED tests to the end, this allows the other tests to run
on a non-Pro X52. Although the tests would still fail, it won't actually
break anything.
Addresses #19.
x52test used to assume that a positive return code indicated a signal
was received and a negative return code indicated an error in libx52.
However, libx52 was changed a while back to return only a positive error
code of type `libx52_error_code`.
This commit changes that assumption, so that:
* The first check is always against `LIBX52_SUCCESS`, to ensure that any
change in the enumeration won't break the rest of the code.
* Tests terminated by a signal return the negated value of the signal,
i.e. -15 is SIGTERM and -2 is SIGINT.
* Tests that fail within libx52 return a standard `libx52_error_code`.
* Error printing uses `libx52_strerror`.
Addresses #19.
Prior to this change, x52cli assumed that the return code from the
handler was a standard error code, but negated. This is an incorrect
assumption as the libx52 API returns a `libx52_error_code` enum, which
is a positive integer.
This change fixes the printing of the error message to call
`libx52_strerror`, which translates it correctly. It also adds error
printing to any failure of `libx52_init`, as well as explicitly
specifying `LIBX52_SUCCESS` instead of `0`.
Addresses #19.
This disables the include file list and dependency graph in the file
view. In addition, the groups are updated to include `libx52` in their
names, to avoid any potential conflict.
[skip ci]
This change exposes the libx52_hotplug_* functions in libx52.h to allow
other programs to link against them.
This commit also adds Doxygen comments, and groups the declarations by
their function, for later use in Doxygen integration.
This allows the caller to register a callback and forget about it. This
is useful in cases where a particular callback needs to be run
everytime, and there is no point in deregistering it until the
application terminates, at which point `libx52_hotplug_exit` will take
care of the cleanup.
Ubuntu Trusty doesn't ship with a new enough pkg-config, which causes
the PKG_INSTALLDIR macro to fail on those systems. Since Trusty is EOL
anyway, simply disable the CI build on it.
Prior to this change, the libusbx52 Makefile was manually specifying the
pthread flags to indicate that the linker needed to link against the
pthread libraries.
This change moves the pthread detection logic out to configure.ac, and
updates the flags in libusbx52 Makefile to use the pthread compiler.
Prior to this change, libx52 would require that the X52/Pro be plugged
in before initialization. This change allows the application to
initialize libx52 even before the device is plugged in.
This commit adds OSX to the build matrix, as well as building on Trusty,
Xenial and Bionic, both with GCC and CLang on all distributions. For
now, the OSX build uses the default image provided by Travis CI, but we
may decide to add more images in the future.
Also move realpath installation out of addons::apt::packages, since on
Xenial and newer distributions, realpath is included in the coreutils
package and doesn't need to be explicitly installed. However, we still
need it on Trusty, so add a line to manually install it.
x52test by default expects to run with an attached X52 unit. Since the
primary goal of the program is to test the hardware, it has embedded
delays to allow the user to verify the individual LEDs, MFD, brightness,
etc.
However, the complete test takes about 6 minutes. When using the stub
libusb library, the goal is to capture the requests, not verify it
against the hardware. In this case, the delays serve no useful purpose.
This change adds a nodelay flag, which is controlled by the presence of
a `NO_DELAY` environment variable, or the `LD_PRELOAD` environment
variable. As long as either of these variables are present in the
environment block, there will be no delays in the test execution.
The stub libusb library used for testing writes the control request to a
dump file. By default, this file is block-buffered, and on a typical
Linux system, it waits until it receives about a page worth of data
before flushing it to disk. This results in a delay in monitoring
packets when running a debug program.
This change makes the file line-buffered instead, which results in the
debug output for every single packet getting flushed to disk without
having to wait for a full page of data.
With the release of libusb 1.0.22, `libusb_set_debug` has been
deprecated and replaced by `libusb_set_option`. This function is a new
generic API to add additional functionality in the future without having
to introduce new functions.
This change checks for `LIBUSB_API_VERSION` of at least `0x01000106`,
which is the version corresponding to 1.0.22, and if it matches, it
replaces the calls to `libusb_set_debug` with equivalent calls to
`libusb_set_option`.
These new error codes correspond to similar ones returned by libusb, but
abstract away the usage of libusb underneath libx52. This lets the
application rely solely on libx52 error codes to perform error handling.
- libx52_init returns the libx52_device in an output parameter and
returns a libx52_error_code
- Make all functions return libx52_error_code
- Update package version to indicate incompatible API change
The raw time and date APIs bypass the timezone calculation and update
the internal data structures with the requested time in hh:mm and date
in dd/mm/yy formats.
This is unlikely to be used often, but it is useful during testing.
nirenjan