Denmark
This space intentionally left blank.
From Kenny Levinsen to ~kennylevinsen/poweralertd-devel
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
From Kenny Levinsen to ~kennylevinsen/seatd-devel
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.
From Kenny Levinsen to ~kennylevinsen/seatd-devel
> 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
From Kenny Levinsen to ~kennylevinsen/seatd-devel
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
From Kenny Levinsen to ~kennylevinsen/seatd-devel
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
From Kenny Levinsen to ~kennylevinsen/seatd-devel
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
From Kenny Levinsen to ~kennylevinsen/seatd-devel
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
From Kenny Levinsen to ~kennylevinsen/seatd-devel
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.
From Kenny Levinsen to ~kennylevinsen/seatd-announce
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)`
From Kenny Levinsen to ~kennylevinsen/greetd-devel
Applied, thanks!