The notify module controls the logging settings for the notify socket
code. While missing this doesn't cause any impact to the notify code, an
invalid module name sent on the command socket could cause the daemon to
crash with a NULL pointer access.
libusb requires the application to call one of the
`libusb_handle_events` functions in order for hotplug events to actually
get dispatched. We don't need to wait for any timeout, so we use a
default timeout of 0, which should process any pending events, and then
return immediately.
A test of repeatedly disconnecting and reconnecting a virtual device
using USBIP was done, and no crashes of the daemon were observed.
Github-Issue: https://github.com/nirenjan/libx52/issues/43
This change adds logic to block signals on child threads. This is done
so that we can migrate signal handling to the main thread, even if we
add additional threads in the future.
This change adds a ReverseScroll parameter to the configuration, which
if set, will change the direction of the scroll wheel of the virtual
mouse.
Github-Issue: #45
This change adds support for the public beta of Ubuntu 22.04 and
macOS 12. As this is a beta, this change also updates the
continue-on-error field to indicate that a build failure on the 22.04
runner should not cause the rest of the build to fail.
[skip doxy]
When building with coverage enabled, the compiler complains about
missing definitions for setlocale and LC_ALL. These can be found in
locale.h, and by including it in gettext.h, we can ensure that we won't
see any more such issues.
Since the introduction of X macros to the CLI handling code, there will
never be a condition where the handler will be NULL. This is a legacy
check from when the code had individual maps that were maintained by
hand.
Prior to this change, on failure condition, x52cli would exit with a
code that mapped directly to the return code of the function. This was
inconsistent with the behaviour if the initialization or connect steps
failed for any reason.
When running in foreground, it is likely that it is running within
systemd. In this case, a stale PID file is likely to have a PID that
corresponds to a different process, which can still be kill'ed by the
root user. This results in a false positive that the process is still
running and causes the daemon to abort prematurely.
Fixes#42
This change adds a test suite for validating mouse configuration. This
only tests the logic for mouse thread enable/disable and mouse speed
calculations.
Prior to this change, the Git version was only getting generated when
the call was made to autoreconf. This was resulting in stale version
info.
This change, by contrast, generates the build info at the call to make.
While this doesn't completely eliminate the stale version issue, it's
easier to work around, by simply running `make clean`, `make`.
For some reason, the CI runs on Github Actions block the macOS runners,
and they take forever to run the tests. The tests are really needed only
on Linux, and the errno values that it uses are only verified to work on
Linux.
This change adds an automated test harness that will spin up an instance
of the X52 daemon, connect to its command socket, send commands and
validate the responses. This first set of test cases simply validates
the basic configuration file handling. Subsequent commits will enhance
the tests to improve code coverage.
The configuration processing works as follows - the configuration
parameters are set in memory, and an apply function applies all the
changes directly to the device. While this works during startup and
reload, it adds a needless overhead when processing config set commands
from the command socket.
This change makes it such that a `config set` command would update the
configuration for that particular key, and then immediately call the
callback function for that key. This has the effect that individual
configuration changes are visible immediately, without having to reapply
every other configuration that hasn't changed.
This commit also removes the `config apply` command, since it is no
longer needed. The `config load` and `config reload` already handle
applying the configuration after reading it.
Prior to this change, the IO thread would always report a mouse button
event, even if the mouse was disabled in configuration, or the uinput
device was not created. This results in unexpected button/wheel events.
This change checks that the uinput device has been created and the mouse
has been enabled in the configuration before reporting a button or wheel
event.
Prior to this change, there were spurious build failures seen in Github
CI, especially on macOS builds, where one test out of ~2000 would fail
randomly. After adding an option to display the diagnostics, it was
determined that the failure was only in the tests that included the
timestamp. This was because the time call was returning different values
between `test_setup` and `pinelog_log_message`. Even though they may
have been called milliseconds apart, the time skew was enough to have a
1 second difference between the two returned values.
This change overrides the `time` method from libc, and returns a static
value. With this change, CI should work fine regardless of how slow the
tests run.
This change adds the `logging show` and `logging set` commands to the
command processor module. This allows setting the log levels of the
individual modules via the socket.
Prior to this change, if a module had not registered a name, then the
output would display `(null): `, which was not really helpful. This
change eliminates that by checking if the module name is not NULL prior
to calling the print routines.
This commit adds the following changes to pinelog:
- Optional buffer to write the message to prior to writing to the output
stream. This reduces the likelihood of log messages from multiple
threads interleaving due to multiple calls to fputs/fprintf, etc. The
default is to still write directly to the output stream, but the
integrator can add a define of PINELOG_BUFFER_SZ to the CFLAGS, and
this will allow the application to log messages that are shorter than
the above size, including the timestamp, level and backtrace if any.
- Optional module level logging. This allows more fine-grained
debugging, where the application can control the log levels of the
individual modules. By default, when modules are configured, they
default to the global log level, but this can be overridden by the
application.
nirenjan