Reorganize autostart

Head_on_a_Stick · 2016-07-08 06:56:18

^ Good work

I will try this out on my system tonight.

Does your system really need 12 seconds for volumeicon?

There must be something going on here, I have used volumeicon for several years in both Debian and Arch with tint2 and other panels and I have *never* had to use any `sleep` commands in ~/.{xinitrc,xession}

johnraff · 2016-07-08 09:51:27

Head_on_a_Stick wrote:

Does your system really need 12 seconds for volumeicon?
There must be something going on here, I have used volumeicon for several years in both Debian and Arch with tint2 and other panels and I have *never* had to use any `sleep` commands in ~/.{xinitrc,xession}

Were you using it with PulseAudio? The error message that appears in ~/.Xsession-errors refers to the pulse server. I started out with 2 seconds but found volumeicon failing to load on occasions. Gradually increasing the sleep - 10s seemed to be OK, but a couple of days later there it was again - now with 12s volumeicon loads every time, so far...

Actually, with pnmixer now in Stretch, a Jessie backport of that is starting to look like an attractive option. I'm currently using the Ubuntu package that @hhh posted and it's working very well.

damo · 2016-07-08 12:13:11

Tried the autostart from https://forums.bunsenlabs.org/viewtopic … 741#p31741, with a couple of changes:

## Enable power management
xfce4-power-manager &

## Start the battery applet
# line commented due to dist-upgrade
######(sleep 2; fdpowermon) &

and

## Volume control for systray
(sleep 4; volumeicon) &

Sound control is better than with volti on this laptop - headphone/speaker switching is automatic, and mute for each is independant, and persist between log-ins.

hhh · 2016-07-08 12:37:08

@johnraff, wonderful. BTW, I've had nitrogen at the beginning of my autostart for the last week with no problems.

Agreed to 2 locations, I realized this was unavoidable right after posting.

https://specifications.freedesktop.org/ … atest.html

@cloverskull, see the link above. You can override any /etc/xdg/autostart *.desktop file locally by copying it to ~/.config/autostart and adding the following to it...

Hidden=true

Head_on_a_Stick · 2016-07-08 19:46:39

johnraff wrote:

Were you using it with PulseAudio?

Erm, no.
:8

We could try starting Pulseaudio manually using this line in autostart:

pulseaudio --start && volumeicon &

Then disable the XDG autostart.

Give me a moment to check this...

Head_on_a_Stick · 2016-07-08 19:55:27

Head_on_a_Stick wrote:

We could try starting Pulseaudio manually using this line in autostart:
pulseaudio --start && volumeicon &
Then disable the XDG autostart.

This works for me!

Can somebody else test this please?

To disable the XDG autostart, copy the .desktop file to $HOME:

mkdir -p ~/.config/autostart && cp /etc/xdg/autostart/pulseaudio.desktop ~/.config/autostart

Then add this line:

echo "Hidden=true" >> ~/.config/autostart/pulseaudio.desktop

Finally, replace the "volumeicon" line in ~/.config/openbox/autostart with the line given at the top of the post.

Thanks!

johnraff · 2016-07-09 03:42:08

Head_on_a_Stick wrote:

We could try starting Pulseaudio manually using this line in autostart:
pulseaudio --start && volumeicon &
Then disable the XDG autostart.

Interesting! This would allow us to use the vanilla volumeicon.

I'll test it out as soon as I've finished testing your rebuilt volumeicon...

Last edited by johnraff (2016-07-09 03:43:00)

johnraff · 2016-07-09 05:58:33

(Original post was accidentally removed.)

johnraff wrote:

^It works!
... It turns out they are provided by the Debian package pulseaudio-module-x11. Install it and start-pulseaudio-x11 runs without errors...

hhh wrote:

I left that package out intentionally, I remember seeing a Debian bug about a memory leak in it and it didn't seem necessary at the time. Easy enough to add it back.

