Bug 571358 – x11-misc/sddm: Protect '/usr/share/sddm/scripts/Xsetup' through etc-update mechanism

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Matthias Nagel 2016-01-09 11:48:10 UTC]

I have a very high-dpi display and I use the "force font dpi" from KDE in order to get a reasonable font scaling.

In order to have a unified experience between the KDE lock-screen and SDDM the same settings must be set for SDDM. Unfortunately, SDDM uses its own "Xsetup" script that resides in '/usr/share/sddm/scripts/'. (SDDM does not use the global Xsetup file inside '/etc/X11').

My '/usr/share/sddm/scripts/Xsetup' file looks like that:

echo 'Xft.dpi: 120' | xrdb -override
echo 'Xft.antialias: true' | xrdb -override
echo 'Xft.rgba: rgb' | xrdb -override
echo 'Xft.hinting: true' | xrdb -override
echo 'Xft.hintstyle: hintslight' | xrdb -override

However, the annoying part is that this file gets silently overwritten every time SDDM is upgraded, re-emerge and so on.

Proposed solution:

(a) (Maybe difficult) Patch SDDM such that it honors the global settings found in '/etc/X11/'. Of course, this might be difficult to achieve, because the final global settings are a merge of different files found in various sub-directories of '/etc/X11'. However, this would provide the most user-friendly experience, because this way the settings used by SDDM are always in sync with the rest of the system.

(b) (Easy) If (a) is too difficult, then at least protect '/usr/share/sddm/scripts/Xsetup' via the etc-update mechanism such that the carefully hand-crafted and manually compiled settings are not overwritten without interaction.

Reproducible: Always

[Comment 1 Jauhien Piatlicki (RETIRED) 2016-01-11 22:27:35 UTC]

Thanks for reporting. I'll look at it. Could you, please, also file an upstream bug on sddm issue tracker asking them to read settings from /etc/X11?

[Comment 2 groepaz 2016-04-12 07:55:57 UTC]

for the same reason, this script is also required to get a different keyboard layout than the default US one - see for example: https://fitzcarraldoblog.wordpress.com/2015/12/03/sddm-keyboard-layout/

[Comment 3 mikey 2016-05-15 11:23:56 UTC]

I cofirm this bug. Looks like pretty serious problem for me. It prevents using nvidia-drivers with optimus enabled every time when new version of sddm is installed. Also it is hard hard to debug, as one usually thinks that everything is configured properly and blames new version of nvidia-drivers for disfunctional X.

[Comment 4 Tobias Leupold 2016-07-04 15:10:25 UTC]

Probably also related to the issue I described in Bug #582016

[Comment 5 Soren Harward 2017-02-01 14:19:31 UTC]

/etc/sddm.conf has configuration directives for where Xsetup, Xstop and Xsession files are looked for.  If simply protecting /usr/share/sddm/scripts under the etc-update mechanism isn't satisfactory, then another option might be to patch/rewrite the default config file so that it looks for these things under a subdir of /etc, rather than somewhere in /usr/share/sddm .

[Comment 6 Markus Wernig 2021-07-03 20:11:34 UTC]

This bug report is ancient, but the problem is still not fixed.

Everything under /usr/share/sddm/scripts gets overwritten whenever x11-misc/sddm is updated, which happens every 1-2 months.

/usr/share/sddm/scripts/Xsetup and
/usr/share/sddm/scripts/Xstop

are obviousyl both designed to be user-editable scripts (they are installed in a version that contains only comments).

So clearly they should be protected from being overwritten during upgrades.

It is more than just annoying to have to restore them every couple of weeks.

Please look into this bug again.

[Comment 7 Sam James 2021-07-04 05:58:15 UTC]

