Xorg or some other system overriding xinitrc

Masse · 2010-07-03 16:22:14

I have the following .xinitrc configuration. The important parts are the xmodmap and the xset lines.

xset r rate 195 35
xrdb -merge $HOME/.Xresources
xrdb -merge $HOME/.Xdefaults
pkill urxvtd ; urxvtd &
$HOME/bin/gpg-agent.sh
xsetroot -cursor_name left_ptr
xscreensaver &
skype &
$HOME/bin/tray &
$HOME/bin/randBackground.sh &
xsetkbmap -model evdev
xmodmap $HOME/.Xmodmap
xmodmap > $HOME/logs/xmodmap
exec ssh-agent xmonad

All of the commands work after x and xmonad have started succesfully, xmodmap changes the caps lock to work as esc, and xset enables dpms just as expected.

However if I start X with startx, the xmodmap command does not work in its entirety. Caps lock will function as esc, but also as lock. If I start with slim (which also reads the same xinitrc), the xmodmap commands works fine. The "xmodmap >" line shows that the lock has been cleared at that point of time, so sometimes after the xmodmap lines and functional working X, the lock has been reset. For the xmodmap command to work with slim, points me to believe that something during X startup resets the lock.

The xset dpms command doesn't work with either startx or slim. I had also set

Option "DPMS" "true"

to xorg.conf Monitor section, and still no luck, which points me to believe that something after X (hal?) is interfering with xinitrc and xorg.conf.

masse@libre:~ $ pacman -Qi xorg-server
Name           : xorg-server
Version        : 1.7.6-3

karol · 2010-07-03 16:37:14

You have an old xorg-server, is there a reason you didn't upgrade?
What DE / WM do you use?

Masse · 2010-07-03 16:53:07

I have identified the cause for DPMS misbehaviour; xscreensaver. Xscreensaver had dpms toggled on, but maybe there was some form of error. I toggled it off and back on and now it's working again.

Masse · 2010-07-03 16:58:35

karol wrote:

You have an old xorg-server, is there a reason you didn't upgrade?
What DE / WM do you use?

I use XMonad but the same behaviour can be seen with fluxbox.

I have an old xorg-server because most of the time updating kernel breaks something (russian roulette anyone?) so I put it on hold. Therefore nvidia is on hold and therefore xorg-server is on hold and therefox <y> is on hold.

loafer · 2010-07-03 17:21:55

Out of interest what are your examples of a kernel update breaking things with such regularity. Do you have esoteric hardware etc. that makes this more likely?

Masse · 2010-07-03 17:39:37

loafer wrote:

Out of interest what are your examples of a kernel update breaking things with such regularity. Do you have esoteric hardware etc. that makes this more likely?

I can't remember exactly anymore, but there were a lot of acpi troubles, which got worse with almost every update. At first it stopped from booting randomly, then consistently, then again randomly. Actually the problem still persists, but I can "fix" it by using framebuffer. My theory is that it slows down the booting by few milliseconds which gives time for some hardware to initialize.

The last time I upgraded kernel and most importantly nvidia drivers, the drivers had become so slow to start that kdm would rather shut down than wait for a bit longer.
http://bbs.archlinux.org/viewtopic.php?id=90340

Last edited by Masse (2010-07-03 17:46:20)

Arch Linux

#1 2010-07-03 16:22:14

Xorg or some other system overriding xinitrc

#2 2010-07-03 16:37:14

Re: Xorg or some other system overriding xinitrc

#3 2010-07-03 16:53:07

Re: Xorg or some other system overriding xinitrc

#4 2010-07-03 16:58:35

Re: Xorg or some other system overriding xinitrc

#5 2010-07-03 17:21:55

Re: Xorg or some other system overriding xinitrc

#6 2010-07-03 17:39:37

Re: Xorg or some other system overriding xinitrc

Board footer