hayodea/salmanoff
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

DAPSpec: Add params to quale-iface-api

Browse Source 
We add params to the quale iface (soon to be renamed to cologex-api).
This allows us to eventually set the history length for stimbuffs.
This commit is contained in:
Hayodea Hekol
2025-11-01 00:57:04 -04:00
parent 9cf1398f5c
commit e824685c19
5 changed files with 48 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
devices/avia0.dapss
+1 -1
View File
@@ -1 +1 @@
+edev|avia0|structural-qualeiface|livoxGen1()|livoxProto1()|3JEDK380010Z39
+edev|avia0|structural-qualeiface()|livoxGen1()|livoxProto1()|3JEDK380010Z39
devices/win0.dapss
+1 -1
View File
@@ -1 +1 @@
+edev|win0|visual-qualeiface|xcb(dev-substring)|xorg(display=1|screen=0)|mut
+edev|win0|visual-qualeiface()|xcb(dev-substring)|xorg(display=1|screen=0)|mut
docs/deviceAttachmentPipelineSpec.md
+25 -24
View File
@@ -35,7 +35,7 @@ data and the mind's processing capabilities.
The general format of a DAP specification is:
```
sensor-type|dev-identifier|quale-iface-api|stim-buff-api(api-params)|provider(provider-params)|dev-selector
sensor-type|dev-identifier|quale-iface-api(quale-iface-api-params)|stim-buff-api(api-params)|provider(provider-params)|dev-selector
```
* `sensor-type` is always either '`+idev`' (interoceptor), '`+edev`'
@@ -46,7 +46,8 @@ sensor-type|dev-identifier|quale-iface-api|stim-buff-api(api-params)|provider(pr
sense organ or sense modality.
* `quale-iface-api` is the name of the QualeIface library that should be used to
process the data from the stim buffer. This replaces the previous implexor
concept.
concept. The `quale-iface-api-params` in parentheses may be omitted, in which
case the parentheses will be empty, but the parentheses must always be written out.
* `stim-buff-api` is the interface that provides access to a specific stim
buffer from the device. A single device may have multiple stim buffers
(e.g., audio output, microphone input, different data streams). The
@@ -60,13 +61,13 @@ sensor-type|dev-identifier|quale-iface-api|stim-buff-api(api-params)|provider(pr
* `dev-selector` is the idiosyncratic label/name used by the `provider` to
identify the specific device you want to attach via that `provider`.
## `stim-buff-api-params` and `provider-params`:
## `quale-iface-api-params`, `stim-buff-api-params` and `provider-params`:
If there's more than one parameter item in a list of `stim-buff-api-params` or
`provider-params`, then the individual items in a list of `stim-buff-api-param` or
`provider-params` should be separated by the h-bar character (`|`). E.g:
If there's more than one parameter item in a list of `quale-iface-api-params`,
`stim-buff-api-params`, or `provider-params`, then the individual items in a
list should be separated by the h-bar character (`|`). E.g:
```
+edev|soundcard0|audio-qualeiface|alsa-audio(shmem|param2|param3)|alsa()|cardname
+edev|soundcard0|audio-qualeiface(param1|param2)|alsa-audio(shmem|param2|param3)|alsa()|cardname
```
Each parameter must be in one of these forms:
@@ -148,7 +149,7 @@ required to effectuate the stim-buff controls.
### To attach a particular window from a window manager:
```
+edev|my-window|visual-qualeiface|wayland()|wayland(server-socket)|window0
+edev|my-window|visual-qualeiface()|wayland()|wayland(server-socket)|window0
```
Connect to the Wayland server that's listening on `server-socket`, using the
`wayland` stim-buff-api. Ask that Wayland server to give salmanoff read-access to all of
@@ -157,7 +158,7 @@ the frames composited into the window buffer for `window0`. Use salmanoff's
### To attach a window manager's entire rendered desktop:
```
+edev|my-desktop|visual-qualeiface|wayland()|wayland(listen-socket)|all
+edev|my-desktop|visual-qualeiface()|wayland()|wayland(listen-socket)|all
```
In most cases, this is basically the same as attempting to attach all of the
underlying GFX server's output.
@@ -169,7 +170,7 @@ that Wayland server's compositor buffer.
### To attach all of an Xorg server's gfx output to all screens:
```
+edev|my-xorg-display|visual-qualeiface|x11()|xorg(listen-socket)|all
+edev|my-xorg-display|visual-qualeiface()|x11()|xorg(listen-socket)|all
```
Connect to the Xorg server that's listening on `listen-socket`, using the `x11`
@@ -186,7 +187,7 @@ WM's output.
### To attach all of an Xorg server's gfx output to a particular screen:
```
+edev|my-screen|visual-qualeiface|x11()|xorg(listen-socket)|:0
+edev|my-screen|visual-qualeiface()|x11()|xorg(listen-socket)|:0
```
Connect to the Xorg server that's listening on `listen-socket`, using the `x11`
stim-buff-api. Ask that Xorg server to let Salmanoff read out all of the frames written
@@ -199,7 +200,7 @@ out to display `:0`. Use salmanoff's `visual-qualeiface` to process the visual d
### To attach a camera device by connecting directly to its Linux driver:
```
+edev|my-camera|visual-qualeiface|v4l()|linux()|/dev/video0
+edev|my-camera|visual-qualeiface()|v4l()|linux()|/dev/video0
```
We specify that we want to use the `linux` kernel's loaded driver to connect
to communicate with `/dev/video0`, via the `Video4Linux` stim-buff-api. We want salmanoff
@@ -209,7 +210,7 @@ If `/dev/video0` is already consumed by another process, this may likely fail.
### To attach a microphone that's managed by ALSA server:
```
+edev|my-microphone|audio-qualeiface|alsa-mic(shmem)|alsa()|cardname
+edev|my-microphone|audio-qualeiface()|alsa-mic(shmem)|alsa()|cardname
```
Connect to the ALSA server via `shmem`, using the `alsa-mic` stim-buff-api. Request access to
@@ -218,7 +219,7 @@ the microphone function of the sound card with the name `cardname`. Use the
### To attach a thermal sensor managed by Linux:
```
+idev|my-thermal|thermal-qualeiface|thermal-zone()|linux()|/sys/class/thermal_zone0
+idev|my-thermal|thermal-qualeiface()|thermal-zone()|linux()|/sys/class/thermal_zone0
```
Use the `thermal-zone` SysFS stim-buff-api provided by `linux` to connect to the sensor
@@ -232,9 +233,9 @@ Use the `thermal-zone` SysFS stim-buff-api provided by `linux` to connect to the
The same physical sound card `soundcard0` can be accessed through different providers:
```
+edev|soundcard0|audio-qualeiface|alsa-audio()|alsa()|card0
||| +edev|soundcard0|audio-qualeiface|direct-file-ops()|linux()|/dev/snd/pcmC0D0p
||| +idev|soundcard0|audio-qualeiface|alsa-mic()|alsa()|card0
+edev|soundcard0|audio-qualeiface()|alsa-audio()|alsa()|card0
|| +edev|soundcard0|audio-qualeiface()|direct-file-ops()|linux()|/dev/snd/pcmC0D0p
|| +idev|soundcard0|audio-qualeiface()|alsa-mic()|alsa()|card0
```
This shows:
@@ -247,9 +248,9 @@ This shows:
A camera device `camera0` might expose different data streams:
```
+edev|camera0|visual-qualeiface|v4l-rgb()|linux()|/dev/video0
||| +edev|camera0|visual-qualeiface|v4l-yuv()|linux()|/dev/video0
||| +idev|camera0|thermal-qualeiface|v4l-thermal()|linux()|/dev/video0
+edev|camera0|visual-qualeiface()|v4l-rgb()|linux()|/dev/video0
|| +edev|camera0|visual-qualeiface()|v4l-yuv()|linux()|/dev/video0
|| +idev|camera0|thermal-qualeiface()|v4l-thermal()|linux()|/dev/video0
```
This shows the same camera device providing:
@@ -274,7 +275,7 @@ your actuator device.
The general format for an actuator's device attachment specification follows the same pattern:
```
+adev|dev-identifier|wilzor-algorithm|stim-buff-api(api-params)|provider(provider-params)|dev-selector
+adev|dev-identifier|wilzor-algorithm(quale-iface-api-params)|stim-buff-api(api-params)|provider(provider-params)|dev-selector
```
Where `wilzor-algorithm` is the specific wilzor algorithm needed to control the actuator device.
@@ -287,7 +288,7 @@ Separate individual DAP specifications with two consecutive h-bar
characters (`||`),
like this:
```
+edev|my-window|visual-qualeiface|wayland()|wayland(server-socket)|window0
|| +edev|my-xorg-display|visual-qualeiface|x11()|xorg(listen-socket)|all
|| +idev|my-thermal|thermal-qualeiface|thermal-zone()|linux()|/sys/class/thermal_zone0
+edev|my-window|visual-qualeiface()|wayland()|wayland(server-socket)|window0
|| +edev|my-xorg-display|visual-qualeiface()|x11()|xorg(listen-socket)|all
|| +idev|my-thermal|thermal-qualeiface()|thermal-zone()|linux()|/sys/class/thermal_zone0
```
include/user/deviceAttachmentSpec.h
+11 -1
View File
@@ -35,6 +35,7 @@ public:
std::string deviceIdentifier;
char sensorType;
std::string qualeIfaceApi;
std::vector<std::pair<std::string,std::string>> qualeIfaceApiParams;
std::string stimBuffApi;
std::vector<std::pair<std::string,std::string>> stimBuffApiParams;
std::string provider;
@@ -46,7 +47,16 @@ public:
std::ostringstream os;
os << "Device Identifier: " << deviceIdentifier
<< ", Sensor Type: " << sensorType
<< ", QualeIface API: " << qualeIfaceApi << ", StimBuff API: " << stimBuffApi
<< ", QualeIface API: " << qualeIfaceApi << ", QualeIface API Params: (";
for (const auto& param : qualeIfaceApiParams)
{
os << param.first;
if (!param.second.empty()) {
os << "=" << param.second;
}
os << " ";
}
os << "), StimBuff API: " << stimBuffApi
<< ", StimBuff API Params: (";
for (const auto& param : stimBuffApiParams)
{
smocore/deviceManager/deviceAttachmentPipeSpecp.yy
+10 -8
View File
@@ -106,18 +106,20 @@ extrospector_spec:
;
spec_body:
STRING PIPE STRING PIPE STRING LPAREN opt_params RPAREN PIPE STRING LPAREN opt_params RPAREN PIPE STRING {
STRING PIPE STRING LPAREN opt_params RPAREN PIPE STRING LPAREN opt_params RPAREN PIPE STRING LPAREN opt_params RPAREN PIPE STRING {
$$ = new smo::device::DeviceAttachmentSpec();
$$->deviceIdentifier = std::string($1);
$$->sensorType = '\0'; // This will be set by the parent rule
$$->qualeIfaceApi = std::string($3);
$$->stimBuffApi = std::string($5);
$$->stimBuffApiParams = std::move(*$7);
$$->provider = std::string($10);
$$->providerParams = std::move(*$12);
$$->deviceSelector = std::string($15);
delete $7;
delete $12;
$$->qualeIfaceApiParams = std::move(*$5);
$$->stimBuffApi = std::string($8);
$$->stimBuffApiParams = std::move(*$10);
$$->provider = std::string($13);
$$->providerParams = std::move(*$15);
$$->deviceSelector = std::string($18);
delete $5;
delete $10;
delete $15;
}
;