Le Mon, Sep 15, 2025 at 05:06:55PM +0200, Matthieu Herrb a écrit :
> Hi,
> 
> cage is a kiosk compositor for Wayland: it will only run one
> full-screen application.
> 
> I picked up the HEAD version in git to have support for wlroots 0.19
> 
> comments ? ok ?

thanks for the port, that was one of the runtime requirements for the
wip greetd login manager i had around.

i've been able to successfully test it w/ 'LIBSEAT_BACKEND=noop
XDG_RUNTIME_DIR=~/.local/run cage -d sakura', and when i exit sakura i'm
back to a VT.

even if i have ownership of wsmouse1 & wsmouse0, it warns about not
being able to map them to 'an output device':
00:00:00.448 [../cage-2e593fe5a8a2186a558ceb414674775e4ba5d2b1/seat.c:141] Input device wsmouse1 cannot be mapped to an output device
00:00:00.451 [../cage-2e593fe5a8a2186a558ceb414674775e4ba5d2b1/seat.c:141] Input device wsmouse0 cannot be mapped to an output device

because apparently the wlr_pointer->output_name string isnt defined.

it automatically starts an xwayland server, i guess on purpose..

and when exiting, cage aborts on an assertion:
00:00:04.234 [wayland] failed to read client connection (pid 26597)
(EE) failed to read Wayland events: Broken pipe
assertion "wl_list_empty(&xsurface->events.associate.listener_list)" failed: file "xwayland/xwm.c", line 592, function "xwayland_surface_destroy"
Abort trap (core dumped)

the trace from cage.core is in wlroots:

#0  thrkill () at /tmp/-:2
#1  0xc4decc9d46285940 in ?? ()
#2  0x0000004b9f63e61b in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#3  0x0000004b9f6c160a in _libc___assert2 (file=<optimized out>, line=<optimized out>, func=<optimized out>, failedexpr=<optimized out>) at /usr/src/lib/libc/gen/assert.c:52
#4  0x0000004bcb931d87 in xwayland_surface_destroy () from /usr/local/lib/libwlroots-0.19.so.0.0
#5  0x0000004bcb9315cd in xwm_destroy () from /usr/local/lib/libwlroots-0.19.so.0.0
#6  0x0000004bcb9305e6 in wlr_xwayland_destroy () from /usr/local/lib/libwlroots-0.19.so.0.0
#7  0x000000491b072342 in ?? ()

other that that, portswise it looks ok, minus one nit, the version spec
is wrong, 0.2.0.2e593fe wont compare to another random git hash, so
maybe use the date of the last commit, eg 0.2.0pl20250702 ? this ways it
only increases, until a newer 0.2.1 or 0.3.0 is released.

with that fixed, ok with me, the other bits can still be looked at/fixed
in-tree.

Landry