Hi,

This is a bit esoteric, I'm happy to try to patch and test this myself, especially if someone can give me a pointer.

I am trying to get away from passwords for my local machine. I have PAM configured to allow me to login with a u2f/fido2 token.

However, I also have udev configured to loginctl lock-sessions whenever I remove my fido2 token. This ends up trigger cosmic-greeter, which then does not find my fido2 token available, and switches to password prompt.

I'm wondering/hoping that there's a way to maybe bind Escape to "re-trigger" PAM? or like (securely) soft-reset the greeter/unlock process?/

Thanks for any tips! And thanks for Cosmic, already feels great!

unable to send message: Connection refused (os error 111) is shown for wrong password. Show the error copy instead.

From the unlock screen, if you want to show the password (eye icon) it does not show it. The password is always *****

when no "realname" is available, no name is being shown during login. Which can be confusing when having multiple users, as it's just blank

It updates after moving the mouse.

When logging in with GDM, the proper theme is respected.

I believe that this and #22 are both related to the latest change 1b13865

With confirmation dialog

https://www.figma.com/file/SkAtS5qlVOGQC0n895AHzX/Design-System-(WIP)?type=design&node-id=8235-11383&mode=design&t=Uy0g6aDVHcc7FAsz-0

When #27 is merged, it will be possible to save a file to some path like /run/user/$UID/cosmic-greeter-$XDG_SESSION_ID to denote when the session is supposed to be locked. This file can be used to automatically relock the session if either the compositor or the lock screen died and were restarted.

I only updated recently so I didn't realize I had didn't have cosmic-greeter-daemon running. But with the latest commit it implicitly enabled it.

I did downgrade/remove the want section, try it again, and it worked, manually enabled cosmic-greeter-daemon and it indeed just left me with a gray screen. Once cosmic-greeter-daemon breaks cosmic, a downgrade and restart is needed simply restarting cosmic-greeter is not good enough.

Logs were made using journalctl --boot -g cosmic > logs/cosmic-greeter-good.txt

good log:
cosmic-greeter-good.txt

bad log:
cosmic-greeter-bad.txt

Howdie, thanks so much for sharing this project! <3

I haven't tried running cosmic-greeter as my greeter since the cosmic-greeter-daemon work, and I can't seem to get it to run as before

After systemctl disable greetd.service ; systemctl enable cosmic-greeter.service cosmic-greeter-daemon.service, I reboot, and the system just sort of hangs or does nothing at the point where I'd usually see my other greeter (greetd) appear

I've also tried this with systemctl disable cosmic-greeter-daemon.service but that doesn't seem to change any noticeable behaviour

What does work, is switching to a different virtual console, logging in there, and systemctl restart cosmic-greeter.service

I believe what's happened here is that systemd-homed systems ( https://systemd.io/HOME_DIRECTORY/ ) do not have users stored in /etc/passwd (my username does not appear listed here at all), and HOME directories are not even decrypted and mounted until after the user has logged in

I've briefly read through the cosmic-greeter-daemon code, and I believe it returns an empty Vec because there aren't any users that pass the filter:

But, I haven't yet found if/where cosmic-greeter would behave weirdly due to this

I figured I'd log this issue and come back once I've investigated more thoroughly, hopefully with a PR

SSH'ed in to my machine after booting it and saw that cosmic greeter is using quite a bit of CPU. The issue goes away after login.

I'm currently on the latest version in the pop repos.

Howdie, thanks so much for sharing this exciting work! <3

I wanted to report this just so that it's tracked/known, even though the actual fix is probably upstream: 1wilkens/pam-sys#27

I'm uncertain when this began to be an issue, but I am finding I can no longer launch Gnome sessions using Wayland. I can launch Xorg Gnome sessions intermittently - though something in how those sessions launch is breaking Pop extensions for Gnome - but when ever I attempt to launch a Wayland session of Gnome, the screen goes black, as though it is launching a session, and immediately returns me to the greeter login prompt.

Such as the title

After #11, cosmic-greeter will run in the background process. It currently reads the background data and keeps it around. That should instead be done only when locked, and after unlocking it should trim malloc to reduce memory usage.

On serw13, I sometimes see a grey screen with no dialog when I try to lock the screen. This seemed to happen less with cosmic-greeter as my DM than before when I was using GDM, but I just had it happen again.

These seem to be the relevant logs (before this was me moving panel applets around, and after it was me running commands in the TTY):

