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!
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.
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!
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...
??
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.
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!
> 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.
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.
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, ...
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.>
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.