Last edited by johnraff (2016-07-13 06:46:46)

hhh · 2016-07-10 17:02:37

^Sorry, @johnraff, this was my post. I must have clicked Edit instead of Quote.

hhh · 2016-07-12 07:31:33

johnraff wrote:

Back to topic: @hhh I've taken your original suggested autostart and modified it according to input from @HoaS and my own thoughts. My current autostart looks a lot like this and seems to be causing no problems, but that doesn't mean there are none.
Nearly all the sleeps are gone, along with most of the ampersands. (I'm now wondering if some of the compositing/systray weirdness we had in the past might have been caused by the very race conditions @HoaS referred to with forking.)
@hhh contributed a couple of extra keyboard & touchpad settings.
The exact order of commands is more important now, without forking, and might well need tweaking. My personal file starts compton before tint2 while @hhh has tint2 first (as here). I've moved nitrogen earlier than @hhh had it, for no particular reason...
Any opinions on which commands should run before/after others, along with whether any other delays are needed, will be gratefully entertained.
## SETTINGS START

## Turn on/off system beep.
xset b off

## Set keyboard settings - 250 ms delay and 25 cps (characters per second) repeat rate.
## Adjust the values according to your preferances.
xset r rate 250 25

## Add keyboard mapping.
#xmodmap -e "keysym Insert = Multi_key"

## NEW
## Disable CapsLK
setxkbmap -option ctrl:nocaps

## Configure touchpad. See 'man synaptics' for more info.
synclient VertEdgeScroll=1 HorizEdgeScroll=1 TapButton1=1 2>/dev/null

## NEW
## Disable touchpad while typing
syndaemon -i .5 -K -t -R -d &

## SETTINGS END

## GNOME PolicyKit authentication
/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 &

## Set a wallpaper
nitrogen --restore

## Start the tint2 session (the default tint2 will run if no sessions have been set)
bl-tint2-session

## Compton
bl-compositor --start

## Start the Conky session (the default conkyrc will run if no sessions have been set)
bl-conky-session --autostart &

## Start the battery applet
fdpowermon &

## Volume control for systray
(sleep 12; volumeicon) &
## Replace with this?:
#pnmixer &

## Start Clipboard manager
clipit &

## bl-welcome - post-installation script, will not run in a live session and
## only runs once. Safe to remove.
(sleep 10; bl-welcome --firstrun) &

## DISABLED

## Volume keys daemon (probably not needed)
#xfce4-volumed &

## Start xscreensaver (light-locker now used by default, run via XDG autostart.)
#xscreensaver -no-splash &

## bl-fortune - have the system come up with a little adage (not yet enabled)
#(sleep 120; bl-fortune) &

Sorry to quote your whole post, but this is fantastic IMO. Way faster, the desktop wall is instantaneous, tint2 loads smoothly, a quick flicker for compton and then the panel applets pop up, as well as conky with it's background already transparent. Just great! BTW, I've been starting compton at the start of the file, right after nitrogen, with no issues, but where you have it is perfect. Compton seems to take a second to kick in anyway, so the timing shouldn't be that significant.

We should commit this (when our apps are finalized) for Deuterium, please!

BTW, @johnraff, we need another thread if this is possible... Any way to make updating bunsen-configs smoother? The method of deleting ~/.config/bunsen/bl-setup is kind of harsh. It wipes a bunch of non-BL settings, so to speak, including (iirc) obconf and lxappearance configs.

brontosaurusrex · 2016-07-12 08:22:55

madoromi wrote:

brontosaurusrex wrote:
madoromi wrote:
Sleeping for an arbitrary period of time is bad form and not actually deterministic; either a) you didn't sleep long enough or b) you're slowing down the setup process, extending a session set up that would take 1s on a machine to ahem, 30s.
Actually I agree, do you have some links on how to do systemd "units" for openbox autostart part?
Check out this repository [1]; it has an example config for dwm that shows how to convert a linear session/autostart script into a collection of units: https://github.com/KaiSforza/systemd-user-units

