Search Results for 'xinitrc'

[Member stevesr0]

Hi anticapitalista,

Thanks much for your response.

anticapitalista wrote,
Pipewire already runs without systemd installed on antiX sid/testing via the use of elogind.
However, at the moment, it does not run without either systemd or elogind.
It might work in the future with seatd: ie no systemd/elogind baggage. Who knows?
I have tried to build systemd/elogind – free versions of Pipewire, but all attempts have failed.

Does void/artix install parts of elogind to get it to work?
If they do, then they are not doing anything different to what already exists in antiX,

My answer is that several distro forums including Devuan, void and artix have indicated that Pipewire works without systemd, and I have seen posts suggesting that the primary mechanism involved setting a user runtime directory either setting an environmental variable (such as XDG_RUNTIME_DIR) or using a script (such as pam_rundir). However, I haven’t found a thread on these nonsystemd forums which described how to do this in a complete step-by-step.

However, many sites reference the instructions on the Gentoo wiki page on Pipewire. Here is a part of the page dealing with installation without systemd.

Login without session management

Ensure there is a viable D-Bus session active:
FILE ~/.xinitrc

if command -v dbus-launch >/dev/null && test -z "${DBUS_SESSION_BUS_ADDRESS}"; then
       eval $(dbus-launch --sh-syntax --exit-with-session)
fi

Check that XDG_RUNTIME_DIR is set. This is usually managed by either systemd-logind, its fork elogind for OpenRC and similar init systems, or seatd - an alternative free-standing implementation of logind. In addition to running one of the 3 logind variants, a PAM module must also be loaded to let the daemon interact with users logging in and out of the system.

"On systems without any such logind implementation and the required PAM module, the user must create the required directory and set the environment variable manually:

# Ensure XDG_RUNTIME_DIR is set
unset XDG_RUNTIME_DIR
export XDG_RUNTIME_DIR=$(mktemp -d /tmp/$(id -u)-runtime-dir.XXX)

The PipeWire executable must also be called:
FILE ~/.xinitrc

/usr/bin/gentoo-pipewire-launcher"

Whether this would also work on antiX Sid or not, I do not know. (HINT: With some guidance about problems that pop up, I would be willing to try – even if it breaks my “minimalist” Sid install.)

(Not sure if that adequately addresses your question – let me know if you want me to provide specific pages on the nosystemd forums and I shall.)

stevesr0
————————————————

