Description of problem: An update to lightdm-gtk-1.5.1-1.fc19, from lightdm-gtk-1.5.0-1.fc19, drops 'logo=...' line from lightdm-gtk-greeter.conf. That could be taken as a design "feature", even if quite unfortunate one, if not that detail that a sort of a "logo" is displayed by a greeter anyway. Only this is a generic "practice target" one instead of something more appealing. That is the case both with a "logo=..." line absent and with such line copied from the previous lightdm-gtk-greeter.conf. Not attempting to display _anything_ would be preferable in this bad situation; even better - getting configurable logo back. Version-Release number of selected component (if applicable): lightdm-gtk-1.5.1-1.fc19 How reproducible: always
aye, that option is gone from lightdm-gtk 1.5.1. Instead it tries to load the user avatar of the selected user. You can set it in the user management tools of your DE or whatever you use (I tried KDE systemsettings). So far so good - it's not a bug. However I encountered 2 issues: 1. lightdm can't access the location of the avatar /home/user/.face -> fallback to default icon 2. (maybe specific to KDE): lightdm expects '.face' but KDE creates '.face.icon' -> again default icon Probably we could run lightdm as root to access the home dir, though that would compromise the security concept :/
(In reply to comment #1) > Instead it tries to load > the user avatar of the selected user. What this is supposed to mean before any user is selected at all? As it happens some installation have multiple user accounts. What about a very sane situation when you have 'greeter-hide-users=true' in /etc/lightdm/lightdm.conf? There are sites where this, or equivalent, is a non-negotiable requirement. > 1. lightdm can't access the location of the avatar /home/user/.face > -> fallback to default icon Not that surprising. I have yet to see a "real life" installation where such thing like ~/.face even exist. Fallback is ok, only a choice of a default icon is all wet. The best would be to have a configurable "fallback".
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
As I understand it, this indeed was an upstream design choice, and as such, is not something we're willing to modify at this point. Feel free to engage lightdm upstream if you want to pursue the issue further.
(In reply to comment #4) > As I understand it, this indeed was an upstream design choice, and as such, > is not something we're willing to modify at this point. It looks like that to avoid these troubles one can use lightdm-gtk-1.3.1 which so far works fine even with the current rawhide.
(In reply to Rex Dieter from comment #4) > As I understand it, this indeed was an upstream design choice, In case somebody else will try to replace a default pictue: a recipe given in a comment 4 of https://bbs.archlinux.org/viewtopic.php?id=167228, with "obvious layout adjustments", works. Scaling your picture does not seem to be necessary as lightdm-gtk-greeter seems to be doing its own rescaling anyway. Also a 'gtk-update-icon-cache' can be skipped although it may help. Before doing all that work one may want to put 'icon-theme-name=HighContrast' in /etc/lightdm/lightdm-gtk-greeter.conf (assuming that /usr/share/icons/HighContrast/48x48/status/avatar-default.png is really in place) and restart lightdm.service to check that this has desired effects on a give installation.
Oh! lightdm-gtk-1.7.0 introduced configurable 'default-user-image' but I am not sure when and how this is supposed to work. I do not see neither errors nor effects.