Solved Xset Command running at startup

the3ajm

the3ajm

I wanted to share my experience of trying to run the xset command at startup, I'm running Xfce and it has a autostart box that you can edit to run commands that didn't work. There's a rc.d script that I created it runs with onestart command since it's stating that the rcvar variable wasn't set on rc.conf which I made sure that both file matches the variable it was set to.

Then I came across posts suggesting to input the commands to ~/.xinitrc but that failed as well, second page down a user asks to input the command at the ~/.profile because the commands gets overwritten at boot up so that's what worked for me. If anyone can extend the reasoning why then it would help me understand how command gets executed in certain order as it feels like it was overwritten somewhere.

The purpose of all this is that my screen goes black and can't wake up through normal keyboard presses and had to login to virtual terminal on getting access back to the machine, however my other session is still running so I want to disable the screen from blanking out.
 
That belongs to how you start your X session; I assume your xset command should be added to ~/.xsession - just before it executes the main Xfce startup script.
 
the3ajm said:
The purpose of all this is that my screen goes black and can't wake up through normal keyboard presses and had to login to virtual terminal on getting access back to the machine, however my other session is still running so I want to disable the screen from blanking out.
Click to expand...
Isn't this just caused by DPMS? Is it blanking (i.e. turning black) or does the monitor switch off to a power save mode?

You can turn off DPMS by adding this to the monitor section:
Code: 
Option "DPMS" "false"
Alternatively you can try this in the ServerFlags section:
Code: 
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"
Option "BlankTime" "0"
 
xset should work from ~/.xinitrc, this file is traditionally sourced when X starts. Unfortunately, desktop environments do not care much about traditions any more ...
 
Right, it works for me from ~/.xinitrc, which also includes a couple of xset commands as well. For example, adding font directories to X session: xset +fp $my_additional_font_path. Now ~/.xinitrc is supposed to work when X is started using startx or xinit command. Documentation says (ArchWiki or other), you either start using startx or you use alternative methods like DMs and these won't care about ~/.xinitrc. I prefer startx because it leaves me in command. But then, I don't use DEs like GNOME...
 
With this said, I wonder why is it that in my recent 12.2-p1 installation one of the commands included in .xinitrc doesn't last long??
I have this in my .xinitrc to conveniently handle my keyboard hotkeys + layout switching:
Code: 
setxkbmap -layout 'us,fr(oss),ru' -variant -option grp:alt_shift_toggle,\
terminate:ctrl_alt_bksp,compose:ralt,lv3:menu_switch keypad:pointerkeys &
It has worked fine in ALL my FVWM installations that I use across several computers, including both 12 and CURRENT. It runs there as long as X session does and then I can terminate the session with Ctrl+Alt+Backspace.
But now I've made a fresh 12.2 install (with subsequent freebsd-update, of course) and there this setxkbmap command lasts just some time and then it is "forgotten" by the running desktop session. Any ideas why this could be?
Not only that, but also nvidia dirver is not loaded upon boot (I'm using GRUB2, but it works fine everywhere) nor vmm PPT functionality is working. Weird, I say. Can give it no explanation as this particular installation is a COPY of another one where it al works fine.

ADDED: and why is it that the <code> tag wrapped text shows in one line that goes outside all boundaries, so I have to split it into 2 lines?
 
You must log in or register to reply here.
Back
Top