Γεια αντικαπιταλίστα,
Ευχαριστώ πολύ για την απάντησή σας. «αντικαπιταλιστής έγραψε, Το Pipewire λειτουργεί ήδη χωρίς εγκατεστημένο σύστημα σε antiX sid / δοκιμές μέσω της χρήσης του elogind. Ωστόσο, προς το παρόν, δεν λειτουργεί χωρίς ούτε systemd ούτε elogind. Μπορεί να λειτουργήσει στο μέλλον με καθήμενους: δηλαδή χωρίς systemd / elogind αποσκευές. Ποιος ξέρει; Έχω προσπαθήσει να οικοδομήσουμε systemd / elogind – δωρεάν εκδόσεις του Pipewire, αλλά όλες οι προσπάθειες έχουν αποτύχει. Το void / artix εγκαθιστά τμήματα του elogind για να το κάνει να λειτουργήσει; Εάν το κάνουν, τότε δεν κάνουν τίποτα διαφορετικό από αυτό που υπάρχει ήδη στο antiX, ` Η απάντησή μου είναι ότι πολλά φόρουμ διανομής, συμπεριλαμβανομένων των Devuan, void και artix, έχουν δείξει ότι το Pipewire λειτουργεί χωρίς σύστημα και έχω δει αναρτήσεις που υποδηλώνουν ότι ο κύριος μηχανισμός περιελάμβανε τη ρύθμιση ενός καταλόγου χρόνου εκτέλεσης χρήστη είτε ορίζοντας μια περιβαλλοντική μεταβλητή (όπως XDG_RUNTIME_DIR) είτε χρησιμοποιώντας ένα σενάριο (όπως pam_rundir).

Ωστόσο, δεν έχω βρει ένα νήμα σε αυτά τα μη συστηματικά φόρουμ που περιέγραψε πώς να το κάνετε αυτό σε ένα πλήρες βήμα προς βήμα. Ωστόσο, πολλοί ιστότοποι αναφέρονται στις οδηγίες στη σελίδα wiki του Gentoo στο Pipewire. Εδώ είναι ένα μέρος της σελίδας που ασχολείται με την εγκατάσταση χωρίς systemd. «Συνδεθείτε χωρίς διαχείριση συνεδρίας Βεβαιωθείτε ότι υπάρχει ενεργή μια βιώσιμη συνεδρία D-Bus: ΑΡΧΕΙΟ ~/.xinitrc if command -v dbus-launch >/dev/null && test -z “${DBUS_SESSION_BUS_ADDRESS}”; τότε eval $(dbus-launch –sh-syntax –exit-with-session) υγ. Βεβαιωθείτε ότι έχει οριστεί XDG_RUNTIME_DIR. Αυτό συνήθως το διαχειρίζεται είτε το systemd-logind, το πιρούνι του elogind για το OpenRC και παρόμοια συστήματα init, είτε το seatd – μια εναλλακτική ανεξάρτητη υλοποίηση του logind. Εκτός από την εκτέλεση μίας από τις 3 συνδεδεμένες παραλλαγές, πρέπει επίσης να φορτωθεί μια λειτουργική μονάδα PAM για να επιτρέψει στον δαίμονα να αλληλεπιδράσει με χρήστες που συνδέονται και εξέρχονται από το σύστημα.

“Σε συστήματα χωρίς τέτοια συνδεδεμένη υλοποίηση και την απαιτούμενη μονάδα PAM, ο χρήστης πρέπει να δημιουργήσει τον απαιτούμενο κατάλογο και να ορίσει τη μεταβλητή περιβάλλοντος με μη αυτόματο τρόπο: # Βεβαιωθείτε ότι έχει οριστεί XDG_RUNTIME_DIR αναίρεση XDG_RUNTIME_DIR export XDG_RUNTIME_DIR=$(mktemp -d /tmp/$(id -u)-runtime-dir.XXX) Το εκτελέσιμο αρχείο PipeWire πρέπει επίσης να ονομάζεται: ΑΡΧΕΙΟ ~/.xinitrc /usr/bin/gentoo-pipewire-launcher” ` Αν αυτό θα λειτουργούσε επίσης στο antiX Sid ή όχι, δεν ξέρω. (ΣΥΜΒΟΥΛΗ: Με κάποια καθοδήγηση σχετικά με τα προβλήματα που εμφανίζονται, θα ήμουν πρόθυμος να προσπαθήσω – ακόμα κι αν σπάσει την “μινιμαλιστική” εγκατάσταση Sid μου.)

(Δεν είμαι σίγουρος αν αυτό αντιμετωπίζει επαρκώς την ερώτησή σας – επιτρέψτε μου να ξέρω αν θέλετε να παράσχω συγκεκριμένες σελίδες για τα φόρουμ nosystemd και θα το κάνω.)

stevesr0

• This reply was modified 9 months, 1 week ago by stevesr0.
• This reply was modified 9 months, 1 week ago by stevesr0.
• This reply was modified 9 months, 1 week ago by stevesr0.

[Member Xaver]

