~kennylevinsen/seatd-devel

10 2

Test of port of seatd to GNU/Hurd?

Details
Message ID
<e4bb63cda150a07e00fc4ee727e65a336b7ac351.camel@gmail.com>
Sender timestamp
1736866331
DKIM signature
pass
Download raw message
Hello,

I've recently subscribed to the development of seatd and try to port it to
GNU/Hurd. The only backend available would be the native one.

From the build log:

seatd 0.9.1

    libseat-seatd     : YES
    libseat-builtin   : YES
    libseat-systemd   : NO
    libseat-elogind   : NO
    server            : YES
    man-pages         : YES

I've built packages from patched Debian sources:
seatd_0.9.1-1.1_hurd-i386.deb seatd-dbgsym_0.9.1-1.1_hurd-i386.deb
libseat1_0.9.1-1.1_hurd-i386.deb libseat1-dbgsym_0.9.1-1.1_hurd-i386.deb 
libseat-dev_0.9.1-1.1_hurd-i386.deb

However, I don't yet know how to properly test seatd. Using xorg for testing is
not possible without recompiling the whole xorg suite. This is due to the
existence of the package xserver-xorg-legacy, see:

Description: setuid root Xorg server wrapper
 This package provides a wrapper for the Xorg X server, which is
 necessary for legacy drivers and non-Linux kernels.

And the only way to start X on GNU/Hurd is to allow "anybody" to use the suid
root wrapper: /usr/lib/xorg/Xorg.wrap which is not a test of seatd.

Do you have any ideas on how to properly test seatd in some other way?

Thanks!
Details
Message ID
<04a9eeea-d166-4811-9aff-b0c804a3ad71@kl.wtf>
In-Reply-To
<e4bb63cda150a07e00fc4ee727e65a336b7ac351.camel@gmail.com> (view parent)
Sender timestamp
1736869846
DKIM signature
pass
Download raw message
On 14/01/2025 14.52, Svante Signell wrote:
> However, I don't yet know how to properly test seatd. Using xorg for testing is
> not possible without recompiling the whole xorg suite. This is due to the
> existence of the package xserver-xorg-legacy, see:

There's small included test client (simple_test), but that just tries to 
open a device without doing anything with it so it's not super exciting.

Devuan has a patched Xorg with libseat support, so maybe that is of 
interest. I have poked them about upstreaming before, but I don't think 
they have tried yet. There's pretty good built-in support for libseat 
across Wayland servers (e.g., weston and sway), but not sure if those 
run on Hurd.
Details
Message ID
<c8965baa93b74bdefcf718b60a962943170aaa82.camel@gmail.com>
In-Reply-To
<04a9eeea-d166-4811-9aff-b0c804a3ad71@kl.wtf> (view parent)
Sender timestamp
1736944702
DKIM signature
pass
Download raw message
Thank you for your reply.

On Tue, 2025-01-14 at 15:50 +0100, Kenny Levinsen wrote:
> On 14/01/2025 14.52, Svante Signell wrote:
> > However, I don't yet know how to properly test seatd. Using xorg for testing
> > is not possible without recompiling the whole xorg suite. This is due to the
> > existence of the package xserver-xorg-legacy, see:
> 
> There's small included test client (simple_test), but that just tries to 
> open a device without doing anything with it so it's not super exciting.

Running simpletest it asks for a "file". What file is expected here as input?

> Devuan has a patched Xorg with libseat support, so maybe that is of 
> interest. I have poked them about upstreaming before, but I don't think 
> they have tried yet. There's pretty good built-in support for libseat 
> across Wayland servers (e.g., weston and sway), but not sure if those 
> run on Hurd.

I will try to install Devuan's Xorg in GNU/Hurd. However, some things are still
unclear for me.

- What triggers seatd when running in background?
- seatd-launch expects a "command". Which is the command excpected here?
- The man-pages are very brief, maybe some examples could be added here.
- Unfortunately Wayland packages are not available on GNU/Hurd.