(In reply to Markus Wernig from comment #6)
> This bug report is ancient, but the problem is still not fixed.
> 
> Everything under /usr/share/sddm/scripts gets overwritten whenever
> x11-misc/sddm is updated, which happens every 1-2 months.
> 
> /usr/share/sddm/scripts/Xsetup and
> /usr/share/sddm/scripts/Xstop
> 
> are obviousyl both designed to be user-editable scripts (they are installed
> in a version that contains only comments).
> 
> So clearly they should be protected from being overwritten during upgrades.
> 
> It is more than just annoying to have to restore them every couple of weeks.
> 
> Please look into this bug again.

These things are usually configurable and are in /usr/share/ as examples. Typically, you'd move them to /etc and modify there.

https://askubuntu.com/questions/789742/sddm-xsetup-location suggests you can configure the location.

[Comment 8 Markus Wernig 2021-07-04 10:09:14 UTC]

Thanks for picking this up again.

Installing my versions of the scripts into /usr/local/bin and referencing them in /etc/sddm.conf took care of the overwriting issue.

I still think that scripts that are meant to be modified should not be overwritten silently (and the default configuration points to them, so people are likely to modify them directly, instead of copy, modify and change sddm.conf).

If they are to be considered sample scripts (valid point), it should say so in the script. Suggestion for Xsetup:

#!/bin/sh
# Xsetup - run as root before the login dialog appears
#
# This file is installed as an example only. If you need to modify it
# copy it to another location (eg. /usr/local/bin) and update 
# the DisplayCommand setting in /etc/sddm.conf to the new location. 

And the default config in sddm.conf should probably not point to them.
But I see how this is basically an upstream issue.

[Comment 9 Markus Wernig 2021-07-05 13:58:29 UTC]

On second thought, I don't think it's an upstream issue.

If the sddm developers consider these files only examples, the files should be copied to a regular system location during installation, and that location should be referenced in /etc/sddm.conf

eg:

/etc/sddm.d/Xsetup
/etc/sddm.d/Xstop
/etc/sddm.d/Xsession
/etc/sddm.d/wayland-session

and /etc/sddm.conf

[X11]
DisplayCommand=/etc/sddm.d/Xsetup
DisplayStopCommand=/etc/sddm.d/Xstop
SessionCommand=/etc/sddm.d/Xsession

[Wayland]
SessionCommand=/etc/sddm.d/wayland-session

Plus the comment in the sample files under /usr/share/sddm/scripts/

[Comment 10 Nowa Ammerlaan 2022-02-10 19:02:28 UTC]

As a workaround put:

CONFIG_PROTECT="/usr/share/sddm/scripts/Xsetup"

In /etc/portage/make.conf

[Comment 11 Matthias Nagel 2023-06-12 16:56:42 UTC]

(In reply to Markus Wernig from comment #9)
> On second thought, I don't think it's an upstream issue.
> 
> If the sddm developers consider these files only examples, the files should
> be copied to a regular system location during installation, and that
> location should be referenced in /etc/sddm.conf

I chose this solution and it works. Any chance that this will become the official fix and will be included into the ebuilds?

[Comment 12 Michael Jones 2023-08-09 02:18:14 UTC]

Ideally we can have the sddm package define a directory to source commands from, instead of a single file.

[Comment 13 msdobrescu 2023-08-24 12:56:41 UTC]

I have this problem too. Is there any conclusion?

[Comment 14 Nowa Ammerlaan 2023-08-24 13:06:26 UTC]

(In reply to msdobrescu from comment #13)
> I have this problem too. Is there any conclusion?

With >=x11-misc/sddm-0.20 you can use /etc/sddm.conf.d/ and set DisplayCommand= and DisplayStopCommand=. Basically what @Markus Wernig said above. For earlier versions you can use the CONFIG_PROTECT= workaround.

[Comment 15 msdobrescu 2023-08-24 20:06:34 UTC]

I have SDDM 0.18.1-r8, yet works to add the commands in /etc/sddm/Xsetup too.

[Comment 16 msdobrescu 2023-08-24 20:08:27 UTC]

Sorry, pressed the save button too soon.

I've made this by using /etc/sddm.conf:

[X11]
# Example scripts here: /usr/share/sddm/scripts/
DisplayCommand=/etc/sddm/Xsetup