Mar 01 16:53:06 serw13 cosmic-panel[3656]: [GL] GL_INVALID_VALUE in glTexSubImage2D(xoffset 0 + width 440 > 432)
Mar 01 16:53:06 serw13 cosmic-panel[3656]: [GL] GL_INVALID_VALUE in glTexSubImage2D(xoffset 0 + width 440 > 432)
Mar 01 16:53:06 serw13 cosmic-session[3613]: 2024-03-01T23:53:06.068695Z ERROR egl{platform="PLATFORM_WAYLAND_KHR" version=(1, 5)}:egl_context{ptr=98939939080992}:renderer_gles2: [GL] GL_INVALID_VALUE in glTexSubImage2D(xoffset 0 + width 440 > 432)
Mar 01 16:53:06 serw13 cosmic-session[3613]: 2024-03-01T23:53:06.068723Z ERROR egl{platform="PLATFORM_WAYLAND_KHR" version=(1, 5)}:egl_context{ptr=98939939080992}:renderer_gles2: [GL] GL_INVALID_VALUE in glTexSubImage2D(xoffset 0 + width 440 > 432)
Mar 01 16:53:28 serw13 cosmic-greeter[10291]: pam_unix(login:auth): conversation failed
Mar 01 16:53:28 serw13 cosmic-greeter[10291]: pam_unix(login:auth): auth could not identify password for [jacob]

Here's the whole journalctl file in case I missed something (note that I had to restart COSMIC Greeter earlier in the boot to get the login screen working in the first place): cosmic-greeter-lock-screen-failure.txt

This can be successfully worked around without losing the session using the following commands @jackpot51 gave me:

killall cosmic-greeter
WAYLAND_DISPLAY=wayland-1 cosmic-greeter

For first release, do not include "Show keyboard layout..." or "Keyboard settings..."

Usually I'm able to log-in but sometimes the greeter doesn't seem to work as expected.
I don't get the error message(below) in all of those occasions but I did got it once.
unable to send message: Transport endpoint is not connected (os error 107)

Let me know if anything on my end would fix this for me.

When launching a Pop!_OS 22.04 xorg Gnome session with Cosmic-Greeter, functionalities of the Cosmic extentions for Gnome do not work.

This includes:

• shortcuts such as super + q to quit applications and super + f to launch the file manager;
• Tiling does not work smoothly (hard to describe, but it is noticeably less fluid);
• The DING extension seems to have been effected, with icons present on the desktop that are both A) Not using the standard Pop!_OS icon set (looks to be the default Ubuntu icons, but I'm not certain) and B) launching a "find files on desktop" prompt with super + f when the desktop was the last item focused;
• and finally, the Pop-launcher does not return the correct results for certain searches, such as having no Nautilus/Files result when searching for either "Nautilus" or "Files".

These were just immediate issues. I'm truncating journal logs to drop in a subsequent comment (because no one needs 13000 lines when most of them aren't germane.)

Seems like some permission issue with cosmic-greeter causes cosmic-comp to panic (cosmic-greeter is never displayed, just the message in lines 116-132 in the attached file repeatedly being refreshed).
Output of journalctl -e:
journalctl_greeter.txt

I started cosmic-session from a different tty at the end and it starts up fine.
Sorry if it is a bit early to report an issue on something just implemented.

A menu isn't designed but it would be the same as input selection.

I recently reorganized my Pictures folder, and moved the image I use for my wallpaper into a subdirectory.

When I launched cosmic-greeter as a lock-screen, the background was blank and black. When I check logs, I see:

[WARN cosmic_greeter::Locker] output wl_output@6: failed to load wallpaper "home/daniel/Pictures/wallpaper.png": Os { code: 2, kind: NotFound, message: "No such file or directory" }

This is replicated several times for each active display.

The behaviour on a reboot is similar, save that the default "Cosmic" wallpaper (the word Cosmic with a handful of stars on a whirly blue galaxy background) displays.

I tested cosmic-greeter 0d7624b as display manager on a handful of graphics setups and found consistent behaviour across all of them.

I looked at integrated Intel and AMD graphics, discrete Nvidia and AMD desktop graphics, and a hybrid laptop with Intel iGPU and Nvidia dGPU.

Subjectively, the cosmic-session did feel like it loaded (drawing panel, dock, etc.) more slowly through cosmic-greeter vs. gdm, though that maybe a result of the desktop background being present in the DM.