Thanks!
Details
Message ID
<3ea217170471c69721ee70e7d5293eb25fdbe5e3.camel@gmail.com>
In-Reply-To
<c8965baa93b74bdefcf718b60a962943170aaa82.camel@gmail.com> (view parent)
Sender timestamp
1736982531
DKIM signature
pass
Download raw message
On Wed, 2025-01-15 at 12:38 +0100, Svante Signell wrote:
> Thank you for your reply.
> 
> On Tue, 2025-01-14 at 15:50 +0100, Kenny Levinsen wrote:
> > On 14/01/2025 14.52, Svante Signell wrote:
> > > However, I don't yet know how to properly test seatd. Using xorg for
> > > testing
> > > is not possible without recompiling the whole xorg suite. This is due to
> > > the
> > > existence of the package xserver-xorg-legacy, see:
> > 
> > There's small included test client (simple_test), but that just tries to 
> > open a device without doing anything with it so it's not super exciting.
> 
> Running simpletest it asks for a "file". What file is expected here as input?
> 
> > Devuan has a patched Xorg with libseat support, so maybe that is of 
> > interest. I have poked them about upstreaming before, but I don't think 
> > they have tried yet. There's pretty good built-in support for libseat 
> > across Wayland servers (e.g., weston and sway), but not sure if those 
> > run on Hurd.
> 
> I will try to install Devuan's Xorg in GNU/Hurd. However, some things are
> still
> unclear for me.
> 
> - What triggers seatd when running in background?
> - seatd-launch expects a "command". Which is the command excpected here?
> - The man-pages are very brief, maybe some examples could be added here.
> - Unfortunately Wayland packages are not available on GNU/Hurd.
> 
> Thanks!

Thanks, another stupid question:
/simpletest -l debug /usr/lib/xorg/Xorg.wrap
00:00:00.000  [libseat/libseat.c:73] Seat opened with backend 'seatd'
libseat_open_seat(listener: 0x1039d58, userdata: 0x1039d50) = 0x200009c0
/simpletest -l debug /usr/lib/xorg/Xorg.wrap
00:00:00.000  [libseat/libseat.c:73] Seat opened with backend 'seatd'
libseat_open_seat(listener: 0x1039d58, userdata: 0x1039d50) = 0x200009c0
waiting for activation...waiting for activation...

??
Details
Message ID
<fbaaa978-1726-470e-8cbf-17a6ccfe2aa9@kl.wtf>
In-Reply-To
<3ea217170471c69721ee70e7d5293eb25fdbe5e3.camel@gmail.com> (view parent)
Sender timestamp
1736984132
DKIM signature
pass
Download raw message
On 15/01/2025 23.08, Svante Signell wrote:
> Thanks, another stupid question:
> /simpletest -l debug /usr/lib/xorg/Xorg.wrap
> 00:00:00.000  [libseat/libseat.c:73] Seat opened with backend 'seatd'
> libseat_open_seat(listener: 0x1039d58, userdata: 0x1039d50) = 0x200009c0
> /simpletest -l debug /usr/lib/xorg/Xorg.wrap
> 00:00:00.000  [libseat/libseat.c:73] Seat opened with backend 'seatd'
> libseat_open_seat(listener: 0x1039d58, userdata: 0x1039d50) = 0x200009c0
> waiting for activation...waiting for activation...
>
> ??


That's not really a question, but simpletest is a test client that only 
takes 1 argument, which is the path to a supported device file (upstream 
that would be evdev, kms, hidraw and wscons) you'd like it to ask seatd 
to open for you. You're passing 3 arguments to it, so if it hadn't 
gotten stuck it would have tried to open a device file named '-l'. Also 
not sure what's up with the duplicated output - seems like you're 
running it twice in a row?

Once the client has an open seat session, seatd should eventually send 
"enable_seat" to activate the session (which gives it exclusive control 
of input/output devices for display server use). That it is still 
waiting seems to suggest that seatd has not sent enable, or maybe 
something is wrong in your port so the client doesn't receive the 
message. If you run *seatd* with `-l debug` before running your test, 
you'd get some more info about what seatd is doing. The expected output 
is something like:

     seatd[9862]: 00:00:00.000 [INFO] [seatd/seat.c:39] Created VT-bound 
seat seat0
     seatd[9862]: 00:00:00.000 [INFO] [seatd/seatd.c:194] seatd started
     seatd[9862]: 00:00:02.254 [INFO] [seatd/server.c:145] New client 
connected (pid: 9898, uid: 1000, gid: 1000)
     seatd[9862]: 00:00:02.255 [INFO] [seatd/seat.c:170] Added client 1 