So far problems (1) and (3) have been solved:
(1) package ‘resolveconf’ was missing (see post #85326 and #85330)
(3) further runit-services are not needed (see post #85258)

Problem (2) still exists: The system freezes on wakeup after suspend (booted live from usb).

I have noticed, that there is a nosystemd1-version of lightdm. I have installed it and indeed, the belonging runit services are installed too.
Unfortunately with running lightdm service the system still freezes on wakeup after suspend.

Using the ligtdm runit service as blueprint I have created a runit service for lxdm as well.
It does work fine, but I do not notice any diffence compared to having no service. Freeze still happens.

Lightdm seems to need polkit for reboot and shutdown. From lxdm reboot and shutdown work fine. So if the refined settings of lightdm are not needed, lxdm is the better (and lighter) choice.

.xinitrc
I have checked, if login with .xinitrc would work better. Unfortunately I have failed to start the system this way.
The openbox-desktop is loaded and looks as it should, but no keyboard or mouse input is possible.
Could this hangup show a hint to the cause of the freeze on wakeup?
Would I need a runit service for startx/.xinitrc too?

• This reply was modified 10 months, 1 week ago by Xaver.

[Forum Admin Dave]

Log into a terminal as root and run the service management tool sysv-rc-conf to disable slimski (remove all x marks).

alternatively if you are always going to run from console… you can remove slimski and run startx /usr/local/bin/desktop-session rox-icewm where rox-icewm is the desktop code. (could also be space-icewm, icewm, rox-fluxbox, etc).

Depending how minimal you want an X session you could also get rid of desktop-session and build your session manually in ~/.xinitrc and run just startx with no arguments

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member Antix-X]

Yea I meant that the program doesn´t run in the background, sorry for my bad explanation. Somebody asked in reddit about the redshift autostart and a user answered:

“What about placing it in .xinitrc? I use Fluxbox, so I have redshift run from .fluxbox/startup. The -O option means redshift will set the color and exit, so there will be no running PID. No need to background it ( & ). On my system, running redshift outputs the message “Using method ‘randr'”.”

And like I said, redshift works fine with the redshift -O 4000 command in the terminal. But why it doesn´t start from the startup folder? I tried it with the desktop-session startup folder and with the fluxbox/startup folder. Nothing works. There´s no reason that it should run in the background as I only want the 4000 colour permanently.

[Member techore]

Thank you and you are correct, it works!

I had dinked around with Xwrapper.conf but it is a new package for me. I had no idea what I was doing.

For anyone else wanting to use Xorg without a display manager this is how I did it.

1. Using cli-aptiX install xorg (148)
2. apt install xserver-xorg-legacy twm xfonts-cyrillic
3. per @christophe, update /etc/X11/Xwrapper.conf with
needs_root_rights=yes
4. nano ~/.xinitrc

xterm &
exec twm

I choose to use twm for testing. It’s tiny with little to no deps.

• This reply was modified 1 year, 3 months ago by techore.
• This reply was modified 1 year, 3 months ago by techore.
• This reply was modified 1 year, 3 months ago by techore.

Attachments:

1. 

   vbantix_twm.png
   

[Moderator Brian Masinick]

crackulator wrote:

I found the answer by digging through the code.

Such customizations can be placed in
~/.desktop-session/desktop-session.conf
Not sure if that is exactly intended, but it serves the purpose.

The files commonly used for this purpose on other systems, like .xsession, .xprofile, .xinitrc, .xsessionrc are not referenced by the toolchain in the default installation.

To modify the $PATH as my case, use a line such as:
export PATH=$HOME/script:$PATH

This makes good sense. The only thing I’d consider doing differently is that I’d probably put the script path after the primary path, but that’s personal preference; what you suggest looks fine too.

--
Brian Masinick

[Member crackulator]

I found the answer by digging through the code.

Such customizations can be placed in
~/.desktop-session/desktop-session.conf
Not sure if that is exactly intended, but it serves the purpose.

The files commonly used for this purpose on other systems, like .xsession, .xprofile, .xinitrc, .xsessionrc are not referenced by the toolchain in the default installation.

To modify the $PATH as my case, use a line such as:
export PATH=$HOME/script:$PATH

• This reply was modified 1 year, 6 months ago by crackulator.
• This reply was modified 1 year, 6 months ago by crackulator.

[Member ex_Koo]

( @Koo, why is your xprofile getting executed and mine is not?)
It is called from my xinitrc file as is i3 executed. I do not like nor use login managers that why I use xinitrc. And if I have more then one Linux system install I use tbsm which I use to login from the tty screen.

tbsm

#!/bin/sh

# this file is run when calling startx

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

# user init scripts and settings
[ -r /etc/X11/xinit/.Xmodmap ] && xmodmap /etc/X11/xinit/.Xmodmap
[ -r ~/.Xmodmap ] && xmodmap ~/.Xmodmap
[ -r ~/.Xresources ] && xrdb -merge ~/.Xresources
[ -r ~/.xprofile ] && . ~/.xprofile

# launch the session, commands below this line will be ignored
exec i3

[Member crackulator]

Well that didn’t help at all. I made an ~/.xprofile, containing this:

echo ".xprofile" >> /tmp/fc.log
export PATH="/home/crackulator/script:$PATH"

Made sure it was executable by all. The “echo” is to report to a log file when it gets executed. I boot the computer, log in from SLiM, and i3 starts up. The $PATH is not changed, and there is no entry in /tmp/fc.log. By all appearances, .xprofile was not executed, nor /etc/xprofile.

So that took me back to /etc/X11/xinit/xinitrc, which was basically blank, no reference to .xprofile. Fixed it according to https://wiki.archlinux.org/title/xprofile, made it executable, also made the same in ~/.xinitrc, also logging to file. Never gets executed. What the hell?

This is a stock antix install, only thing weird is 32-bit, and I’m using i3, but I also tried Rox-Ice, same result. @Koo, why is your xprofile getting executed and mine is not?

I guess the one good thing is that it took me back to /etc/slim.conf, and it appears that the default path is defined there. So I can probably add it there and it’ll work. But what the heck is going on here?

• This reply was modified 1 year, 6 months ago by crackulator.
• This reply was modified 1 year, 6 months ago by crackulator.

[Member ex_Koo]

I’m not quite sure what you are trying to do.

If you want a script to run after loading i3 you just need something like below.
(Make Sure your scripts executable)

exec –no-startup-id ~/.scripts/dunstesting.sh
Or a key bind
bindsym $mod+shift+l exec –no-startup-id ~/.config/rofi/scripts/rofi-locate

export XDG_CONFIG_HOME=”$HOME/.scripts”

This is my xprofile

#!/bin/sh

# sourced at boot by ~/.xinitrc and most display managers

export XDG_CONFIG_HOME="$HOME/.config"
export PATH="$HOME/.local/bin:$PATH"

picom -b &
nm-applet &
volumeicon &
nitrogen --restore &
xfce4-power-manager &
/usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1 &
gnome-keyring-daemon --start --components=pkcs11 &
ksuperkey -e 'Super_L=Alt_L|F1' &
ksuperkey -e 'Super_R=Alt_L|F1' &
xset dpms 600 900 1200
xset r rate 350 60

• This reply was modified 1 year, 6 months ago by ex_Koo.

I am running i3 window manager. My objective is to add a $PATH entry, which works for dmenu in i3, therefore needs to be in place before starting i3 from SLiM. I want to add this path entry to point to some scripts that I use to perform common custom tasks that I run often from dmenu or the terminal.

Usually one adds such a command in .profile, .xsessionrc, etc. to add to the $PATH variable. However, I empirically determined that none of the following scripts are executed when launching i3 from SLiM:

.profile
.bashrc
.xsession
.xprofile
.xinitrc
.xsessionrc

It does run ~/.config/i3/config, and also ~/.desktop-session/startup, but I can’t figure out how to get them to change the $PATH as seen by i3/dmenu. I believe this is because of their context, they run at a parental level that doesn’t let them set the environment variables. Or maybe I just haven’t found the right syntax, trying things like:

PATH=/home/crackulator/scripts:$PATH
export PATH=/home/crackulator/scripts:$PATH
exec export PATH=/home/crackulator/scripts:$PATH
…and so forth, as appropriate as I can tell from the context.

In general, I’d like to add this path to all contexts and all desktops. It doesn’t need to be only for i3, that’s just my preferred desktop for this computer.

Where and how can I insert a command to make this modification to $PATH?

Thanks

[Member andyprough]

olsztyn wrote:

Just as this thread has be thoroughly discussed and many great thought have been shared I just have one remaining question that bugs me:
The peculiar DWM behavior described in post #84852, where occasionally on one of my instances an image of closed app remains in the screen, not being cleared, until a new app is started: Has anyone else experienced this behavior?

I am trying to positively determine if it is a bug or just me. I have done lots of testing and it seems to happen on one my Live instance but not on others. This would indicate some difference in that instance and not a bug, not sure why though… Other than that DWM functions perfectly…
Any info will be appreciated. Thanks and Regards…

I don’t recall ever seeing that. If you only saw it on your Live instance and not on others, then you probably answered your own question. Probably some graphics aspect of the Live system.

With DWM, you can try different graphics compositors – maybe one of them would improve your graphics experience. A couple of common compositors are compton and picom, and you can use openbox and other compositors. Try installing compton with “sudo apt install compton”, and then use dmenu to start “compton”, and see if you get the graphics artifact. Or do the same with picom. If you find one that works, you can put it into your ~/.xinitrc file (or autostart file if you installed the dwm autostart patch) as just a single line: “compton &”, or “picom &”. compton and picom will also allow you to set transparency in some of your programs, such as with many of your terminal emulators, like roxterm.

Now that I’ve begun exploring herbstluftwm, I see how stuff like using compositors is easier than with DWM. Just put a “compton &” line in ~/.config/herbstluftwm/autostart, hit the Super-Shift-r key combination to refresh the window manager, and you are done.

Edit – picom, a lightweight version of compton, is not in the Debian repos, and would have to be built from source: https://github.com/yshui/picom. It’s available in the Arch AUR – I must have used it when I was trying Artix.
2nd Edit – I built picom – very easy using the instructions on the github page:
Install dependencies:
sudo apt install libxext-dev libxcb1-dev libxcb-damage0-dev libxcb-xfixes0-dev libxcb-shape0-dev libxcb-render-util0-dev libxcb-render0-dev libxcb-randr0-dev libxcb-composite0-dev libxcb-image0-dev libxcb-present-dev libxcb-xinerama0-dev libxcb-glx0-dev libpixman-1-dev libdbus-1-dev libconfig-dev libgl1-mesa-dev libpcre2-dev libpcre3-dev libevdev-dev uthash-dev libev-dev libx11-xcb-dev meson cmake
Clone the source and build and install:

cd /usr/src/
sudo git clone https://github.com/yshui/picom
cd picom/
sudo git submodule update --init --recursive
sudo meson --buildtype=release . build
sudo ninja -C build
sudo ninja -C build install

• This reply was modified 1 year, 8 months ago by andyprough.
• This reply was modified 1 year, 8 months ago by andyprough.

[Member ex_Koo]

olsztyn wrote:

Also looked at tbsm, which at first looks interesting to simplify switching WMs. Just want to mention that the latest update was to rel. 0.5 and the date of this latest update was in Dec. 2018. Almost three years. Is this still a viable choice considering this project has been virtually dropped?

Don’t worry about the date as there are only so many things that can be done with a simple program like this it works great..

The reason I like using dwm-autostart it keep all the related dwm stuff separate from the rest of the system setting. If you start using .xinitrc to start programs after login it can interfering with what use want to start with each window manager, as with i3wm I keep my autostart’s as part of the i3 .config.

part of my i3 config.

exec_always --no-startup-id exec i3-workspace-names-daemon &
exec --no-startup-id picom --config ~/.config/picom/picom.conf &
exec --no-startup-id nm-applet &
exec --no-startup-id dunst &
exec --no-startup-id /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1 &
exec --no-startup-id nitrogen --restore &
exec --no-startup-id xfce4-power-manager &

dwm-autostart

#! /bin/bash

nitrogen --restore &
dunst &
picom --config ~/.config/picom/picom.conf &
nm-applet &
dwmbar &
##~/suckless/dwmbar/dwmbar.sh &

[Member ex_Koo]

andyprough wrote:

Yes, I’m a big fan of the autostart patch. You and I use most of the same applets and autostart programs. But tell me about tbsm for window manager switching, I’ve never heard of it.

tbsm is just a simple script that let you login to windows managers or GUI desktops from tty. No need to install login managers or even use .xinitrc .

tbsm homepage

[Member andyprough]

ex_Koo wrote:

One of the best patches for me is autostart as I can keep all my dwm stuff, separate and I don’t have to use .xinitrc for autostart’s in dwm. I don’t use a GUI login manager as use I tbsm to switch between window managers.

~/.dwm folder

#! /bin/bash

nitrogen --restore &
dunst &
picom --config ~/.config/picom/picom.conf &
nm-applet &
dwmbar &
##~/suckless/dwmbar/dwmbar.sh &

Yes, I’m a big fan of the autostart patch. You and I use most of the same applets and autostart programs. But tell me about tbsm for window manager switching, I’ve never heard of it.