SDDM игнорирует пользовательскую конфигурацию (/etc/sddm.conf)
Я пытался настроить новую тему для SDDM, но независимо от изменений, которые я делаю в окне настроек или вручную в /etc/sddm.conf, встроенный приветствующий по умолчанию остается тем же, который я получаю при загрузке, и экран блокировки по умолчанию все еще тот, который я получаю после сна. Я на Fedora 28, KDE 5.13.5, ядро 4.19, пытаюсь установить Chili в качестве моего экрана блокировки и приветствия. Установил его через графический интерфейс настройки KDE SDDM, проверил каталог установки и все там, где оно должно быть. Вот мой /etc/sddm.conf:
│ File: sddm.conf
│________________________
1 │ [Autologin]
2 │ Relogin=false
3 │ Session=plasma.desktop
4 │ User=renard
5 │
6 │ [General]
7 │ Numlock=on
8 │ HaltCommand=
9 │ RebootCommand=
10 │
11 │ [Theme]
12 │ Current=plasma-chili
13 │ CursorTheme=Adwaita
14 │
15 │ [Users]
16 │ MaximumUid=65000
17 │ MinimumUid=1000
Также тема работает просто отлично при использовании sddm-greeter --test-mode --theme /usr/share/sddm/themes/plasma-chili/, Я не могу получить доступ к /var/lib/ssdm, что кажется нормальным, и у меня нигде нет папки sddm.conf.d. Еще более озадачивает то, что это проблема, о которой я немного читал, прежде чем приехать сюда, и я видел людей с 2014 года, у которых были такие же проблемы, но я нигде не мог найти решение.
0 ответов
Это фактически не игнорирует это - или скорее: это сложно.
У меня была такая же проблема, поэтому я проверил, как это работает:
В исходном файле sddm daemon/PowerManager.cpp в списке несколько бэкэндов, как следует обрабатывать нажатие кнопки выключения или перезапуска, и только один из них использует HaltCommand от /etc/sddm.conf,
Для shutdown/HaltCommand соответствующей функцией является powerOff().
Итак, что же на самом деле делает powerOff ()?
/************************************************/
/* POWER MANAGER BACKEND */
/************************************************/
virtual void powerOff() const = 0;
/**********************************************/
/* UPOWER BACKEND */
/**********************************************/
// comment from me: some reference to org.freedesktop.UPower"
void powerOff() const {
QProcess::execute(mainConfig.HaltCommand.get()); // <---------------
}
/**********************************************/
/* LOGIN1 && ConsoleKit2 BACKEND */
/**********************************************/
void powerOff() const {
m_interface->call(QStringLiteral("PowerOff"), true);
}
/**********************************************/
/* POWER MANAGER */
/**********************************************/
void PowerManager::powerOff() const {
if (daemonApp->testing())
return;
for (PowerManagerBackend *backend: m_backends) {
if (backend->capabilities() & Capability::PowerOff) {
backend->powerOff();
break;
}
}
}
sddm.conf читается в mainConfig, так mainConfig.HaltCommand держит эту команду от /etc/sddm.conf, который вы так жаждете выполнить, когда нажимаете кнопку на экране.
Я не знаю, если HaltCommand в /etc/fstab это функция в процессе, которая в конечном итоге будет реализована в каждом бэкэнде, или документация будет повреждена, так как в ней не упоминается, что она будет работать только с конкретным бэкэндом...
Я не рассматривал весь код, так что даже возможно, что предполагается, что если HaltCommand представлен в sddm.conf, то независимо от серверной части, эта команда должна быть выполнена, только они не смогли ее реализовать, или они забыли это со временем.
Я использую Debian Stretch с systemd, поэтому я почти уверен, что у меня есть серверная часть LOGIN1 && ConsoleKit2. Пока это не идеально, по крайней мере, теперь я знаю, что я не испортил конфигурацию, скорее, то, что я хотел, не может быть сделано с настройкой sddm...
ПРИМЕЧАНИЕ: я использовал код sddm-0.14.0 из источников Debian для моего исследования. Я проверил последние источники на
SRC / демон / PowerManager.cpp
И, похоже, этот код не изменился.
Хотя я не проверял (даже не уверен, как это сделать), похоже, если переключиться на UPower бэкэнд, вы получите HaltCommand функциональность.
Также, как мне кажется, пара ifво всех бэкэндах можно было бы использовать HaltCommandвсякий раз, когда он изменяется от значения по умолчанию пользователем.
Пока я на этом, проверил, что происходит с Current Элемент конфигурации в последнем источнике. Кажется, это должно работать:
Вот конфиг [theme], как его видит код:
Section(Theme,
Entry(ThemeDir, QString, _S(DATA_INSTALL_DIR "/themes"), _S("Theme directory path"));
Entry(Current, QString, _S(""), _S("Current theme name"));
Entry(FacesDir, QString, _S(DATA_INSTALL_DIR "/faces"), _S("Global directory for user avatars\n"
"The files should be named <username>.face.icon"));
Entry(CursorTheme, QString, QString(), _S("Cursor theme used in the greeter"));
Entry(EnableAvatars, bool, true, _S("Enable display of custom user avatars"));
Entry(DisableAvatarsThreshold,int, 7, _S("Number of users to use as threshold\n"
"above which avatars are disabled\n"
"unless explicitly enabled with EnableAvatars"));
);
Это та часть, где тема "Current" фактически анализируется и проверяется. Похоже, она должна дать вам предупреждение - возможно, в /var/log/sddm.log - если она не найдет ее:
QString Display::findGreeterTheme() const {
QString themeName = mainConfig.Theme.Current.get();
// an unconfigured theme means the user wants to load the
// default theme from the resources
if (themeName.isEmpty())
return QString();
QDir dir(mainConfig.Theme.ThemeDir.get());
// return the default theme if it exists
if (dir.exists(themeName))
return dir.absoluteFilePath(themeName);
// otherwise use the embedded theme
qWarning() << "The configured theme" << themeName << "doesn't exist, using the embedded theme instead";
return QString();
}
Я немного растерялся здесь, но, похоже, если тема найдена в пути, то она ищет файлы конфигурации темы, либо в themePath/metadata.desktop, или как-то вы можете настроить пользовательский именованный файл конфигурации темы. Я думаю themePath является [theme] ThemeDir в sddm.conf,
void Greeter::setTheme(const QString &theme) {
m_themePath = theme;
if (theme.isEmpty()) {
m_metadata->setTo(QString());
m_themeConfig->setTo(QString());
} else {
const QString path = QStringLiteral("%1/metadata.desktop").arg(m_themePath);
m_metadata->setTo(path);
QString configFile = QStringLiteral("%1/%2").arg(m_themePath).arg(m_metadata->configFile());
m_themeConfig->setTo(configFile);
}
}
В общем, вы можете попытаться изучить (от решения проблем до обходного пути):
- ваша тема на пути? попробуйте дать абсолютный путь! проверять
/var/log/sddm.logа также/var/log/syslogза это"The configured theme" << themeName << "doesn't exist, using the embedded theme instead"сообщение об ошибке! - попробуйте добавить
themeDir - у вашей темы есть
metadata.desktopфайл? если нет, попробуйте переименовать / символьную ссылку на файл, который, как представляется, может быть версией его темы sddm --example-configпечатает ваш текущий конфиг; если это всплывает[theme] Currentскопируйте / вставьте ссылку на вашу тему в это место (возможно, сделайте резервную копию оригинала) и посмотрите, что произойдет
ПРИМЕЧАНИЕ. Я не видел в коде больше условий для использования темы, кроме "существует ли этот файл?" - что не значит, что их там нет. Тем не менее, я видел, что тема используется для создания пользовательских значков, лица пользователя, чего угодно, поэтому возможно, что он потерпит неудачу из-за нехватки ресурсов в будущем - я сомневаюсь, что это так, но это возможно.
Хотя это не полный ответ, я уже посмотрел код, поэтому попробовал, надеюсь, я нашел то, что вы можете использовать для решения проблемы!