All systems successfully logged in when first booted. On all systems, I could logout of the user session, and return to the DM login screen. I could login and logout multiple times.

On all systems, after several cycles of logging in and out, I would attempt another login and the user session would never launch. This usually took the form - symptomatically - of seeing the password prompt in cosmic-greeter disappear, and then nothing happening. Cosmic-greeter is responsive (e.g. I can shutdown with the GUI power button) in this state, it is just that the cosmic-session never starts. I need to look into this further.

I did not see any issue with cosmic-greeter displaying correctly when I logged out through the panel applet. However, on all hardware, I did see TTY1 getting stuck on a grey screen with a cursor when I exited my cosmic-session using the Super + Shift + Escape shortcut. On all hardware, I also saw the lockscreen provided by cosmic-greeter similarly getting stuck on a grey screen when triggered with the Super + Escape shortcut, but have yet to try it through the applet.

start-cosmic works fine, cosmic-session works fine, so I'm pretty confused and I've been trying to figure out why cosmic-greeter won't log in to the session properly. All I get is a brief black screen with a panic in greetd:

thread 'main' panicked at greetd/src/session/worker.rs:200:14:
unable to exec: EACCES

I tried looking at it with RUST_BACKTRACE=full but the stack trace was completely unhelpful, going through a lot of unknown areas and some libc areas

I have these dependencies installed (not including dependencies derived from build depends) (Fedora)

• greetd
• greetd-selinux
• dbus
• pam
• cosmic-comp
• fprintd-pam

OS: Fedora Silverblue 39 with COSMIC rpms applied
When I log in with cosmic-greeter, and run podman start {CONTAINER_ID}, I get an error similar to this:

sd-bus call: Process org.freedesktop.systemd1 exited with status 1: Input/output error

I followed an issue train:

containers/podman#13429
containers/buildah#4293
https://bugzilla.redhat.com/show_bug.cgi?id=1622259

Apparently, when $DBUS_SESSION_BUS_ADDRESS is unset, podman/toolbox just fails.

I tried logging in with GDM, and running the toolbox works

needs design

With the current master branch of cosmic-greeter, the display manager won't launch with the error "configured default user ‘cosmic-greeter’ not found". I am building cosmic-epoch with all submodules updated using git submodule update --remote with a Containerfile for a Fedora ostree image. The Container file is here: https://github.com/ryanabx/fedora-cosmic-atomic/blob/876895d2e3bc2740631ad62c165fa7ad8178d0e2/containers/fedora-cosmic-atomic/Containerfile

To fix this, I have to run some of the postinstall script in https://github.com/pop-os/cosmic-greeter/blob/master/debian/cosmic-greeter.postinst manually.

I had to create a cosmic-greeter user with useradd (adduser doesn't exist on a Fedora base image), make sure it is in the cosmic-greeter group, and that it has a home directory at /var/lib/cosmic-greeter

I don't know if this should be a manual process on my part, so I'm writing this as an issue. GDM and SDDM automatically work from a regular install but then again I am installing them from the .rpm instead of building manually.

I'd also suggest if possible that some of the postinstall script instead use the more ubiquitous useradd and groupadd as opposed to adduser and addgroup.

On a system with an internal display (eDP-1) and an external display (DP-1) such that the two displays are aligned at their bottoms with eDP-1 at the left edge of DP-1, the session starts with displays correct, and maintains display layout in the lock-screen.

But, when first logging in, the displays are such that they are top edge aligned with eDP-1 to the right of DP-1. This was the default layout that was generated the first time that DP-1 was attached to the system. However, across many unplug-replug cycles, the displays have consistently resumed my user-set arrangement everywhere except for initial session login.

I noticed my Odyssey G9 picks up some ghosting of my wallpaper image if I leave my home desktop locked all day. Seeing ghosting on such a display makes me uneasy, so I would be much more likely to use COSMIC DE as my daily driver on this setup if the lock screen could make my displays go into standby mode. This would also be good for OLED and plasma displays.

I know the log-in issues were supposed to be fixed but I started getting this error today & was unable to log in to cosmic session couple of times, even after multiple reboot.
Here is the error I kept seeing:

While git LFS is pretty nifty, At least arch doesn't support it via makepkg officially. (It is possible to use an AUR package which is what im using for my own pkgbuild scripts) but it's not ideal.

PS. you can shrink the png to 640kb using ect (or to 372kb using JXL lossless but image-rs doesn't support jxl yet and it's unclear when they will be willing to) if size is a factor