Actually after some thinkering I disagree, this is kinda complicated and it will tie us to systemd (or multiple solutions).

Last edited by brontosaurusrex (2016-07-12 08:23:59)

johnraff · 2016-07-13 04:18:00

hhh wrote:

^Sorry, @johnraff, this was my post. I must have clicked Edit instead of Quote.

And you nuked all my long post!!

(It was about what command should be used to launch pulseaudio, and the modules that might be loaded.)

Has anyone got it in an email notification or something, so @hhh's comment would make sense?

johnraff · 2016-07-13 04:26:15

hhh wrote:

Any way to make updating bunsen-configs smoother? The method of deleting ~/.config/bunsen/bl-setup is kind of harsh. It wipes a bunch of non-BL settings, so to speak, including (iirc) obconf and lxappearance configs.

It shouldn't be quite that harsh. If it does what I intended ( ) then the only files overwritten will be those contained in /usr/share/bunsen/skel. Everything else should be left alone. A backup copy of all overwritten files should be created.

I can't think of any way to copy in a new version of e.g. rc.xml and simultaneously respect the user's own changes. The way it is now, it's left up to the user to resolve any clashes the way they want. If you can suggest a preferable algorithm I'll be happy to adjust the user-setup script accordingly. (Something with git?)

johnraff · 2016-07-13 07:25:12

Head_on_a_Stick wrote:

We could try starting Pulseaudio manually using this line in autostart:
pulseaudio --start && volumeicon &
Then disable the XDG autostart.

Let me summarize my sadly bereaved post before it fades away too far...

I tried that idea, and basically, It seems to work pretty well.

Some side-issues:

