Please allow to choose between AccountsService and ${HOME}/.dmrc

I second that. If LightDM strives to be a universal login manager, it should support standard configuration, not only gnome-specific services.

+1, but note that the same bug also affects other users of AccountsService (e.g., gdm) so perhaps it should be addressed in the accountsservice package, or by providing a reusable wrapper around libaccountsservice and any alternatives one may wish to support. $HOME/.dmrc is one option but maybe some sites would prefer an LDAP-based solution.

Well, I don't think the GNOME people are going to change policy. They're the ones who came up with AccountsService, so they're certainly not going to change it back to a state which allows you to use the old dmrc mechanism. So I didn't even bother mentioning gdm (they don't even care that users complain you cannot set the login language anymore, the bug report just remains open).

lightdm is the only universal display manager we have (besides good old gdm 2.20), so I put all my hopes into it. I wrote a few small patches to fix some minor issues with lightdm and I actually tried implementing this feature to choose between dmrc and AccountsService, but the lightdm code is quite messy in that regard. There are, for example, two identical functions to read from dmrcs: dmrc_read and read_dmrc, one is part of liblightdm, one is part of lightdm. lightdm-gtk-greeter uses the library implementation of it.

It's really confusing.

Adrian

Situation is worsened in 1.5.3. Lightdm now completely ignores .dmrc

I'm using lightdm 1.8.5 and AccountsService 0.6.35. Every time I log in, lightdm creates ~/.dmrc.

[+14.57s] DEBUG: Session pid=358: User carl authorized
[+14.57s] DEBUG: Session pid=358: Greeter requests session openbox
[+14.59s] DEBUG: Writing /home/carl/.dmrc

I noticed that AccountsService contains the same information.

$ cat ~/.dmrc
[Desktop]
Session=openbox
$ cat /var/lib/AccountsService/users/carl
[User]
XSession=openbox
SystemAccount=false

If using AccountsService, lightdm should not create ~/.dmrc.

tested lighdm 1.9.6 with gtk greeter 1.7.0
~/.dmrc is written almost correctly, in my case it contains: "Language=ru_RU.utf8@ISO" (utf8 in lower case, not sure if this affects something)

But ~/.dmrc is not being read anyhow on choosing user in greeter (default values appear in selectors)
And chosen values are not applied when session start.

tested lightdm 1.9.9 with gtk greeter 1.8.2.
There is an improvement!
~/.dmrc is being read by greeter, selectors for language and session are presented with correct values.
Language parameter is being written to ~/.dmrc, but not exported into environment. System default locale is still used.
Session parameter writing is confusing. Sometimes it is written, sometimes it is not. I thought it mixes default session with specific session which is currently default, but I failed to find reproducible pattern.
Chosen session seems to be applied regardless of whether it was written to ~/.dmrc

I made a workaround for locale by creating xsession snippet /etc/X11/Xsession.d/21-lightdm-locale-fix with content:
------------------------------------------
# get locale from .dmrc if lightdm is used
if pidof lightdm >/dev/null 2>/dev/null
then
 LANG="$(cat "$HOME/.dmrc" | grep 'Language=' | tail -n 1 | cut -d '=' -f 2- | sed 's/utf/UTF/g')"
 LANGUAGE="$(echo "$LANG" | cut -d '.' -f 1):$(echo "$LANG" | cut -d '.' -f 1 | cut -d '_' -f 1)"
 export LANG
 export LANGUAGE
fi
------------------------------------------

> Chosen session seems to be applied regardless of whether it was written to ~/.dmrc

I just had another go at this using lightdm 1.12 and lightdm-gtk-greeter from Debian experimental. Indeed, the ~/.dmrc file is now written again but, like you say, lightdm is completely ignoring what was previously written to ~/.dmrc. Even worse, the settings from the previously logged in user remain such that if your preferred session is KDE and the previous user used MATE, your session will automatically set to MATE instead to KDE.

It's sad that this still hasn't been properly addressed as it makes lightdm pretty much unusable in corporate environments where people don't have a personal workstation, e.g. a university or school.

With old versions of gdm (<= 2.20), session management worked like a charm in corporate environments. There was a default session and language that was started when a new user logged in - regardless on which machine on the network - when no ~/.dmrc was found.

If the user then decided they would want a different desktop environment/window manager or language, they could change these values once during login and gdm would write them to ~/.dmrc and restore these settings on subsequent logins - again, completely independent what machine on the network was used.

Then someone had the genius idea to completely shove the ~/.dmrc concept and came up with the ingenious "accounts-service-daemon" while completely ignoring the fact that people might change their workstation in a corporate environment as this daemon is constrained to local use.

Thus, when a user set their preferred default session and language, it was rather like gambling whether their preferred session and language would be loaded when logging the next time as it depended on the fact whether they had used this machine before and whether they actually already set their current preferred session and language on this machine.

The current version of lightdm does not improve this situation really. It does indeed write the settings to ~/.dmrc, but never reads them which makes the whole thing pointless. To be honest, I am rather surprised that this isn't handled with higher priority. This is a fundamental and very annoying problem that really needs to be fixed.

In my opinion, a display manager should always be able to query a user for their preferred language and desktop environment/window manager before logging in, then save these values in a decentral location, e.g. the home directory, then restore these preferred values at next login.

GDM3 has similar problems in this regard and I am surprised that RedHat hasn't addressed these issues yet. But I guess they will postpone it as long as possible until some "strategic customer" complains such that the GDM3 developers fix the problem - which they have been ignoring for so long - within 1-2 weeks (they did exactly that with a serious bug in gvfs).

Adrian