Denmark
This space intentionally left blank.
Comment by ~kennylevinsen on ~kennylevinsen/wlsunset
The project hub is located at https://sr.ht/~kennylevinsen/wlsunset/, which has all the links. There's a sourcehut todo for having backlinks from the services (https://todo.sr.ht/~sircmpwn/hub.sr.ht/15).
Can't complain that you don't have anything else to report. :P
REPORTED RESOLVED FIXED
Comment by ~kennylevinsen on ~kennylevinsen/wlsunset
Closed by fa2bd44253148ae8dc0e7145ffd2d0f04bfac1ab
REPORTED RESOLVED FIXED
Comment by ~kennylevinsen on ~kennylevinsen/greetd
XDG_CURRENT_DESKTOP is mentioned in fd.o specs though
Yup, just highlighting that the others' aren't, despite their misleading names. This has also lead to some thinking that XDG_SESSION_TYPE is a valid thing to read from user-space for e.g. picking wayland vs. x11 client backends, although I think we finally got all that killed. :/
Note: I'm mostly just ranting over how broken this is.
While I prefer no code when it serves no sane purpose, I do prefer a generic usable interface over one customized specifically to misuse of a broken systemd feature. :)
Comment by ~kennylevinsen on ~kennylevinsen/greetd
There are also things that require XDG_CURRENT_DESKTOP
These do not need to be set before pam_open_session, so in the spirit of simplicity, these should be handled as arbitrary environment vars set by a wrapper script (or even just by doing e.g.
XDG_CURRENT_DESKTOP=blah command).The only real reason to provide env vars in the protocol is to affect the PAM env in modules during pam_open_session. And, to my knowledge, the only relevant parameter is XDG_SESSION_TYPE for pam_systemd.so.
... freedesktop specifications ...
Note that XDG_SESSION_TYPE and all other logind XDG_* vars are not related to freedesktop specifications, but are purely systemd-internal variables with very unfortunate names, and no intention from systemd to upstream it to freedesktop.
For security considerations, allowed vars could be filtered (
^XDG_).XDG_SEAT, XDG_VTNR and XDG_SESSION_CLASS aren't supposed to be set.
It's really nasty that we'd have to add a protocol feature (even if a simple one that have existed before) just for a single var so that a single broken compositor can abuse an API. :(
Ticket created by ~kennylevinsen on ~migadu/alps
The readme doesn't mention what the project is, and the repo description is empty.
Ticket created by ~kennylevinsen on ~kennylevinsen/wlsunset
6500K is currently special cased to r,g,b of 1.0,1.0,1.0. However, the approximated planckian locus calculates the same temperature as 1.0,0.97,0.99, which is noticeably less green.
As any value below 6500 K uses planckian locus, a transition from 6500 K to 6499 K leads to a drop in green channel disproportionate to the requested change in color temperature.
Comment by ~kennylevinsen on ~kennylevinsen/greetd
Try to give master a shot. https://git.sr.ht/~kennylevinsen/greetd/commit/0d8812c80b2b61d5bd5bbd19b503459ff85ce7ff should have fixed the issue.
Comment by ~kennylevinsen on ~kennylevinsen/greetd
That's a fatal configuration error. Not much greetd can do other than fail at startup. It's true that there is a special case where initial is broken but default is not, but not sure if a limb mode for that special case is that useful.
On the other hand, I wonder if we could/should return a different status code so we could interrupt the pointless restart loop...
#10 should be fixed, but that's separate.
enhancement added by ~kennylevinsen on ~kennylevinsen/seatd