Docs:devspec: Server renamed to provider
This commit is contained in:
@@ -0,0 +1,12 @@
|
||||
# DeviceSpec: API `drm()` from server `linux()`:
|
||||
|
||||
The API is Linux DRM/KMS. The server is Linux itself. This server provides
|
||||
direct capture of frames at the kernel so it works for both Linux and Wayland.
|
||||
There's a program known as GPU Screen Recorder that is able to use this to
|
||||
capture specific windows on X11, but the window-specific capture doesn't work
|
||||
with Wayland. Irrespective, whole-screen capture works on both GFX servers.
|
||||
|
||||
Notes:
|
||||
* `modetest` utility in ubuntu package `libdrm-tests` is relevant.
|
||||
* `kmscube` is apparently relevant.
|
||||
* `drm_info` from ubuntu pkg `drm-info`is relevant.
|
||||
@@ -0,0 +1,5 @@
|
||||
# DeviceSpec: API `x11`, server `xorg`:
|
||||
|
||||
|
||||
|
||||
* `xwininfo` is relevant.
|
||||
+10
-10
@@ -18,30 +18,30 @@ of input sensor data and detect objects and patterns within it.
|
||||
|
||||
The general format of a device-spec for a sensor is:
|
||||
```
|
||||
sensor-type|implexor|api(api-params)|server(server-params)|deviceselector
|
||||
sensor-type|implexor|api(api-params)|provider(provider-params)|deviceselector
|
||||
```
|
||||
|
||||
* `sensor-type` is always either '`+idev`' (interoceptor), '`+edev`'
|
||||
(extrospector), or '`+adev`' (actuator).
|
||||
* `implexor` is the name of the implexor algorithm that should be used with
|
||||
the data that is provided by the `server` via the `api`.
|
||||
* `api` is the interface that the server uses to export perceptual data for
|
||||
the data that is provided by the `provider` via the `api`.
|
||||
* `api` is the interface that the provider uses to export perceptual data for
|
||||
harikoff to read. Harikoff will run the `implexor` algorithm on the data
|
||||
from this `api`. The `api-param` in parentheses may be omitted, in which
|
||||
case the parentheses will be empty, but the parentheses must always be
|
||||
written out.
|
||||
* `server` may be a userspace daemon or an OS kernel that provides perceptual
|
||||
data via the `api`. The `server-params` in parentheses may be omitted, in
|
||||
* `provider` may be a userspace daemon or an OS kernel that provides perceptual
|
||||
data via the `api`. The `provider-params` in parentheses may be omitted, in
|
||||
which case the parenthesis will be empty, but the parentheses must always be
|
||||
written out.
|
||||
* `device selector` is the idiosyncratic label/name used by the `server` to
|
||||
identify the specific device you want to access via that `server`.
|
||||
* `device selector` is the idiosyncratic label/name used by the `provider` to
|
||||
identify the specific device you want to access via that `provider`.
|
||||
|
||||
## `API-params` and `Server-params` :
|
||||
## `API-params` and `provider-params` :
|
||||
|
||||
If there's more than one parameter item in a list of `api-params` or
|
||||
`server-params`, then the individual items in a list of `api-param` or
|
||||
`server-params` should be separated by the h-bar character (`|`). E.g:
|
||||
`provider-params`, then the individual items in a list of `api-param` or
|
||||
`provider-params` should be separated by the h-bar character (`|`). E.g:
|
||||
```
|
||||
+edev|audio-implexor|alsa(shmem|param2|param3)|alsa()|cardname
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user