On 8/23/23 13:34, Sebastian Sellmeier wrote:
> First proposal of a feature-request discuessed some time ago in irc as my devices flipps state at around 98/99%.
> It does not fix the issue fully as I also would like to supress online/offline notifications of the charger when over certain battery-level,
> but at the time I don't have access to the current battery-level as there could be mutliple. For device notifications it only supresses the one
> for devices with state over -o value.

We could do one of two things:

1. Something a bit more elaborate in send_state_update, where we like 
here ignore "safe" transitions. This might be similar to the proposed 
threshold, but let's see what's possible.

Having `upower --monitor-detail` output during the charge/discharge

On 8/27/23 23:48, Андрей Сорокин wrote:
> I have set loglevel to debug. The log of the second attempted to run 
> x-session user (when already running x-session by the first user) contains:

The loglevel changes the log output of the seatd service itself, which 
is what might help here. The log output of libseat/X is unchanged.

> If to edit /etc/init.d/seatd with START_ARGS="-l debug" -- that gives
> error on service restart. :^(
I cannot guess what errors you see. If you need help with your init 
scripts, ask in an appropriate community forum for your distribution.

> What do you mean under "first issue"?

Your libseat log contains:

1. A failed connection to the running seatd instance ("Could not poll 
connection: Broken pipe")
2. A failed attempt to use elogind as fallback ("Could not get primary 
session for user")
3. A final failed attempt to use a built-in seatd instance as fallback

Note: Remember to reply to all/reply to list

> Wow! Thank you for correcting me! Then, assuredly, i'm talking on
> multi-session. But why i, then, can not have multi-session with
> "SeatD"? -- For when second user tries to run x-session, it gets
> following errors:
> 
> [  1267.570] (II) seatd_libseat init
> [  1267.570] (EE) [libseat/backend/seatd.c:308] Could not poll
> connection: Broken pipe [  1267.570] (II) [libseat/libseat.c:76]
> Backend 'seatd' failed to open seat, skipping [  1267.570] (EE)

Your connection to seatd failed. You should debug the seatd daemon, 
which should print some information to stderr. Also consider changing

On 8/21/23 09:13, Андрей Сорокин wrote:
> For me it is: several users may have long running x-applications at the 
> same time, simply, locking their sessions, using expensive hardware.

Just to clarify, multi-seat would basically be several office desks 
(screens, keyboards, mice) powered by a single machine, each user having 
their own display, gpu(!), keyboard and mouse used to run their own X or 
Wayland session in parallel with and entirely separate from everyone else.

Multi-session would be 1 office desk with multiple users, where all 
users can be logged in simultaneously but only one session is active and 
shown (the user who is currently at the desk) with the rest being in the

Two updates: First, I have made this "proper" sd_notify adapter: 
https://git.sr.ht/~kennylevinsen/readyfd2sd

It uses libsystemd for notification and maintains that the direct child 
of systemd is the started service with the monitoring process being 
forked off before exec. As such it has the right systemd main pid 
without giving off a systemd alien child warnings, looks clean in the 
process tree, and supports all the sd_notify socket types.

Second, I am reconsidering whether we should allow this in a minimal 
(only readiness), and strictly optional form. While systemd will not be 
seen in a positive light around here - projects like seatd and elogind 
would not really need to exist if systemd accepted cooperation with 
other communities - I do not want our policy to be hostility to systemd

That was an excessive number of quotation marks. :)

> So, question is on your plans with "MultiSeat": do you plan to accomplish "MultiSeat"

What is your multi-seat use-case? The plan is to support multi-seat in 
seatd, but due to how rare multi-seat uses are it has not had the 
highest priority. Knowing about needs in the area would be useful though.

> if "yes" then when do you plan to accomplish "MultiSeat"?
As a general rule of thumb, unpaid work has no estimates and no 
committed schedules/plans. It happens when it happens.

> do not know why developers made such a decision, probably because with "ELoginD" it is absolutely became impossible OR wanted also to get rid if it

On 8/18/23 15:00, James Hilliard wrote:
> Well that's systemd socket activation while this is systemd notify support.

Socket activation indirectly solves readiness by removing the need for 
waiting on seatd altogether. It has been requested before, and as it 
might both bring more functionality and require less non-portable code 
to implement, it could be worth considering.

> It appears that there's some desire to avoid linking with libsystemd just
> for the sake of not linking with libsystemd, even though doing so would
> result in a much better integration.

How would it result in better integration? The service is either ready 
or it is not.

Announcing the release of seatd 0.8.0.

https://git.sr.ht/~kennylevinsen/seatd/refs/0.8.0

---

seatd 0.8.0

Alyssa Ross (1):
       meson: fix seatdpath with absolute bindir

Anna (navi) Figueiredo Gomes (2):
       noop: Return seat0 as the seat name
       noop: Additional open flags for `open(2)`

Applied, thanks!