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.