The XDG autostart runs a different command 'start-pulseaudio-x11'.
That command makes sure that pulseaudio exits with the Xsession. (see https://bugs.debian.org/cgi-bin/bugrepo … =594001#15 )
It also loads two modules module-x11-publish and module-x11-cork-request, and returns 1 if they aren't found.
Those modules can be provided by installing the package pulseaudio-module-x11.
Even without them, we have been using that XDG command with no apparent problems.
They may have caused memory leaks in the past, but they may or may not have been fixed now.
Those modules may or may not be important in some cases: https://www.freedesktop.org/wiki/Softwa … #index31h3

So I'm suggesting we use start-pulseaudio-x11 in openbox/autostart, and, wondering whether we should add pulseaudio-module-x11 to our install list. Can any PulseAudio Guru shed some light here?

PS starting volumeicon after the pulseaudio start command has run seems to work well, and not take anything like 12 seconds, let alone 30. So why was that long delay for volumeicon needed when starting pulseaudio via XDG?

Last edited by johnraff (2016-07-13 07:27:22)

Head_on_a_Stick · 2016-07-13 07:48:03

johnraff wrote:

The XDG autostart runs a different command 'start-pulseaudio-x11'.

*slaps forehead* I didn't even think to look in the XDG file, I just checked the ArchWiki.

Yes, using the XDG autostart command is a much better idea.

wondering whether we should add pulseaudio-module-x11 to our install list.

I'm no PA Guru but the package is only 88.0KiB (amd64) so it would seem silly to leave it out

why was that long delay for volumeicon needed when starting pulseaudio via XDG?

I have no idea

I always avoid invoking XDG at all in my own desktops for exactly this reason...

xaos52 · 2016-07-13 14:00:31

@johnraff

Can any PulseAudio Guru shed some light here?

I am by no means a pulseaudio guru, but I would suggest installing the version of pulseaudio from jessie-backports, before drawing any conclusions.

versions of pulseaudio by repo:
jessie: 5.?
jessie-backports: 7.?
sid: 9.?

So it seems like pulseaudio is still actively being developed.

My 2 cents

hhh · 2016-07-13 21:03:28

This is the bug that caused me to leave pulseaudio-module-X11 out. It looks like the fix has entered stretch/sid...

https://bugs.debian.org/cgi-bin/bugrepo … bug=765828

Head_on_a_Stick · 2016-07-13 21:18:53

hhh wrote:

https://bugs.debian.org/cgi-bin/bugrepo … bug=765828

OK, so that memory leak seemed to be caused specifically be the `start-pulseaudio-x11` command.

Do we need the script used by PA in the XDG autostart file:

#!/bin/sh

set -e

if [ x"$DISPLAY" != x ] ; then

    /usr/bin/pactl load-module module-x11-publish "display=$DISPLAY" > /dev/null
    #/usr/bin/pactl load-module module-x11-cork-request "display=$DISPLAY" > /dev/null

    if [ x"$KDE_FULL_SESSION" = x"true" ]; then
       /usr/bin/pactl load-module module-device-manager "do_routing=1" > /dev/null
    fi

    if [ x"$SESSION_MANAGER" != x ] ; then
        /usr/bin/pactl load-module module-x11-xsmp "display=$DISPLAY session_manager=$SESSION_MANAGER" > /dev/null
    fi
fi

Would using `pulseaudio --start` cause any problems?

It may be preferable in the light of hhh's linked bug report.

hhh · 2016-07-13 21:50:55

BTW, @johnraff, I'm so sorry about that edit!

johnraff · 2016-07-14 03:14:41

xaos52 wrote:

would suggest installing the version of pulseaudio from jessie-backports, before drawing any conclusions.
versions of pulseaudio by repo:
jessie: 5.?
jessie-backports: 7.?
sid: 9.?
So it seems like pulseaudio is still actively being developed.

Indeed. Moving up to the backports 7 version would be exciting, but I'm wondering what new changes to the interface it might bring? Also, installing a jessie-backports package in the default system would mean enabling the backports repos by default, or repackaging the backports pulseaudio package for bunsen-hydrogen. That would probably involve a lot of other dependencies...

Debian Stable has the virtue that, while packages might be old, for the duration of the release you can count on their behaviour not changing much. You can ship scripts and config files that won't need constant updating.

So, if it has no major issues (I'm presuming the Debian devs saw to that) I'd vote for staying with pulseaudio 5 by default. We could offer users the option of upgrading if it was found to fix certain problems.

BTW @hhh no problem - the topic stayed on course.

Last edited by johnraff (2016-07-14 03:15:25)

#61 2016-07-08 06:56:18

Re: Reorganize autostart

#62 2016-07-08 09:51:27

Re: Reorganize autostart

#63 2016-07-08 12:13:11

Re: Reorganize autostart

#64 2016-07-08 12:37:08

Re: Reorganize autostart

#65 2016-07-08 19:46:39

Re: Reorganize autostart

#66 2016-07-08 19:55:27

Re: Reorganize autostart

#67 2016-07-09 03:42:08

Re: Reorganize autostart

#68 2016-07-09 05:58:33

Re: Reorganize autostart

#69 2016-07-10 17:02:37

Re: Reorganize autostart

#70 2016-07-12 07:31:33

Re: Reorganize autostart

#71 2016-07-12 08:22:55

Re: Reorganize autostart

#72 2016-07-13 04:18:00

Re: Reorganize autostart

#73 2016-07-13 04:26:15

Re: Reorganize autostart

#74 2016-07-13 07:25:12

Re: Reorganize autostart

#75 2016-07-13 07:48:03

Re: Reorganize autostart

#76 2016-07-13 14:00:31

Re: Reorganize autostart

#77 2016-07-13 21:03:28

Re: Reorganize autostart

#78 2016-07-13 21:18:53

Re: Reorganize autostart

#79 2016-07-13 21:50:55

Re: Reorganize autostart

#80 2016-07-14 03:14:41

Re: Reorganize autostart

Board footer