to seat0
     seatd[9862]: 00:00:02.255 [DEBUG] [common/terminal.c:198] Setting 
process switching to 1
     seatd[9862]: 00:00:02.255 [DEBUG] [common/terminal.c:246] Setting 
KD keyboard state to 0
     seatd[9862]: 00:00:02.255 [DEBUG] [common/terminal.c:273] Setting 
KD graphics state to 1
     seatd[9862]: 00:00:02.255 [INFO] [seatd/seat.c:480] Opened client 1 
on seat0
     seatd[9862]: 00:00:02.257 [DEBUG] [seatd/seat.c:219] Opening device 
/dev/dri/card0 for client 1 on seat0

"Added client" is printed as the libseat client is registered, while 
"Opened client 1 on seat0" is printed right after the enable message is 
sent to the client. Should help you figure out where things are getting 
stuck.

Maybe try it on a Linux box to have a point of comparison.
Details
Message ID
<c6f5c2dfd90c6d5460e9b03e9015e8cb3c4e1575.camel@gmail.com>
In-Reply-To
<c8965baa93b74bdefcf718b60a962943170aaa82.camel@gmail.com> (view parent)
Sender timestamp
1737024228
DKIM signature
pass
Download raw message
Hello,

did you se this email? Especially the last part. To clarify more VT switching is
not supported on Hurd, so SEATD_VTBOUND is set to zero.

I'll reply to your latest mail separately.

Thanks!

On Wed, 2025-01-15 at 12:38 +0100, Svante Signell wrote:
> Thank you for your reply.
> 
> On Tue, 2025-01-14 at 15:50 +0100, Kenny Levinsen wrote:
> > On 14/01/2025 14.52, Svante Signell wrote:
> > > However, I don't yet know how to properly test seatd. Using xorg for
> > > testing is not possible without recompiling the whole xorg suite. This is
> > > due to the existence of the package xserver-xorg-legacy, see:
> > 
> > There's small included test client (simple_test), but that just tries to 
> > open a device without doing anything with it so it's not super exciting.
> 
> Running simpletest it asks for a "file". What file is expected here as input?
> 
> > Devuan has a patched Xorg with libseat support, so maybe that is of 
> > interest. I have poked them about upstreaming before, but I don't think 
> > they have tried yet. There's pretty good built-in support for libseat 
> > across Wayland servers (e.g., weston and sway), but not sure if those 
> > run on Hurd.
> 
> I will try to install Devuan's Xorg in GNU/Hurd. However, some things are
> still unclear for me.
> 
> - What triggers seatd when running in background?
> - seatd-launch expects a "command". Which is the command excpected here?
> - The man-pages are very brief, maybe some examples could be added here.
> - Unfortunately Wayland packages are not available on GNU/Hurd.
> 
> Thanks!
Details
Message ID
<86dd8424-3e72-41b0-81b2-55379dd2f8f3@kl.wtf>
In-Reply-To
<c6f5c2dfd90c6d5460e9b03e9015e8cb3c4e1575.camel@gmail.com> (view parent)
Sender timestamp
1737028565
DKIM signature
pass
Download raw message
> Running simpletest it asks for a "file". What file is expected here as input?

In .builds/archlinux.yml you can see it called as part of the smoketest. 
It should be a file path to a privileged file that seatd is to open for 
you, e.g. /dev/input/event0.

> I will try to install Devuan's Xorg in GNU/Hurd. However, some things are still
> unclear for me.
>
> - What triggers seatd when running in background?

seatd is a server that opens privileged devices (evdev, drm/kms, hidraw, 
wscons) on behalf of libseat clients (i.e., display servers) that 
themselves do not (and should not) have direct file access. It also 
enables or disables session as appropriate for session switching (VT 
bound or not), switching drm master status around and revoking 
evdev/hidraw as appropriate.

It does not do anything on its own - your display server must have 
libseat support to use it.

> - seatd-launch expects a "command". Which is the command excpected here?
seatd-launch is not meant for general use. seatd-launch is a SUID binary 
that starts seatd, and when ready, runs your command (generally a 
display server) that depends on seatd, intended for e.g. embedded 
environments where no service manager is present and no multi-session 
support is required.

