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.
(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.
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?
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/
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.
Probably also related to the issue I described in Bug #582016
/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 .