Hello,
Sway uses the wayland compositor “wlroots”.
Wlroots wants to store the compiled keymap in a shared memory area.
What interface should i modify, to allow access to “/dev/shm/wlroots-XXXXX” ?
Sway need is the provider and consumer of the shared-memory area.
I don’t know if there are other sway-clients that could need access.
Just for testing i would add it now to the wayland slot.
Looks like cage is the only other user of wlroots I could find. However wlroots is a library to build your wayland window manager with, I would expect the change to end up in the wayland interface.
@mborzecki
Just figured out, that no “shared-memory” (= /dev/shm/ ) is needed.
The wlroots developer just replaced “mkstemp” with “shm_open” because for posix compatibility.
So i will just revert to the old shared tmpfile inside XDG_RUNTIME_DIR, instead of “/dev/shm”
Sounds fishy, IIRC mkstemp is covered by POSIX. Maybe there were some other performance or compatibility related issues. Have you tried asking the upstream developers?
For me, it looks like they want to be compatible to non-linux platforms ?!
Here is the commit, which i partly reverted in my branch: https://github.com/swaywm/wlroots/commit/2d0c5ec78eb975981b1d194fa9d4bc80b894748d
In my branch i define some pre-compiler toggle.
https://github.com/swaywm/wlroots/pull/1958
(I know, the c is a little bit hacky. )
Hey !
the wlroots-developer don’t want to make /dev/shm configurable.
Mounting tmpfs over /dev/shm was not allowed in snapcraft.
Any further ideas ?
Currently i have a patched, working version of sway in my repo…
You could try snapcraft-preload with the env var SNAPCRAFT_PRELOAD_REDIRECT_ONLY_SHM=1 set for your snap app.
