Xresources not loaded

[atropos1789]

When I use X on my computer, I need to use the xresource "Xft.dpi" to adjust screen dpi. Using my shell to start xinit and then sourcing the files in my local xinitrc generally works fine, but as I am trying to adjust to this display manager I am finding that the Xft.dpi isn't being respected.

There is a file in my home dir as follows:

~/.Xresources
---
Xft.dpi: 144

When I launch this setup, it is not sourced:

/etc/lemurs/wms/i3
---
#! /bin/sh

picom &
dunst &
feh --no-fehbg --bg-fill ~/desktop-background &
exec i3

An inspection of the code leads me to believe that the file /etc/lemurs/xsetup.sh should run and directly source ~/.Xresources, which obviously is not happening.

[coastalwhite]

This is very strange. I had to use ~/.Xresources myself a while back, and it seemed to work just fine. I think it will be very difficult for me to reproduce this bug. Let me know if you figure out something

[juster-0]

Can confirm that xrdb for some reasons doesn't work. I even tried to run it "manually" in the script, but it hasn't helped.

/etc/lemurs/wms/awesome
--------------------------------
#!/usr/bin/env bash
xrdb -merge $HOME/.Xresources
exec awesome

It works perfectly if I use another DisplayManager or even with startx + /etc/lemurs/wms/awesome commands.

lemurs.log

[INFO  lemurs] Main lemurs logger is running
[INFO  lemurs] Switching to tty 2
[INFO  lemurs] UI booted up
[WARN  lemurs::post_login] Failed to read from the wayland folder '/etc/lemurs/wayland'
[INFO  lemurs::info_caching] Attempting to get a cached information from '/var/cache/lemurs'
[INFO  lemurs::info_caching] Read cache file and found environment 'awesome' and username 'test_username'
[INFO  lemurs::ui] Loading username 'test_username' from cache
[INFO  lemurs::ui] Loading environment 'awesome' from cache
[INFO  lemurs] Starting new session for 'test_username' in environment 'X { xinitrc_path: "/etc/lemurs/wms/awesome" }'
[INFO  lemurs::post_login::env_variables] Setting Display
[INFO  lemurs::env_container] Set environment variable 'DISPLAY' to ':0'
[INFO  lemurs::post_login::env_variables] Setting XDG Session Parameters
[INFO  lemurs::env_container] Set environment variable 'XDG_SESSION_CLASS' to 'user'
[INFO  lemurs::env_container] Set environment variable 'XDG_SESSION_TYPE' to 'x11'
[INFO  lemurs::auth] Login attempt for 'test_username'
[INFO  lemurs::auth::pam] Started opening session
[INFO  lemurs::auth::pam] Gotten Authenticator
[INFO  lemurs::auth::pam] Got handler
[INFO  lemurs::auth::pam] Validated account
[INFO  lemurs::auth::pam] Opened session
[INFO  lemurs::ui] Setting cached information
[INFO  lemurs::info_caching] Attempting to set cache
[INFO  lemurs::info_caching] Successfully set username in cache file
[INFO  lemurs::post_login::env_variables] Setting XDG Seat Variables
[INFO  lemurs::env_container] Skipped setting environment variable 'XDG_SEAT'. It was already set to 'seat0'
[INFO  lemurs::env_container] Skipped setting environment variable 'XDG_VTNR'. It was already set to '2'
[INFO  lemurs::post_login::env_variables] Setting XDG Session Variables
[INFO  lemurs::env_container] Skipped setting environment variable 'XDG_RUNTIME_DIR'. It was already set to '/run/user/1000'
[INFO  lemurs::env_container] Skipped setting environment variable 'XDG_SESSION_ID'. It was already set to 'c1'
[INFO  lemurs::post_login::env_variables] Setting Basic Environment Variables
[INFO  lemurs::env_container] Successfully changed working directory to /home/test_username!
[INFO  lemurs::env_container] Set environment variable 'HOME' to '/home/test_username'
[INFO  lemurs::env_container] Set environment variable 'SHELL' to '/bin/bash'
[INFO  lemurs::env_container] Set environment variable 'USER' to 'test_username'
[INFO  lemurs::env_container] Set environment variable 'LOGNAME' to 'test_username'
[INFO  lemurs::env_container] Set environment variable 'PATH' to '/usr/local/sbin:/usr/local/bin:/usr/bin'
[INFO  lemurs::post_login::env_variables] Setting XDG Common Paths
[INFO  lemurs::env_container] Set environment variable 'XDG_CONFIG_DIR' to '/home/test_username/.config'
[INFO  lemurs::env_container] Set environment variable 'XDG_CACHE_HOME' to '/home/test_username/.cache'
[INFO  lemurs::env_container] Set environment variable 'XDG_DATA_HOME' to '/home/test_username/.local/share'
[INFO  lemurs::env_container] Set environment variable 'XDG_STATE_HOME' to '/home/test_username/.local/state'
[INFO  lemurs::env_container] Set environment variable 'XDG_DATA_DIRS' to '/usr/local/share:/usr/share'
[INFO  lemurs::env_container] Set environment variable 'XDG_CONFIG_DIRS' to '/etc/xdg'
[INFO  lemurs::post_login] Setup client to log `stdout` and `stderr` to '/var/log/lemurs.client.log'
[INFO  lemurs::post_login] Starting X11 session
[INFO  lemurs::post_login::x] Start setup of X server
[INFO  lemurs::post_login::x] Filling `.Xauthority` file at `/home/test_username/.Xauthority`
[INFO  lemurs::env_container] Set environment variable 'XAUTHORITY' to '/home/test_username/.Xauthority'
[INFO  lemurs::post_login::x] Setup XServer to log `stdout` and `stderr` to '/var/log/lemurs.xorg.log'
[INFO  lemurs::post_login::x] It took X server 2002ms to start
[INFO  lemurs::post_login::x] X server is running
[INFO  lemurs::auth::utmpx] Adding UTMPX record
[INFO  lemurs::auth::utmpx] Added UTMPX record
[INFO  lemurs::env_container] Removing session environment variables
[INFO  lemurs::env_container] Reverting to environment before session
[INFO  lemurs::env_container] Reverting to working directory before session
[INFO  lemurs] Waiting for environment to terminate
[INFO  lemurs::post_login] Waiting for client to exit

