canonical/lightdm

Display Manager

LightDM Display Manager

LightDM is a lightweight, cross-desktop display manager. A display manager is a daemon that:

• Runs display servers (e.g. X) where necessary.
• Runs greeters to allow users to pick which user account and session type to use.
• Allows greeters to perform authentication using PAM.
• Runs session processes once authentication is complete.
• Provides remote graphical login options.

Key features of LightDM are:

• Cross-desktop - supports different desktop technologies (X, Wayland, Mir, etc)
• Lightweight - low memory usage and fast performance
• Supports remote login (incoming: XDMCP and VNC; outgoing: XDMCP and pluggable)
• Supports guest sessions
• Has a comprehensive test suite

The core LightDM project does not provide any greeter with it; you should install a greeter appropriate to your system. Popular greeter projects are:

• LightDM GTK+ Greeter - a greeter that has moderate requirements (GTK+).
• LightDM KDE - greeter used in KDE (Qt)
• LXQt Greeter - greeter used in LXQt (Qt)
• Pantheon Greeter - greeter used in elementary OS (GTK+/Clutter).
• Unity Greeter - greeter used in Unity.
• WebKit2 Greeter - greeter that can be themed using HTML/CSS/Javascript
• Run with no greeter (automatic login only)
• Write your own...

Configuration

LightDM configuration is provided by the following files:

