diff --git a/libx52_integration.html b/libx52_integration.html index 6276e72..f66e300 100644 --- a/libx52_integration.html +++ b/libx52_integration.html @@ -104,7 +104,7 @@ $(function() {
LIBX52_SUCCESS
@ LIBX52_SUCCESS
Definition: libx52.h:165
libx52_strerror
const char * libx52_strerror(libx52_error_code error)
Return a string representation of the error code.
libx52.h
Functions, structures and enumerations for the Saitek X52 MFD & LED driver library.
-

+

Joystick Updates

Most libx52 functions to update the joystick state do not directly write to the connected joystick, but only update internal data structures within the device context. In order to actually update the joystick, the application must call libx52_update. This function writes the updates to the joystick and resets any internal state.

Example

@@ -114,11 +114,11 @@ Joystick Updates
libx52_update(dev);
libx52_set_text
int libx52_set_text(libx52_device *x52, uint8_t line, const char *text, uint8_t length)
Set the text on an MFD line.
libx52_update
int libx52_update(libx52_device *x52)
Update the X52.
-

+

Error handling

Most libx52 functions return a standard libx52_error_code integer value that indicates the status of the operation. As long as the operation succeeded, the function will return LIBX52_SUCCESS. Other values returned indicate a failure of some sort.

libx52_strerror can convert the return code into a descriptive string that may be displayed to users.

-

+

Internationalization of error strings

libx52_strerror automatically handles internationalization. As long as your application sets up the locale correctly, and the error strings have been translated to that locale, the returned strings will correspond to the translated values for your locale.

diff --git a/proto_config.html b/proto_config.html index 145f19d..6b8cc84 100644 --- a/proto_config.html +++ b/proto_config.html @@ -82,7 +82,6 @@ $(function() {
  • Retrieve configuration parameter
  • Set configuration parameter
    • -
  • Apply configuration

    • The config commands deal with x52d configuration subsystem, and have the following subcommands.

    @@ -183,7 +182,7 @@ Retrieve configuration parameter Set configuration parameter

    The config set command requests the x52d daemon to set the given (section, key) parameter to the given value. The daemon will treat it the same way as if it was being read from the configuration file, i.e., it will follow identical parsing logic, including ignoring unknown keys and not reporting errors for them.

    A side effect of this is that the client could request a set for any arbitrary section and key pair, and if that pair was not recognized, it would be ignored, but the daemon would still send an OK response.

    -

    Finally, this will only set the value within the configuration memory structures, and will not invoke any callback to update the rest of the threads or device state. The client will need to call the apply subcommand to actually invoke the necessary callbacks.

    +

    This will set the value within the configuration memory structures, and will immediately invoke the relevant callback to update the rest of the threads or device state.

    Arguments

    Error example

    ERR\0Error 22 setting 'led.fire'='none': Invalid argument\0
    -

    -Apply configuration

    -

    The config apply command will invoke all the callbacks and ensure that the configuration is applied to the running state.

    -

    Arguments

    - -

    Returns

    - -
    +
    diff --git a/proto_logging.html b/proto_logging.html index 1193a02..785adff 100644 --- a/proto_logging.html +++ b/proto_logging.html @@ -72,27 +72,29 @@ $(function() {

    Table of Contents

    -

    The logging commands allow the user to fine tune the logging configuration of x52d as well as adjust the log levels for either all the modules, or for each of the modules individually.

    While the -v and -q command line options allow you to either increase the logging verbosity or suppress it entirely, they are required to be specified at program startup. On the other hand, having the logging commands allows the user to fine tune the logging while the daemon is running.

    -

    +

    Modules

    x52d is split into several modules as far as logging is concerned. The list of modules is below:

    • Config
      • +
    • Cllient
    • Clock
    • Command
    • Device
    • IO
    • LED
    • Mouse
      • +
    • Notify
    -

    +

    Logging levels

    The following is a list of supported logging levels. Each level logs the ones above it as well as the current level

      @@ -105,7 +107,7 @@ Logging levels
    • trace - Log trace messages - useful for tracing program flow.
    • default - Not a level, but used when configuring module log levels, makes the module log level fallback to the global log level.
    -

    +

    Show logging configuration

    The logging show command takes in an optional module name, as listed in the Modules section above. It returns the module name, if specified, and the log level for that module. If the module is configured to fallback to the global level, then it will return the global level.

    Arguments

    @@ -120,7 +122,7 @@ Show logging configuration
  • module-name (if specified)
  • log-level
    • -

    +

    Set logging configuration

    The logging set command takes in the optional module name and the log level and sets the log level for that module, if specified, or the global level otherwise.

    Arguments

    diff --git a/x52ctl.html b/x52ctl.html index 3e5f9b2..30eb5dd 100644 --- a/x52ctl.html +++ b/x52ctl.html @@ -70,15 +70,15 @@ $(function() {

    x52ctl - Command line controller to X52 daemon

    -

    +

    SYNOPSIS

    x52ctl [-i] [-s socket-path] [command]

    -

    +

    DESCRIPTION

    x52ctl is a program that can be used to communicate with the X52 daemon. It can be used either as a one-shot program that can be run from another program or script, or it can be run interactively.

    Commands are sent to the running daemon, and responses are written to standard output.

    If not running interactively, then you must specify a command, or the program will exit with a failure exit code. If running interactively, the program will request input and send that to the daemon, until the user either enters the string "quit", or terminates input by using Ctrl+D.

    -

    +

    OPTIONS

    • -i Run in interactive mode. Any additional non-option arguments are ignored.