Prior to this change, the tests file contained every test that was in
the original script based test suite. However, we don't need to test
every single scenario within libx52, since those are already handled in
the libx52 specific tests. This also causes a slow compilation, since
the tests are written as a series of macros, and the result is a 2000+
line file before preprocessing.
This change removes some of the spurious test cases, and simply checks
that the parameters passed to the corresponding libx52 function are as
expected for a few test cases.
Prior to this change, the update thread was only checking on
device_update_needed. However, this causes an issue when calling any of
the set methods where the update thread fires, fails to find a device,
and signals the acquisition thread every 50 ms, since the update flag
was never cleared.
This change adds a thread enable flag for the update thread. The update
thread will check that both the thread enable flag and the update needed
flag are set before proceeding with the call to libx52_update.
Some libx52 APIs, notably the clock related ones, can return
LIBX52_ERROR_TRY_AGAIN. This is not a real error, but it is useful
information. It indicates to the application that there is no change
applied to the internal state, and that it should wait until trying
again.
Given that the clock thread calls the libx52_set_clock method every
second, treating the TRY_AGAIN state as a failure and logging it causes
a lot of spurious noise in the logs. This change ensures that the API
returns a real error before logging it.
Having the trace log in there adds unnecessary logging for no real
reason. It is better to disable the log here to help trace other
portions of the daemon.
Commit 2ce9ff22 replaced the calls to AX_PKG_CHECK_MODULES with
PKG_CHECK_MODULES, but it was done blindly, since PKG_CHECK_MODULES
takes a different number of arguments. As a result, even if the checks
for cmocka and udev succeed, they are still disabled because the
corresponding have_ variable is not set to 'yes'.