Added code to lightdm-wrapper to make it source profile, .xprofile, .Xresources, and scripts in /etc/X11/xinit/xintrc.d before staring an xsession. Now these files will be sourced by all three display managers in Solus repo: gdm, sddm, and lightdm.
Details
Details
- Reviewers
JoshStrobl - Group Reviewers
Triage Team - Maniphest Tasks
- T9049: No easy way for user to customize environment variables for X sessions
T8859: Lightdm should source $HOME/.xprofile, if it exists, by default - Commits
- R1955:ee7c66789ce7: Make lightdm source .profile and .xprofile. Resolves T8859.
Installed this version on both Budgie and MATE version. They both pick up environment variable definitions in my .profile
Diff Detail
Diff Detail
- Repository
- R1955 lightdm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Did you test .Xmodmap and .Xresources in the GNOME (gdm) and KDE (sddm) spins?
I'm happy to endorse this, but I'd prefer if we had the exact same behaviour across all four DEs in the presence of local configuration files (and if we can't have that, at least document why according to upstream).
Would you be willing to open a task and drive the testing of this and reference necessary patches in that task (including this one)?
I realise that this can seem like an exercise in moving the goalposts -- please bear with me as I honestly think following the principle of least astonishment here is a good thing in this area.
Comment Actions
@ermo Yeah I actually looked into the xsession startup script shiped with gdm and sddm. They both source .Xresources along with .profile and .xprofile. lightdm-wrapper will do the same if this patch gets merged.
.Xmodmap is a bit more complicated. sddm does not load it by default. gdm loads it, however, similar to what happend to budgie, gnome-session actually overwrites keymaps later so all changes in .Xmodmap will be lost. In short, .Xmodmap will take effect in MATE. For the other three desktop environments, there are workarounds. sddm users can add xmodmap ~.Xmodmap to ~/.xprofile as that file gets picked up by sddm and that is also a standard file for stuff like setting keyboard and Xresources. For budgie and gnome users, they need to create an autostart script for loading Xmodmap after gnome-session starts.
I think this is the best we can do, as different display managers have different defaults and also work differently. I guess it is reasonable to assume that user of a specific DM will have some knowledge of that DM if they want to do something like setting their own key maps.
Comment Actions
Remove code which sources key maps and xsessions. Only source .profile, .xprofile and .Xresources.
| files/lightdm-wrapper | ||
|---|---|---|
| 8 | Why are we no longer loading our vendor-provided config. That is a violation of statelessness. Is it because you symlinked the /etc/profile in the other patch (which we should not be doing)? | |
| files/lightdm-wrapper | ||
|---|---|---|
| 8 | The vendor-provided config (/usr/share/defaults/etc/profile is still sourced here since /etc/profile is a symlink to it and is sourced here. I didn't create the symlink /etc/profile. It is created by the bash package. I created the symlink /etc/xprofile in the other patch to mimic the relations between /etc/profile and /usr/share/defaults/etc/profile. I guess we can modify the patch to source "/usr/share/defaults/etc/profile" and "/usr/share/defaults/etc/xprofile" directly instead of doing a symlink in /etc. | |
| files/lightdm-wrapper | ||
|---|---|---|
| 8 |
That would be a more ideal usecase. I'll admit bash isn't fully in spec. | |
| files/lightdm-wrapper | ||
|---|---|---|
| 8 | @JoshStrobl I replied in D8989 about sourcing /etc/xprofile instead of /usr/share/defaults/etc/xprofile. This is to make lightdm behave the same way as gdm and sddm. The latter two look for /etc/xprofile by default. | |
Comment Actions
@JoshStrobl I made lightdm source the vendor-provided xprofile and removed the symlink of /etc/xprofile to /usr/share/defaults/etc/xprofile in D8989 for a stateless setup.
Comment Actions
LGTM, I'll get gdm and sddm patched tomorrow and get this stuff landed. Nice work all around!
Comment Actions
Just a heads up, I'm going to be deferring the landing of this until sometime this weekend. I'll still patch GDM and SDDM in preparation, but I'm not confident there will be enough community testing between landing and sync tomorrow, and I wouldn't want to risk potentially breaking login capabilities.