Normal setups should just run seatd as a root service on startup through 
their service manager of choice. The flags let you set which user groups 
are allowed to use seatd, and by extension, run graphical sessions with 
seatd as device access mediator. There isn't any other configuration at 
the current time.
Details
Message ID
<8b24840b75a1ae64b7ccb37d37a61c69b5993f3f.camel@gmail.com>
In-Reply-To
<86dd8424-3e72-41b0-81b2-55379dd2f8f3@kl.wtf> (view parent)
Sender timestamp
1737033341
DKIM signature
pass
Download raw message
On Thu, 2025-01-16 at 11:56 +0100, Kenny Levinsen wrote:
> > Running simpletest it asks for a "file". What file is expected here as
> > input?
> 
> In .builds/archlinux.yml you can see it called as part of the smoketest. 
> It should be a file path to a privileged file that seatd is to open for 
> you, e.g. /dev/input/event0.

Sorry no /dev/input for Hurd.

> > I will try to install Devuan's Xorg in GNU/Hurd. However, some things are
> > still unclear for me.
> > 
> > - What triggers seatd when running in background?
> 
> seatd is a server that opens privileged devices (evdev, drm/kms, hidraw, 
> wscons) on behalf of libseat clients (i.e., display servers) that 
> themselves do not (and should not) have direct file access. It also 
> enables or disables session as appropriate for session switching (VT 
> bound or not), switching drm master status around and revoking 
> evdev/hidraw as appropriate.