/usr/share/lightdm/lightdm.conf.d/*.conf
/etc/lightdm/lightdm.conf.d/*.conf
/etc/lightdm/lightdm.conf

System provided configuration should be stored in /usr/share/lightdm/lightdm.conf.d/. System administrators can override this configuration by adding files to /etc/lightdm/lightdm.conf.d/ and /etc/lightdm/lightdm.conf. Files are read in the above order and combined together to make the LightDM configuration.

For example, if a sysadmin wanted to override the system configured default session (provided in /usr/share/lightdm/lightdm.conf.d) they should make a file /etc/lightdm/lightdm.conf.d/50-myconfig.conf with the following:

[Seat:*]
user-session=mysession

Configuration is in keyfile format. For most installations you will want to change the keys in the [Seat:*] section as this applies to all seats on the system (normally just one). A configuration file showing all the possible keys is provided in data/lightdm.conf.

Display Setup Script

LightDM can be configured to run an external shell script to setup displays.

If an display setup script is used, it must be:

• Located under /usr/share
• Owned by the user lightdm and group lightdm
• It cannot print or log to any destination not accessible to LightDM

To test a configuration:

• Install xserver-xephyr: sudo apt install xserver-xephyr
• Run the test as user lightdm: sudo -u lightdm lightdm --test-mode --debug

Put the shell script reference in the LightDM configuration:

[Seat:*]
display-setup-script=/usr/share/example_display_setup_script.sh 

Questions

Stack Overflow and Ask Ubuntu are good sites for frequently asked questions.

lightdm's Issues

Unity-greeter doesn't change background since 1.25.1 (Bionic)

On Bionic, Since lightdm 1.25.1 unity-greeter doesn't change background when user wallpapers is changed. From /var/log/lightdm/seat0-greeter.log couldn't find anything significant other than

** (unity-settings-daemon:7310): WARNING **: 17:38:25.036: Unable to register client: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method 'RegisterClient'

Downgrading lightdm to 1.25.0 fixes the issue.

All related components updated to latest versions.

Support non-root X

Currently lightdm runs Xorg as root

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       851  0.9  1.5 751600 254880 tty1    Ssl+ May11  43:46 /usr/libexec/Xorg -core -noreset :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt1 -novtswitch -background none

https://bugs.launchpad.net/lightdm/+bug/1292324

Allow using journal for logging

lightdm only seems to log to files in /var/log. It would be much more convenient if it could be built with libsystemd support and log to systemd journal like GDM does.

Downstream issue: NixOS/nixpkgs#26172

display/greeter-setup-script in one seat is blocking greeter session in the other ones

In my multi-seat setup, I want to run a pre-greeter script (configured via display/greeter-setup-script) that waits for user input before greeter starts in some seats. However, I'm observing that my script is blocking lightdm in such a way that the next seat's greeter will only be spawned when the previous seat's display/greeter-setup-script has finished.

Is there a way to make lightdm spawn my display/greeter-setup-scripts in a non-blocking way?

P.S.: I've already thought about the possibility to use a greeter-wrapper rather than a greeter-setup-script, but greeter-wrapper is run as lightdm user, right? In this case, my wrapper script would fail, unless user lightdm is member of group input.

Add means to autologin users from external program

How difficult would it be to add:

• an API to trigger an instant one-shot auto-login for a specified user.
  OR
• a lightdm.conf setting for guest-login-account=username - so files don't get deleted.

The auto-login is a one-shot so once the student logs out the next class of say Grade 7's can use their own personal accounts.

We use lightdm for our thin clients in 51 educational schools and facilities. Kindergarten and grade 1 teachers would like the ability to click a button and have the entire lab auto-login for the little guys that are just learning their alphabet. Lightdm's "guest" account in /tmp/ breaks our ability to audit home folder.

Ligthdm does not prompt for new password

When a user has an expired password and enters their login and password, they receive a message underneath the password text box reading "Changing password for <user>". No new text boxes appear for the password and to verify the password. The existing text box does not change the password.

The message changes whether using authenticating an LDAP user or a local user, but the issue is the same.

Attached lightdm.log

Versions

Raspbian (Debian) 9.3 stretch

lightdm 1.18.3-1
lightdm-gtk-greeter 2.0.2-1

Steps to reproduce

1. Expire a local user (chage -d 0 user)
2. Attempt to login with user
3. Receive the error message
4. Type new password using existing text box.

make install fails on reinstall

Doing subsequent make install fails with:

ln: failed to create symbolic link '/usr/share/accountsservice/interfaces/org.freedesktop.DisplayManager.AccountsService.xml': File exists

The install process tries to create the link with 'ln -s', so it fails since the symbolic link is already there. Should the install use 'ln -sf'?

mouse cursor problem

Hello

is it possible to add an option to customize the mouse cursor for Lightdm ???

or if a trick exists, I am interested.
despite long research and some manipulations, it is still the Adwaita cursor that is present on Lightdm .....

I'm using Debian and ArchLinux with Cinnamon.
Thank you.

Unable to hide user name during log in

I've tried to solve this small but annoying issue myself.

I run Manjaro XFCE, it uses lightdm by default. For some reason it (now) will not hide the user name. Since it's only me that ever uses this computer it's an annoying extra. It used to work fine but doesn't any longer.

I've gone as far as to log into the terminal directly during boot, then completely removed all of lightdm, all of the greeters, all of the configuration files, including the .pacsave in /etc/lightdm/ and even removed the light-locker package. AFAIK that was lightdm and any dependency.

I then completely reinstalled, installing only lightdm, lightdm-gtk-greeter and the lightdm-gtk-greeter-settings gui.

I've read what documentation I can find. Despite I have clearly set hide-greeter-users=true under [Seat:*] I still have to enter my user name at login.

I have then installed the lightdm-slick-greeter and edited its config, which also contains a field hidden-users and which I set. STILL no joy.

Is there some cache/.config I need to remove or clean?

It used to work fine. I can't see how any update to Manjaro or its kernels could have affected me?

edit: p.s. have removed the AccountsService package completely. Issue still exists.

Is XDG_SEAT variable available for {display,greeter}-setup-script?

I want to write a display/greeter setup script for LightDM which should be aware of current systemd-logind seat name, but it seems environment variable XDG_SEAT is not avaiable for those scripts. Is there any other way to get correct seat name from display/greeter setup script?

Default to "greeter-show-manual-login = true"

Hi, since 2016 AccountsService uses a MAX_LOCAL_USERS=50 limit, meaning that only the first 50 users are able to login by default:
https://gitlab.freedesktop.org/accountsservice/accountsservice/issues/39

To match that change in AccountsService, please update the default lightdm configuration to:
greeter-show-manual-login = true

...so that at least the rest of the users are able to login by typing their username.

Remove Mir support

You know why…

lightdm-session should be installed as executable

Instead of 644, shouldn’t /usr/bin/lightdm-session be made executable (755)?

Starting graphical session targets

The display manager should start SystemD's "graphical-session.target" and "graphical-session-pre.target", so graphical units are started too.

Lightdm does not start session on kernels without TTY and VT support

Trying to use lightdm on debian on kernel without TTY and VT. Loginctl reports no sessions.
Error: Jul 15 15:27:34 okt lightdm[2605]: pam_systemd(lightdm-autologin:session): Failed to create session: Seat has no VTs but VT number not 0

Frequent segfaults when authenticating with AD using pbis-open

My workplace uses pbis-open to authenticate users machines with AD. lightdm frequently crashes under Ubuntu 18.04 when I try to login. It does work eventually but it usually takes a few tries. I see the following error in dmesg:

[   27.305847] lightdm[1573]: segfault at 8 ip 00007f1fbc4b9c77 sp 00007ffcad065590 error 4 in pam_lsass.so[7f1fbc4b5000+c000]
[   27.305859] Code: ff ff 41 83 3e 05 0f 86 8b f6 ff ff 41 b9 5a 03 00 00 89 2c 24 e9 e4 f8 ff ff 48 8b 9c 24 30 05 00 00 4c 8b a4 24 a0 04 00 00 <4c> 8b 7b 08 4c 89 e7 4c 89 fe e8 9a d6 ff ff 85 c0 0f 84 b7 f6 ff 

The first two lines of my /etc/nsswitch.conf look like:

passwd:         compat systemd lsass
group:          compat systemd lsass

Make .dmrc follow XDG base directory specification

One of my personal pet peeves is applications cluttering my home directory - every once in a while I try uncluttering it to see just how far I can get.

This time .dmrc is on my hit list. Could it be read from ${XDG_CONFIG_HOME:-$HOME/.config}/lightdm/dmrc, following the XDG base directory specification, or at least be configurable in some way?

Provide some pkg-config variables

It would be really nice (and cheat to implement)

Some useful variables:
xgreeters (/usr/share/xgreeters)
lightdm_data (/usr/share/lightdm/)
lightdm_sysdir (/etc/lightdm/)

That way it's always reliable

db-tool lock+x11vnc run cmd without unlock

Hi!
Im user xfce
Alt+r hot keys to xfce4-terminal (or any key to run any commands)

Step 1

on terminal
$ x11vnc

Step 2

$ dm-tool lock

Step 3

Connect to host via vnc
see black screen
Next press Alt+r and put any command
Command will be execute on new running terminal without unlock screen

Examples im put sudo reboot and my pc rebooted

Duplicated name-entries.

Hi. Investigation made upon suggested links –one at a time– present on Red Hat Bugzilla – 1518343.

leaking fds in VNCServer mode until explodes from out of fds

We are running lightdm 1.25.0 (CentOS7) with

[VNCServer]
enabled=true
command=Xvnc -securitytypes vencrypt,x509none -x509cert ... -x509key ...
depth=24

and it seems that lightdm is not closing the VNC sockets. That is, the total number of sockets just keeps increasing until it explodes with out of file descriptor messages.

Here is a listing of the /proc//fd directory after running for about 30-60min.

lr-x------ 1 root root 64 May 14 14:41 0 -> /dev/null
lrwx------ 1 root root 64 May 14 14:41 1 -> socket:[73145]
lr-x------ 1 root root 64 May 14 14:41 10 -> /var/lib/lightdm-data
lrwx------ 1 root root 64 May 14 15:04 100 -> socket:[67840]
lrwx------ 1 root root 64 May 14 15:04 101 -> socket:[67843]
lrwx------ 1 root root 64 May 14 15:04 102 -> socket:[67846]
lrwx------ 1 root root 64 May 14 15:04 103 -> socket:[59411]
lrwx------ 1 root root 64 May 14 15:04 104 -> socket:[29866]
lrwx------ 1 root root 64 May 14 15:04 105 -> socket:[37109]
lrwx------ 1 root root 64 May 14 15:04 106 -> socket:[46129]
lrwx------ 1 root root 64 May 14 15:04 107 -> socket:[10326]
lrwx------ 1 root root 64 May 14 15:04 108 -> socket:[10329]
lrwx------ 1 root root 64 May 14 15:04 109 -> socket:[22757]
lrwx------ 1 root root 64 May 14 14:41 11 -> socket:[34575]
lrwx------ 1 root root 64 May 14 15:04 110 -> socket:[26996]
lrwx------ 1 root root 64 May 14 15:04 111 -> socket:[70812]
lrwx------ 1 root root 64 May 14 15:04 112 -> socket:[37112]
lrwx------ 1 root root 64 May 14 15:04 113 -> socket:[10332]
lrwx------ 1 root root 64 May 14 15:04 114 -> socket:[22760]
lrwx------ 1 root root 64 May 14 15:04 115 -> socket:[18666]
lrwx------ 1 root root 64 May 14 15:04 116 -> socket:[10335]
lrwx------ 1 root root 64 May 14 15:04 117 -> socket:[59414]
lrwx------ 1 root root 64 May 14 15:04 118 -> socket:[29869]
lrwx------ 1 root root 64 May 14 15:04 119 -> socket:[29874]
lrwx------ 1 root root 64 May 14 14:41 12 -> socket:[34577]
lrwx------ 1 root root 64 May 14 15:04 120 -> socket:[19970]
lrwx------ 1 root root 64 May 14 15:04 121 -> socket:[29877]
lrwx------ 1 root root 64 May 14 15:04 122 -> socket:[29880]
lrwx------ 1 root root 64 May 14 15:04 123 -> socket:[10339]
lrwx------ 1 root root 64 May 14 14:41 13 -> socket:[70767]
lrwx------ 1 root root 64 May 14 14:41 14 -> socket:[67769]
lrwx------ 1 root root 64 May 14 14:41 15 -> socket:[68681]
lrwx------ 1 root root 64 May 14 14:41 16 -> socket:[67772]
lrwx------ 1 root root 64 May 14 14:41 17 -> socket:[29834]
lrwx------ 1 root root 64 May 14 14:41 18 -> socket:[36215]
lrwx------ 1 root root 64 May 14 14:41 19 -> socket:[22697]
lrwx------ 1 root root 64 May 14 14:41 2 -> socket:[73145]
lrwx------ 1 root root 64 May 14 14:41 20 -> socket:[22699]
lrwx------ 1 root root 64 May 14 14:41 21 -> socket:[26960]
lrwx------ 1 root root 64 May 14 14:41 22 -> socket:[59399]
lrwx------ 1 root root 64 May 14 14:41 23 -> socket:[29843]
lrwx------ 1 root root 64 May 14 14:41 24 -> socket:[68686]
lrwx------ 1 root root 64 May 14 14:41 25 -> socket:[46111]
lrwx------ 1 root root 64 May 14 14:41 26 -> socket:[66711]
lrwx------ 1 root root 64 May 14 14:41 27 -> socket:[56410]
l-wx------ 1 root root 64 May 14 14:41 28 -> pipe:[13640]
lrwx------ 1 root root 64 May 14 14:41 29 -> socket:[46108]
lrwx------ 1 root root 64 May 14 14:41 3 -> anon_inode:[eventfd]
lrwx------ 1 root root 64 May 14 14:41 30 -> socket:[67775]
lr-x------ 1 root root 64 May 14 14:41 31 -> pipe:[13641]
lr-x------ 1 root root 64 May 14 14:41 32 -> /ram/var/lib/sss/mc/passwd
lrwx------ 1 root root 64 May 14 14:41 33 -> socket:[68696]
lrwx------ 1 root root 64 May 14 14:41 34 -> socket:[56413]
lrwx------ 1 root root 64 May 14 14:41 35 -> socket:[70790]
lrwx------ 1 root root 64 May 14 14:41 36 -> socket:[59402]
lrwx------ 1 root root 64 May 14 14:41 37 -> socket:[26980]
lrwx------ 1 root root 64 May 14 14:41 38 -> socket:[46122]
lrwx------ 1 root root 64 May 14 14:41 39 -> socket:[29848]
lr-x------ 1 root root 64 May 14 14:41 4 -> pipe:[34569]
lrwx------ 1 root root 64 May 14 14:49 40 -> socket:[56416]
lrwx------ 1 root root 64 May 14 14:49 41 -> socket:[18645]
lrwx------ 1 root root 64 May 14 14:49 42 -> socket:[10296]
lrwx------ 1 root root 64 May 14 14:49 43 -> socket:[66714]
lrwx------ 1 root root 64 May 14 14:49 44 -> socket:[10299]
lrwx------ 1 root root 64 May 14 14:49 45 -> socket:[10302]
lrwx------ 1 root root 64 May 14 14:49 46 -> socket:[10305]
lrwx------ 1 root root 64 May 14 14:49 47 -> socket:[46123]
lrwx------ 1 root root 64 May 14 14:49 48 -> socket:[67796]
lrwx------ 1 root root 64 May 14 14:49 49 -> socket:[18648]
l-wx------ 1 root root 64 May 14 14:41 5 -> pipe:[34569]
lrwx------ 1 root root 64 May 14 14:49 50 -> socket:[67799]
lrwx------ 1 root root 64 May 14 14:49 51 -> socket:[29851]
lrwx------ 1 root root 64 May 14 14:49 52 -> socket:[67802]
lrwx------ 1 root root 64 May 14 14:50 53 -> socket:[68699]
lrwx------ 1 root root 64 May 14 14:50 54 -> socket:[18651]
lrwx------ 1 root root 64 May 14 14:50 55 -> socket:[67805]
lrwx------ 1 root root 64 May 14 14:50 56 -> socket:[66717]
lrwx------ 1 root root 64 May 14 14:50 57 -> socket:[66720]
lrwx------ 1 root root 64 May 14 14:50 58 -> socket:[10308]
lrwx------ 1 root root 64 May 14 14:53 59 -> socket:[28727]
l-wx------ 1 root root 64 May 14 14:41 6 -> /local/var/log/lightdm/lightdm.log
lrwx------ 1 root root 64 May 14 14:53 60 -> socket:[67809]
lrwx------ 1 root root 64 May 14 14:53 61 -> socket:[28730]
lrwx------ 1 root root 64 May 14 14:53 62 -> socket:[59405]
lrwx------ 1 root root 64 May 14 14:53 63 -> socket:[70797]
lrwx------ 1 root root 64 May 14 14:53 64 -> socket:[68702]
lrwx------ 1 root root 64 May 14 14:53 65 -> socket:[66723]
lrwx------ 1 root root 64 May 14 14:53 66 -> socket:[68705]
lrwx------ 1 root root 64 May 14 14:53 67 -> socket:[56425]
lrwx------ 1 root root 64 May 14 14:53 68 -> socket:[37071]
lrwx------ 1 root root 64 May 14 14:53 69 -> socket:[37074]
lrwx------ 1 root root 64 May 14 14:41 7 -> anon_inode:[eventfd]
lrwx------ 1 root root 64 May 14 14:53 70 -> socket:[46126]
lrwx------ 1 root root 64 May 14 14:53 71 -> socket:[29854]
lrwx------ 1 root root 64 May 14 14:53 72 -> socket:[67812]
lrwx------ 1 root root 64 May 14 14:53 73 -> socket:[18654]
lrwx------ 1 root root 64 May 14 14:55 74 -> socket:[18657]
lrwx------ 1 root root 64 May 14 14:55 75 -> socket:[67825]
lrwx------ 1 root root 64 May 14 14:55 76 -> socket:[67828]
lrwx------ 1 root root 64 May 14 14:55 77 -> socket:[10311]
lrwx------ 1 root root 64 May 14 14:55 78 -> socket:[29857]
lrwx------ 1 root root 64 May 14 14:55 79 -> socket:[26990]
lrwx------ 1 root root 64 May 14 14:41 8 -> anon_inode:[eventfd]
lrwx------ 1 root root 64 May 14 15:04 80 -> socket:[18660]
lrwx------ 1 root root 64 May 14 15:04 81 -> socket:[18663]
lrwx------ 1 root root 64 May 14 15:04 82 -> socket:[22751]
lrwx------ 1 root root 64 May 14 15:04 83 -> socket:[59408]
lrwx------ 1 root root 64 May 14 15:04 84 -> socket:[29860]
lrwx------ 1 root root 64 May 14 15:04 85 -> socket:[22754]
lrwx------ 1 root root 64 May 14 15:04 86 -> socket:[10314]
lrwx------ 1 root root 64 May 14 15:04 87 -> socket:[29863]
lrwx------ 1 root root 64 May 14 15:04 88 -> socket:[37100]
lrwx------ 1 root root 64 May 14 15:04 89 -> socket:[19941]
lrwx------ 1 root root 64 May 14 14:41 9 -> socket:[74967]
lrwx------ 1 root root 64 May 14 15:04 90 -> socket:[28739]
lrwx------ 1 root root 64 May 14 15:04 91 -> socket:[67831]
lrwx------ 1 root root 64 May 14 15:04 92 -> socket:[67834]
lrwx------ 1 root root 64 May 14 15:04 93 -> socket:[67837]
lrwx------ 1 root root 64 May 14 15:04 94 -> socket:[70809]
lrwx------ 1 root root 64 May 14 15:04 95 -> socket:[37103]
lrwx------ 1 root root 64 May 14 15:04 96 -> socket:[10317]
lrwx------ 1 root root 64 May 14 15:04 97 -> socket:[10320]
lrwx------ 1 root root 64 May 14 15:04 98 -> socket:[26993]
lrwx------ 1 root root 64 May 14 15:04 99 -> socket:[10323]

I realize it would be better if I tested the latest version and such, but I didn't find any new commits mentioning file descriptors since the 1.25.0 tag, so figured I would mention it here first in case it is something easy for someone familiar with the code to address.

Thanks! -Tyson

Missing some input devices in wayland session

I am using sway compiled from git master on Debian and I noticed that my Fn+Brightness keys were not reporting any events when Sway is started by LightDM (via a custom desktop file in /usr/share/wayland-sessions/ ). Everything works fine when I manually start Sway from a VT.

I eventually figured out that Sway started via LigthDM is only showing 5 of the 8 input devices that my laptop is normally providing. However, those missing input devices exist in the system and can be tested using evtest or libinput. I also noticed that the missing input devices (and the brightness key events) become visible after switching back and forth to another VT.

The issue is not limited to Sway. I also tested Weston. It does not provide a list of its input devices but I noticed that weston-eventdemo is not reporting any event for the Fn+Brightness keys until I switch VT manually.

So I suspect a race condition between LightDM and the Wayland compositor using libinput (because of ibus? systemd? VT switch?).

For me, a temporary workaround was to add a sleep 1 command before starting sway.

System information:

• debian buster
• ligthdm 1.26.0-3
• weston 5.0.0-1
• libinput 1.12.6-1
• sway version 1.0-rc1-145-g19df2e59 (Mar 6 2019, branch 'master')

Potential security issue - method for bypassing LightDM lock screen to gain system access

Hello,

I believe I have uncovered a method for bypassing the lightDM lock screen (almost entirely), to be able to access a user's session.

I am unsure of the correct location for this information, or the procedure I should follow for reporting it.

I am on Ubuntu 18.04.

ryanisnan [at] gmail.

Dynamic auto-login

How do I get lightdm to reload it's lightdm.conf on logout?

Just recently upgraded from Ubuntu 12.04 to 16.04 and we lost some lightdm functionality.

With 12.04 lightdm would reload it's lightdm.conf at log out. This gave us the ability to dynamically change lightdm.conf to support auto-logins in our schools.

i.e. A teacher presses auto-login which updates the lightdm.conf to autologin-user=USERNAME. Then reloads lightdm.service. This works great!

The problem is when the teacher want's auto-login disabled. The login completes and lightdm.conf is changed back to remove "#autologin-user" but lightdm does not reload it's config settings. It will autologin-user=USERNAME as it's stored in memory. Previously at logout it would reload settings. It seems I have to manually "systemctrl restart lightdm.service"

How do I get lightdm to reload it's lightdm.conf on logout?

Thanks.

Implement visual countdown when autologin-user-timeout is set

I have configured lightdm.conf with a 10 second autologin timeout. It works, but I don't see a countdown on the login screen. This would be a helpful feature reduce additional. MDM has this but sometimes distributions change the display manager and having a common set of useful features might be desirable. (E.g. one wouldn't have to switch to MDM to get that countdown back.)

XDMCP connection not closing on user logout

I enabled XDMCP and it seems to work normally until I logout from remote desktop. The desktop session has fully exited, username has disappeared from the list, but it stuck at the wallpaper left on the screen unless I terminate the connection forcefully.

After I disconnect, the greeter still considers me as logged in and marks me in bold.
lightdm.log at logout:

[+2744.81s] DEBUG: Seat (null): Exit status of /etc/X11/xdm/Xreset: 0
[+2744.81s] DEBUG: Seat (null): Stopping display server, no sessions require it
[+2744.81s] DEBUG: Seat (null): Display server stopped
[+2744.81s] DEBUG: Seat (null): Active display server stopped, starting greeter
[+2744.81s] DEBUG: Seat (null): Stopping; failed to start a greeter
[+2744.81s] DEBUG: Seat (null): Stopping
[+2744.81s] DEBUG: Seat (null): Stopped
[+2744.81s] WARNING: instance with invalid (NULL) class pointer
[+2744.81s] CRITICAL: g_signal_emit_valist: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

I confirmed this on many RHEL distributions, including CentOS 7, Fedora 27 and OpenSUSE Leap 42.3. But it's fine in Debian family.
LightDM versions are 1.25.0 on EPEL and 1.22.0 on OpenSUSE.

Full log:
lightdm.log

Request for setting OOM score for X server

Would it be possible to add an option to the config to adjust the OOM score of the X server?

The Linux kernel uses this in a low-memory situation to decide which process to terminate in order to free up memory, and because the X server gets quite large with a lot of programs running, it often gets killed first, bringing down the whole session.

It would be nice if the OOM score could be adjusted so that the X server has a much lower score by default, so that the kernel will choose to kill a user process like a web browser before the X server, allowing the desktop session to continue after an out-of-memory situation.

(I did send a message to the LightDM mailing list about this but it never arrived so not sure if the list is accepting new subscriptions or not.)

mlockall() call needs to be removed

mlockall() is generally a bad idea and certainly has no place in a graphical program. A program like this uses lots of memory and it is crucial that this memory can be paged out to relieve memory pressure.
It also doesn't have the desired security effect. See https://bugzilla.redhat.com/show_bug.cgi?id=1662857#c18 for a longer explanation.

If you want to keep memory locked for the vestigial security effect, apply mlock() carefully for the space used to store the password, and/or use explicit_bzero to erase afterwards.

mlockall() also prevents the machine from starting if the memory lock limit is raised high enough, see the linked bug.

Setting XAUTHORITY environment variable causes LightDM to be unable to launch window manager

If XAUTHORITY environment variable set set, LightDM ignores it and saves to ~/.Xauthority instead. When window manager starts, it fails to start because it cannot find Xauthority.

Relevant code: https://github.com/CanonicalLtd/lightdm/blob/712a0254baf2bedf0370affbb3b54bc68c2aafc2/src/session.c#L815

Invalid test in configure.ac

I'm updating LightDM for pkgsrc (NetBSD packager) and I encountered the following error:
=> Checking for portability problems in extracted files
ERROR: [check-portability.awk] => Found test ... == ...:
ERROR: [check-portability.awk] configure: if test "x$GCC" == xyes; then

Explanation:

The "test" command, as well as the "[" command, are not required to know
the "==" operator. Only a few implementations like bash and some
versions of ksh support it.

The following patch fixes the error:
--- configure.ac.orig 2018-03-21 23:13:29.000000000 +0000
+++ configure.ac
@@ -15,12 +15,12 @@ AC_PROG_MKDIR_P
AM_MAINTAINER_MODE

dnl Check if the compiler really supports -std=c99.
-if test "x$ac_cv_prog_cc_c99" == xno; then
+if test "x$ac_cv_prog_cc_c99" = xno; then
AC_MSG_ERROR([$CC does not support '-std=c99'.])
fi

dnl Enable compile warnings (only supporting GCC)
-if test "x$GCC" == xyes; then
+if test "x$GCC" = xyes; then
WARN_CFLAGS="-Wall
-Wstrict-prototypes
-Wnested-externs \

Document multi-seat/multi-session configurations

Better said, I can't find any such documentation. The chief document on lightdm I find is:

https://wiki.ubuntu.com/LightDM

Now I know that I have a default session on vt7 and that I can switch user and this opens a new greeter on vt8. This is shown clearly as two sessions on one seat by dm-tool.

And I also know I'm not alone in wanting to see this greeter on vt8 after boot without having to switch user as others are asking and posting solutions:

https://askubuntu.com/questions/505120/how-to-enable-second-x-session-on-tty8-in-14-04

https://unix.stackexchange.com/questions/87169/autostart-all-lightdm-seats-and-show-one-as-default

but these solutions all propose one seat per vt (a multi-seat solution). There must be a multi-session solution as well given we see that "switch user" produces this very outcome. But the documentation on configurations is so meagre I cannot divine how we might configure lightdm to produce the outcome that lies between these solutions. Namely a mult-session configuration that sees a greeter displayed on vt7 and vt8 (and/or more vts) after boot.

I'd love to see this documented somewhere.

"Not running inside a display manager, XDG_SEAT_PATH not defined" without giving a clue on how to set XDG_SEAT_PATH

Today I was greeted by the "This screen is locked. It will be unlocked in a second" screen that would in fact not go away in a second nor in two seconds.

So I switched to a text console, did a ps faux, saw lightdm, man lightdm, saw "SEE ALSO" dm-tool, did man dm-tool, saw the various dm-tool commands and did:

# dm-tool switch-to-greeter
Not running inside a display manager, XDG_SEAT_PATH not defined

Yeah, however how should I know what to set XDG_SEAT_PATH to for heaven's sake? man dm-tool doesn't mention it, nor does man lightdm. What gives?

traps: lightdm[27882] general protection ip:413fa7 sp:7ffda5e6c650 error:0 in lightdm[407000+26000]

Hi
I've tried to run lightdm with --test-mode --debug but get a Segmentation fault (core dumped) (lightdm-1.24.0)
Here is the output:

[+0.00s] DEBUG: Logging to /home/jacks/.cache/lightdm/log/lightdm.log
[+0.00s] DEBUG: Starting Light Display Manager 1.24.0, UID=1000 PID=27882
[+0.00s] DEBUG: Loading configuration dirs from /usr/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
[+0.00s] DEBUG: Running in user mode
[+0.00s] DEBUG: Registered seat module local
[+0.00s] DEBUG: Registered seat module xremote
[+0.00s] DEBUG: Registered seat module unity
[+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
[+0.01s] DEBUG: Monitoring logind for seats
[+0.01s] DEBUG: New seat added from logind: seat0
[+0.01s] DEBUG: Seat seat0: Loading properties from config section Seat:*
[+0.01s] DEBUG: Seat seat0: Starting
[+0.01s] DEBUG: Seat seat0: Creating greeter session
[+0.01s] DEBUG: Loading users from org.freedesktop.Accounts
[+0.01s] DEBUG: User /org/freedesktop/Accounts/User1000 added
[+0.02s] DEBUG: Seat seat0: Creating display server of type x
[+0.02s] DEBUG: posix_spawn avoided (fd close requested)
[+0.02s] DEBUG: Could not run plymouth --ping: Failed to execute child process ?plymouth? (No such file or directory)
[+0.02s] DEBUG: Seat seat0: Starting local X display
[+0.02s] DEBUG: XServer 0: Logging to /home/jacks/.cache/lightdm/log/x-0.log
[+0.02s] DEBUG: XServer 0: Writing X server authority to /home/jacks/.cache/lightdm/run/root/:0
[+0.11s] DEBUG: XServer 0: Launching X Server
[+0.11s] DEBUG: Launching process 27888: /usr/bin/X :0 -seat seat0 -auth /home/jacks/.cache/lightdm/run/root/:0 -nolisten tcp
[+0.11s] DEBUG: XServer 0: Waiting for ready signal from X server :0
[+0.11s] DEBUG: Acquired bus name org.freedesktop.DisplayManager
[+0.11s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat0
[+0.12s] DEBUG: Process 27888 exited with return value 1
[+0.12s] DEBUG: XServer 0: X server stopped
[+0.12s] DEBUG: XServer 0: Removing X server authority /home/jacks/.cache/lightdm/run/root/:0
[+0.12s] DEBUG: Seat seat0: Display server stopped
[+0.12s] DEBUG: Seat seat0: Stopping session
[+0.12s] DEBUG: Seat seat0: Session stopped
[+0.12s] DEBUG: Seat seat0: Stopping display server, no sessions require it
[+0.12s] DEBUG: Seat seat0: Stopping; greeter display server failed to start
[+0.12s] DEBUG: Seat seat0: Stopping
[+0.12s] DEBUG: Seat seat0: Stopped
[+0.12s] DEBUG: Required seat has stopped
[+0.12s] DEBUG: Stopping display manager
[+0.12s] DEBUG: Display manager stopped
[+0.12s] DEBUG: Stopping daemon
[ 8130.690166] traps: lightdm[27882] general protection ip:413fa7 sp:7ffda5e6c650 error:0 in lightdm[407000+26000]
[ 8130.690220] audit: type=1701 audit(1540035604.134:43): auid=1000 uid=1000 guid=1000 ses=15 subj=kernel pid=27882 comm="lightdm" exe="/usr/bin/lightdm" sig=11 res=1
Segmentation fault (core dumped)

Icon unlock and login screen low resolution

Icon in unlock screen and in login screen is of low resolution. See screenshot in attachment for screen of 1280 x 1080 pixels.

https://sourceforge.net/p/lxde/bugs/886/attachment/IMG_20171026_093942.jpg

https://sourceforge.net/p/lxde/bugs/_discuss/thread/8db71fe0/9543/attachment/Untitled.png

original bug report is at https://sourceforge.net/p/lxde/bugs/886/

localization problem:"login" string

while change system language to non-english ,the login button still show "login",and there is no string in *.po files to do the transelation,is it a bug or just feature?

Login screen not showing till you hold any key

As reported in Manjaro:

After the latest update the login screen no longer shows in LightDM 1.26.0. Happens in various desktop environments and computers from different users.

No error messages are printed, only the usual stuff when booting up. It simply doesn’t pass the latest screen, although the computer is still responsive to the shutdown button and holding any key brings up the login screen.

In the Terminal if you enter:
sudo lightdm --test-mode --debug

It shows:

[+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.00s] DEBUG: Starting Light Display Manager 1.26.0, UID=0 PID=1331
[+0.00s] DEBUG: Loading configuration dirs from /usr/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /usr/share/lightdm/lightdm.conf.d/60-deepin.conf
[+0.00s] DEBUG: Loading configuration dirs from /usr/local/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
[+0.00s] DEBUG: Using Xephyr for X servers
[+0.00s] DEBUG: Registered seat module local
[+0.00s] DEBUG: Registered seat module xremote
[+0.00s] DEBUG: Registered seat module unity
[+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
[+0.01s] DEBUG: Monitoring logind for seats
[+0.01s] DEBUG: New seat added from logind: seat0
[+0.01s] DEBUG: Seat seat0: Loading properties from config section Seat:*
[+0.01s] DEBUG: Seat seat0: Starting
[+0.01s] DEBUG: Seat seat0: Creating greeter session
[+0.01s] DEBUG: Seat seat0: Creating display server of type x
[+0.01s] DEBUG: Could not run plymouth --ping: Failed to execute child process ?plymouth? (No such file or directory)
[+0.01s] DEBUG: Using VT 1
[+0.01s] DEBUG: Seat seat0: Starting local X display on VT 1
[+0.01s] DEBUG: XServer 1: Logging to /var/log/lightdm/x-1.log
[+0.01s] DEBUG: XServer 1: Can't launch X server Xephyr, not found in path
[+0.01s] DEBUG: XServer 1: X server stopped
[+0.01s] DEBUG: Releasing VT 1
[+0.01s] DEBUG: Seat seat0: Display server stopped
[+0.01s] DEBUG: Seat seat0: Can't create display server for greeter
[+0.01s] DEBUG: Seat seat0: Session stopped
[+0.01s] DEBUG: Seat seat0: Stopping display server, no sessions require it
[+0.01s] DEBUG: Seat seat0: Stopping
[+0.01s] DEBUG: Seat seat0: Stopped
[+0.01s] DEBUG: Failed to start seat: seat0

Potential security issue: bypassing LightDM lockscreen through secondary display.

I have found that if i have my laptop in sleepmode, i can wake it up by lifting up the laptop-lid and then if i connect a monitor through HDMI when it is in the process of waking up the secondary screen will be fully accessible by mouse.
I can switch (Browser) tabs, access the desktop and basically look at anything that is currently open on the display connected through the HMDI.

Desktop cannot be connected until display of remote server connected.

I've detected this on computers equipped with Nvidia display cards.

OS System: Ubuntu Server 16.04 LTS
GPU: Nvidia GTX 1080Ti

The problem looks like this, if I startup the remote server without a display connected, the lightdm failed to start dues to no screen connect to it.
It was partly dues to gpumanager or xorg. so is there any solution to this?

dm-tool failing assertions noisily .... (GLib-CRITICAL) ... 'is_valid_heap_iter (iter)' fails

I'll let this trace speak for itself:

$ dm-tool --version
lightdm 1.26.0
$ dm-tool list-seats                                       
Seat0
  CanSwitch=true
  HasGuestAccount=false
  Session2
    UserName='bernd2'
  Session0
    UserName='bernd'

(process:10106): GLib-CRITICAL **: 15:40:02.408: g_variant_iter_free: assertion 'is_valid_heap_iter (iter)' failed

(process:10106): GLib-CRITICAL **: 15:40:02.409: g_variant_iter_free: assertion 'is_valid_heap_iter (iter)' failed

and for the record inxi reports:

System:    Kernel: 4.15.0-32-generic x86_64 bits: 64 Console: tty 14 Distro: Linux Mint 19 Tara
Machine:   Device: desktop System: ASUS product: All Series serial: N/A
           Mobo: ASUSTeK model: MAXIMUS VII HERO v: Rev 1.xx serial: N/A
           UEFI [Legacy]: American Megatrends v: 2401 date: 02/24/2015
CPU:       Quad core Intel Core i7-4790 (-MT-MCP-) cache: 8192 KB
           clock speeds: max: 4000 MHz 1: 1276 MHz 2: 1052 MHz 3: 1025 MHz 4: 1026 MHz
           5: 1043 MHz 6: 1031 MHz 7: 1053 MHz 8: 1047 MHz
Graphics:  Card: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
           Display Server: X.org 1.19.6 drivers: modesetting (unloaded: fbdev,vesa)
           tty size: 100x82 Advanced Data: N/A out of X
Audio:     Card-1 Intel Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller
           driver: snd_hda_intel
           Card-2 Intel 9 Series Family HD Audio Controller driver: snd_hda_intel
           Card-3 Logitech G930 driver: USB Audio
           Sound: Advanced Linux Sound Architecture v: k4.15.0-32-generic
Network:   Card-1: Intel Ethernet Connection (2) I218-V driver: e1000e
           IF: eno1 state: up speed: 100 Mbps duplex: full mac: 08:62:66:4a:31:5b
           Card-2: Belkin F7D2102 802.11n N300 Micro Wireless Adapter v3000 [Realtek RTL8192CU]
           driver: rtl8192cu
           IF: wlx08863bf3e29b state: N/A mac: N/A
Drives:    HDD Total Size: 3688.8GB (76.3% used)
           ID-1: /dev/sda model: KINGSTON_SV300S3 size: 240.1GB
           ID-2: /dev/sdb model: SAMSUNG_SSD_830 size: 128.0GB
           ID-3: /dev/sdc model: WDC_WD10EACS size: 1000.2GB
           ID-4: /dev/sdd model: Maxtor_6V320F0 size: 320.1GB
           ID-5: /dev/sde model: WDC_WD20EARX size: 2000.4GB
Partition: ID-1: / size: 188G used: 17G (10%) fs: ext4 dev: /dev/dm-0
           ID-2: /home size: 294G used: 126G (46%) fs: ext4 dev: /dev/sdd1
           ID-3: swap-1 size: 34.23GB used: 0.00GB (0%) fs: swap dev: /dev/dm-1
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 29.8C mobo: 27.8C
           Fan Speeds (in rpm): cpu: 0
Info:      Processes: 475 Uptime: 11 days Memory: 17219.3/32044.4MB Init: systemd runlevel: 5
           Client: Shell (bash) inxi: 2.3.56

if that helps diagnose.

Update launch and freedesktop pages with new project home?

The project development seem to have moved to GitHub, however there's no mention of that on either

https://launchpad.net/lightdm
or
https://www.freedesktop.org/wiki/Software/LightDM/

People are confused because they don't see 1.25.1 release on LP and consider it a fake. Here, for example: https://repology.org/metapackage/lightdm/report

When will 1.25.2-0ubuntu1 be available in bionic?

@robert-ancell I am hoping to test the fixes for the updated user background settings as discussed here: linuxmint/slick-greeter#94

At this point I think I am still having issues with the service not being found that may be solved by 1.25.2:
No such interface 'org.freedesktop.DisplayManager.AccountsService'

I am not certain as to when 1.25.2-0ubuntu1 will make it to the bionic repos: are you able to help me understand when this will get to them? thanks...

extremely slow or impossible to use mouse with windows and desktop icons in VirtualBox guest

Hi,
I originally reported this here:
https://bugzilla.redhat.com/show_bug.cgi?id=1600175
and was asked to upstream it with you.

With a recent update of lightdm, mouse control moving windows, accessing window controls, and also accessing desktop icons, has become non-responsive. Once in a while, the system reacts to the mouse again, only to become non-responsive again quite quickly.

Steps to Reproduce:

1. Boot into Fedora.
2. Launch default terminal from panel (tilix or mate-terminal) or any other program.
3. Try to move the window with the mouse, or resize it, or access its right-click menu items, or access desktop icons.

Actual results:
Window can't be moved with the mouse. Window can't be made fullscreen (double-click on title bar, or use of the respective title bar button). Can't copy/paste with the mouse. Can't access desktop icons (they don't even change their shade anymore when I hover the mouse over).

After a few minutes (?), most actions work again. Just for a short time though, then the whole desktop is stuck again. (See additional info below.)

This is all in Fedora (F27 and F28) VirtualBox guests, running on a Windows 10 host.

Expected results:
Snappy reaction to mouse actions.

Additional info:
This is all in Fedora (F27 and F28) VirtualBox guests, running on a Windows 10 host. This happens both with and without VirtualBox's 3D acceleration support.

Interestingly, I can, most of the time, still fluidly control the icons and menus from/in the panel.

When stuck, I can't use right mouse actions (such as copy or paste) either, while pasting with Shift+Insert works.

As far as I could track it down, it happened with Fedora's update from lightdm-1.25.2-1 to 1.26.0-1. I am aware that your upstream code contains no changes between these versions. ;-) The latter Fedora package includes three patches from your upstream commits though:

733d175
9cfe924
149d9d7

I have observed this behavior both on an F27 Cinnamon spin, and on an F28 Mate-Compiz spin. (These are special Fedora package compilations which concentrate on different desktops than the default Gnome3.) I tracked this down to lightdm, as that is the one obvious component both spins share, and it was a component which was updated just before the issue started occurring on each system. When I reverted this component to lightdm-1.25.2-1.fc28 (incl. lightdm-gobject), everything was fine again.

If you can't reproduce, I'd like a hint as to into which logs (or similar) I can look, whether I shall attach strace or something, or such. I'd like to avoid recompiling right now because it's a bit of a hassle, even though I consider myself good at it. ;-)

Thanks!

x11vnc was unable to open the X DISPLAY: ":0", it cannot continue.

For some reason, lightdm uses the wrong magic cookie when connecting to the main X11 server. any ideas why?

[+10.97s] DEBUG: Seat vnc0: Loading properties from config section Seat:*
[+10.97s] DEBUG: Seat vnc0: Starting
[+10.97s] DEBUG: Seat vnc0: Creating greeter session
[+10.97s] DEBUG: Seat vnc0: Creating display server of type x
[+10.97s] DEBUG: XServer 1: Logging to /var/log/lightdm/x-1.log
[+10.97s] DEBUG: XServer 1: Writing X server authority to /run/lightdm/root/:1
[+10.97s] DEBUG: XServer 1: Launching X Server
[+10.97s] DEBUG: Launching process 18078: /usr/bin/x11vnc :1 -auth /run/lightdm/root/:1 -nolisten tcp -inetd -geometry 1024x768 -depth 8
[+10.97s] DEBUG: XServer 1: Waiting for ready signal from X server :1
[+10.97s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat1
[+14.99s] DEBUG: Process 18078 exited with return value 1
[+14.99s] DEBUG: XServer 1: X server stopped
[+14.99s] DEBUG: XServer 1: Removing X server authority /run/lightdm/root/:1
[+14.99s] DEBUG: Seat vnc0: Display server stopped
[+14.99s] DEBUG: Seat vnc0: Stopping session
[+14.99s] DEBUG: Seat vnc0: Session stopped
[+14.99s] DEBUG: Seat vnc0: Stopping display server, no sessions require it
[+14.99s] DEBUG: Seat vnc0: Stopping; greeter display server failed to start
[+14.99s] DEBUG: Seat vnc0: Stopping
[+14.99s] DEBUG: Seat vnc0: Stopped

LightDM doesn't close session on logout, leaving user services running

This happens in many distributions and in many desktop environments.
If you login using lightdm and then logout:

• loginctl shows that the user session is still running.
• all processes started by systemd --user are still running, for example dbus-daemon, dconf, gvfsd, bluetooth...

The correct thing to do would be for LightDM to close the PAM session so that systemd then stops all those services. Otherwise problems like "could not acquire bus sesson" are caused on re-logins and I've even seen dconf database corruption in 2 cases, which may be related.

Tested in: Ubuntu MATE 18.04.1, Debian Stretch, lubuntu-18.04.1-desktop-i386.iso, xubuntu-18.04.1-desktop-i386.iso, Fedora-MATE_Compiz-Live-x86_64-28-1.1.iso

To reproduce just boot into any live CD or distro that uses lightdm, logout, switch to vt2, login, run ps -ef and see that the user services are still running even hours later.

This doesn't happen in Ubuntu 16.04.5, so it might be a regression.
And of course if one replaces lightdm with gdm, it doesn't happen in any of the above test cases either.

wayland-session is not checked for default session

It appears that /usr/share/wayland-sessions is not checked for the default session in ~/.dmrc -- the selected session always defaults to the first session after using a wayland session.

How to force LightDM to startup on a container (LXC) system?

I'm having an issue where I need to start xorg and Xubuntu at the startup of an LXC container. I installed Xubuntu form a base Ubuntu Proxmox container installation via tasksel install xubuntu-desktop. I then was able to install x2go (apt install x2goserver) and start sessions for users just fine.

LightDM is installed, but it doesn't seem to want to start at startup. I figure lightdm is the right way to go since I would be able to use autologin and then execute a graphical app I need to start at system startup, but it seems like I'm missing some piece of the puzzle that get's lightdm to start at system startup on a container.

Is there any way to get lightdm to start on a system that doesn't have a graphical terminal available by default such as is the case it seems with containers?

Move website from freedesktop.org

Since the code for LightDM was never hosted on freedesktop.org, it would be good if LightDM could host its own website instead. We would of course be happy to set up any redirects as needed.

Allow different PAM configuration for Loging in and Unlocking an existing session

I have configured my system to require both a password and a plugged in Yubikey in order to authenticate.

It would be nice if I could configure lightdm in such a way that when unlocking an existing session, either one of the Yubikey or a password is sufficient in order to authenticate. This will require an additional pam configuration file and associated configuration option, perhaps called pam-unlock-service.

As I type this I realise that this might be something for the locker to handle and not lightdm itself. Does lightdm even know or care that a session is being unlocked or started?

Thanks

lightdm fails

Just a heads up..
issue reported on stackexchange...
https://stackoverflow.com/a/53094308/10588731

quick details:
lightdm fails to start. "enable" gives fine message, but... it fails to start. "start" crashed my Xorg server immediately.. (It put me back out to a console completely and I had to load Xorg from tty2)...

my system: LXDE, Arch Linux ARMv7, Linux kernel 4.19
archlinuxarm.org repo, package: extra/lightdm 1:1.28.0-1 [installed]

Suggest: strip the blank character in username text box

When I wake up the computer, generally using the space key, and lightdm back to capture the keystroke and the spaces will be automatically entered into the user name text box, lead to validate a pass-through, however, if the user name text box automatically before and after the blank character deletion, it will more convenient. Or if the input is not captured before the screen wakes up, it's okay to consider this suggestion.