libinput/doc/api/mainpage.dox
Peter Hutterer cbd4f35442 dox: switch to sphinx for the user-visible documentation
This is a large commit because it's difficult to split this up and we don't
care about bisecting here anyway.

doxygen is going to produce the API documentation only
sphinx is going to produce the prose user (and a bit of developer) documentation.

The source split is doc/api and doc/user.

Steps performed:
- run the doxygen-to-sphinx.sh script to convert all .dox sources to .rst
- manually fixed the .rst to render correctly
- add a few extra .rst documents to generate the right hierarchy
- hook up sphinx-build in meson
- add a new @mainpage for doxygen more aimed at developers

For the build directory:
- sphinx produces /Documentation
- doxygen now produces /api/

These need to be manually combined in the wayland-web repo, meson doesn't
support subdirectories as output paths within the build dir and the
documentation doesn't need to be installed anywhere.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2018-07-30 12:24:04 +10:00

135 lines
3.8 KiB
Text

/**
@mainpage
This is the libinput API reference.
This documentation is aimed at developers of Wayland compositors. User
documentation is available
[here](https://wayland.freedesktop.org/libinput/doc/latest).
@section concepts Concepts
@subsection concepts_initialization Initialization of a libinput context
libinput provides two different backends:
- a @ref libinput_udev_create_context "udev backend" where notifications
about new and removed devices are provided by udev, and
- a @ref libinput_path_create_context "path backend" where
@ref libinput_path_add_device "device addition" and
@ref libinput_path_remove_device "device removal" need to be handled by
the caller.
See section @ref base for information about initializing a libinput context.
@subsection concepts_events Monitoring for events
libinput exposes a single @ref libinput_get_fd "file descriptor" to the
caller. This file descriptor should be monitored by the caller, whenever
data is available the caller **must** immediately call libinput_dispatch().
Failure to do so will result in erroneous behavior.
libinput_dispatch() may result in one or more events being available to the
caller. After libinput_dispatch() a caller **should** call
libinput_get_event() to retrieve and process this event. Whenever
libinput_get_event() returns `NULL`, no further events are available.
See section @ref event for more information about events.
@subsection concepts_seats Device grouping into seats
All devices are grouped into physical and logical seats. Button and key
states are available per-device and per-seat. See @ref seat for more
information.
@subsection concepts_devices Device capabilities
libinput does not use device types. All devices have @ref
libinput_device_has_capability "capabilities" that define which events may
be generated. See @ref device for more information about devices.
Specific event types include:
- @ref event_keyboard
- @ref event_pointer
- @ref event_touch
- @ref event_gesture
- @ref event_tablet
- @ref event_tablet_pad
- @ref event_switch
@subsection concepts_configuration Device configuration
libinput relies on the caller for device configuration. See
@ref config for more information.
@subsection example An example libinput program
The simplest libinput program looks like this:
@code
static int open_restricted(const char *path, int flags, void *user_data)
{
int fd = open(path, flags);
return fd < 0 ? -errno : fd;
}
static void close_restricted(int fd, void *user_data)
{
close(fd);
}
const static struct libinput_interface interface = {
.open_restricted = open_restricted,
.close_restricted = close_restricted,
};
int main(void) {
struct libinput *li;
struct libinput_event *event;
li = libinput_udev_create_context(&interface, NULL, udev);
libinput_udev_assign_seat(li, "seat0");
libinput_dispatch(li);
while ((event = libinput_get_event(li)) != NULL) {
// handle the event here
libinput_event_destroy(li);
libinput_dispatch(li);
}
libinput_unref(li);
return 0;
}
@endcode
@section building_against Building against libinput
libinput provides a
[pkg-config](https://www.freedesktop.org/wiki/Software/pkg-config/) file.
Software that uses libinput should use pkg-config and the
`PKG_CHECK_MODULES` autoconf macro.
Otherwise, the most rudimentary way to compile and link a program against
libinput is:
@verbatim
gcc -o myprogram myprogram.c `pkg-config --cflags --libs libinput`
@endverbatim
For further information on using pkgconfig see the pkg-config documentation.
@section stability Backwards-compatibility
libinput promises backwards-compatibility across all the 1.x.y version. An
application built against libinput 1.x.y will work with any future 1.*.*
release.
@section About
Documentation generated by from git commit [__GIT_VERSION__](https://gitlab.freedesktop.org/libinput/libinput/commit/__GIT_VERSION__)
*/