On a Devuan/Linux box I find under /dev/: input/*, hidraw{0,1,2,3}, kmsg, dri/*,
drm_dp_aux0 nothing else.

On Hurd none of these above are present and neither of evdev, wscons!

However, on both I find /dev/xconsole. Usable for testing?

> It does not do anything on its own - your display server must have 
> libseat support to use it.
> 
> > - seatd-launch expects a "command". Which is the command excpected here?
> seatd-launch is not meant for general use. seatd-launch is a SUID binary 
> that starts seatd, and when ready, runs your command (generally a 
> display server) that depends on seatd, intended for e.g. embedded 
> environments where no service manager is present and no multi-session 
> support is required.
> 
> Normal setups should just run seatd as a root service on startup through 
> their service manager of choice. 

What is a service manager?

> The flags let you set which user groups are allowed to use seatd, and by
> extension, run graphical sessions with seatd as device access mediator.

Is that the -g option for seatd?

> There isn't any other configuration at the current time.
Details
Message ID
<28fe9cc6-58ac-4bad-b608-48fb54f32f6a@kl.wtf>
In-Reply-To
<8b24840b75a1ae64b7ccb37d37a61c69b5993f3f.camel@gmail.com> (view parent)
Sender timestamp
1737037252
DKIM signature
pass
Download raw message
On 16/01/2025 13.15, Svante Signell wrote:
> Sorry no /dev/input for Hurd.
>
> ...
>
> On Hurd none of these above are present and neither of evdev, wscons!

The purpose of seatd is to give access to such privileged devices. You 
will need to implement support in seatd for the input and output device 
types that Hurd uses, similar to how wscons support was added for NetBSD 
and OpenBSD. This would be the device types that Xorg needs to open for 
input and output.

I am not familiar with Hurd, so I cannot tell you what device types this 
would be. seatd cannot do anything useful before you implement this 
support. Alternatively, take the FreeBSD approach of adding evdev and 
possibly drm support to Hurd to improve compatibility and minimize 
porting work.

> What is a service manager?


The thing you use to run system and user daemons, e.g. openrc, s6, 
systemd, ...
Details
Message ID
<0f8f9cf6b8df4e03e18d61a295143031ac82cd5c.camel@gmail.com>
In-Reply-To
<fbaaa978-1726-470e-8cbf-17a6ccfe2aa9@kl.wtf> (view parent)
Sender timestamp
1738436461
DKIM signature
pass
Download raw message
Hi again,

I'm now trying to start X without xorg-xserver-legacy installed. 
Ans running seatd daemon: /usr/sbin/seatd -g video -l debug
(I'm a member of the video group)

Now starting X fails with
(EE) Server terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

Checking the failing Xorg.0.log shows:
[3265601.077] (EE) 
Fatal server error:
[3265601.087] (EE) xf86KbdInit can't get_privileged_ports. (Operation not
permitted)

Is this something seatd can help with? 
I don't see any output from seatd at all!

On Wed, 2025-01-15 at 23:35 +0100, Kenny Levinsen wrote:
> 
> 
> Once the client has an open seat session, seatd should eventually send 
> "enable_seat" to activate the session (which gives it exclusive control 
> of input/output devices for display server use). That it is still 
> waiting seems to suggest that seatd has not sent enable, or maybe 
> something is wrong in your port so the client doesn't receive the 
> message. If you run *seatd* with `-l debug` before running your test, 
> you'd get some more info about what seatd is doing. The expected output 
> is something like:
> 
>      seatd[9862]: 00:00:00.000 [INFO] [seatd/seat.c:39] Created VT-bound 
> seat seat0
>      seatd[9862]: 00:00:00.000 [INFO] [seatd/seatd.c:194] seatd started
>      seatd[9862]: 00:00:02.254 [INFO] [seatd/server.c:145] New client 
> connected (pid: 9898, uid: 1000, gid: 1000)
>      seatd[9862]: 00:00:02.255 [INFO] [seatd/seat.c:170] Added client 1 
> to seat0
>      seatd[9862]: 00:00:02.255 [DEBUG] [common/terminal.c:198] Setting 
> process switching to 1
>      seatd[9862]: 00:00:02.255 [DEBUG] [common/terminal.c:246] Setting 
> KD keyboard state to 0
>      seatd[9862]: 00:00:02.255 [DEBUG] [common/terminal.c:273] Setting 
> KD graphics state to 1
>      seatd[9862]: 00:00:02.255 [INFO] [seatd/seat.c:480] Opened client 1 
> on seat0
>      seatd[9862]: 00:00:02.257 [DEBUG] [seatd/seat.c:219] Opening device 
> /dev/dri/card0 for client 1 on seat0
> 
> "Added client" is printed as the libseat client is registered, while 
> "Opened client 1 on seat0" is printed right after the enable message is 
> sent to the client. Should help you figure out where things are getting 
> stuck.
> 
> Maybe try it on a Linux box to have a point of comparison.
> 
Details
Message ID
<656685cf-e06d-4b62-9ea9-d2e3d09a265f@kl.wtf>
In-Reply-To
<0f8f9cf6b8df4e03e18d61a295143031ac82cd5c.camel@gmail.com> (view parent)
Sender timestamp
1738499930
DKIM signature
pass
Download raw message
On 01/02/2025 19.01, Svante Signell wrote:
> Hi again,
>
> I'm now trying to start X without xorg-xserver-legacy installed.
> Ans running seatd daemon: /usr/sbin/seatd -g video -l debug
> (I'm a member of the video group)
>
> Now starting X fails with
> (EE) Server terminated with error (1). Closing log file.
> xinit: giving up
> xinit: unable to connect to X server: Connection refused
> xinit: server error
>
> Checking the failing Xorg.0.log shows:
> [3265601.077] (EE)
> Fatal server error:
> [3265601.087] (EE) xf86KbdInit can't get_privileged_ports. (Operation not
> permitted)
>
> Is this something seatd can help with?
> I don't see any output from seatd at all!

This is part of the Hurd specific Xorg integration. I don't know what 
get_privileged_ports does, presumably something with Mach ports, 
although it seems that Xorg implementation just deallocates the port 
immediately afterwards, so not sure what that is good for.

What is ultimately needed to have seatd working:

1. Wire up libseat so that it is used to open the keyboard and video 
devices used by Hurd. You can use the devuan patches as inspiration - I 
suppose they're only applied to the Linux or BSD-specific bits, hence 
why you see nothing trigger.

2. Extend seatd to be able to handle the necessary device types (see: 
https://git.sr.ht/~kennylevinsen/seatd/tree/master/item/seatd/seat.c#L322), 
the same way that e.g. wscons support was added.

3. Figure out if there's anything else Hurd-specific needed that would 
need to be adapted, e..g. is it seatd that needs to get a privileged 
port, if seatd needs to send it to the client, if it can be revoked when 
needed, etc.

Note that display servers using seatd through libseat will still need to 
know how to use Hurd-specific device types - what libseat/seatd provides 
is device access management without root or compromising groups and 
support for multiple sessions.

I'll happily review patches, but I am unfamiliar with the details of 
Hurd and have too limited time to start digging into it myself.
Reply to thread Export thread (mbox)