$ lemurs --version
0.3.1
$ xrdb -version
xrdb 1.2.1
$ uname -a
Linux laptop 6.2.13-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 26 Apr 2023 20:50:14 +0000 x86_64 GNU/Linux

[coastalwhite]

I am able to reproduce the behavior. It is very strange. From what I see, some other DMs (e.g. Ly) have the same problem. I think the xsetup.sh script runs xrdb at the wrong time in the Xorg start. There is no real documentation on this so I will have a look what other DMs do to see whether that works.

[M1ndo]

@coastalwhite Can confirm i have faced the same problem today, had to revert to my previous display manager in order to get it working.

[AzraelSec]

Hello, nice to meet you all 👋🏻 I'd like to join this conversation and see if/how I can help, considering I'm actively using Lemurs and have to deal with this issue daily.

As a first attempt, I tried to apply a sleep between the X bootup and the xstart.sh execution (to ensure that no race condition was present), but It didn't work. I also verified that the script was actually executed after receiving the sigusr1 signal (to make sure that no weird exiting condition was causing the script to be executed before the X process exited). I also looked at how Ly handles that part of the startup, but It seems similar to Lemurs (unless the bug hides inside the complexity of our abstractions - the C code is pretty straightforward on this). I'll add more details as soon as I have time to dig dive.

[coastalwhite]

Thank you. I would love for someone to look further this. Personally, I got a bit lost on this issue when I looked into it before.

[ghost]

I had the same problem.
Adding xrdb -load ~/.Xresources & right before exec in the wms script works perfectly for me.

[kpa28-git]

I had the same problem. I added the following to the end of my ~.xinitrc (after all the background processes were kicked off): xrdb -load "$HOME/.Xresources". Maybe add it before everything if those background processes need something from ~/.Xresources in your .xinitrc.

I noticed /etc/lemurs/xsetup.sh only calls xrdb -merge $HOME/.Xresources (which didnt work to load in Xresources when added to .xinitrc, only -load worked -> wrong, see my last comment).

[coastalwhite]

Although, looking at the documentation for xrdb, I don't feel like it should matter. I feel like we are safe to replace -merge with the -load option by default. I will test it out and see what I find.

[kpa28-git]

Yeah I thought the same thing before trying both, it doesn't seem like it should matter.
My theory was wrong, both -load and -merge work fine. Sorry for the confusion. I was having a problem with another part of my setup I thought was related to Xresources loading, but I now know is not.

I just added this line from xsetup.sh at the end of my .xinitrc and everything works fine:
[ -f "$HOME/.Xresources" ] && xrdb -merge "$HOME/.Xresources"

[zacstewart]

I want to use Lemurs bit this issue is preventing me from doing so. I use .Xresources to set my screen DPI, and it's the only way that I've been able to use my external monitor with my HDPI laptop screen together. It's an annoying, but hard-won victory for this to work and I'm not keen on trying to find another solution in that regard. I want to use Lemurs so that I can finally have sleep/idle working properly since i3 doesn't report idle events for logind.

I've tried some of the fixes in the comments here, but none of them work. The following .xinitrc with startx has worked for a long time:

#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then
    xrdb -merge $sysresources
fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then
    xrdb -merge "$userresources"
fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

setxkbmap us -option ctrl:nocaps
XDG_MENU_PREFIX=arch- kbuildsycoca6

exec i3

I created the following /etc/lemurs/wms/i3. It launches i3, but does not set my keyboard map with setxkbmap or load my .Xresources.

#!/usr/bin/env sh

setxkbmap us -option ctrl:nocaps 2>&1 > /tmp/lemurs.log
XDG_MENU_PREFIX=arch- kbuildsycoca6 2>&1 > /tmp/lemurs.log

xrdb -merge $HOME/.Xresources 2>&1 > /tmp/lemurs.log
exec i3

I'm wondering if it's because xrdb -merge .Xresources needs to be run before starting the X server, and xsetup.sh is executed too late to take effect.