Configuration file exploration (in episodes)

[ncmprhnsbl]

Tried in the terminal out of curiosity, it works but the maximum value is 65536 or is it better to give the percentage with %

just checked myself, and you're right, it works, it's just missing the % (unless you want use ten thousands ) ...there could also be an issue with whether pipewire has got it together at this point in the startup..**
we could try using wpctl directly, but it needs some extra stuff to find the correct channel.
for now, in /usr/local/bin/gui-autostart:

Code: Select all

# Set volume
get_cheatcode_value volume cheatcodes
[ "$cheatval" ] && amixer set Master ${cheatval}%

should fix it (provided ** is not the case)
..or, i am over complicating this and the cheat should just be eg. volume=50% and to fix in documentation..

I had tried opensnitch-ui just to combine the useful with the delightful, though later I also tried mousepad and it doesn't work. I tried out of curiosity to prepend the command "sleep 30;" obviously without any result

the whole guiexec is a work in progress atm(you may have noticed in the other thread)

RE cliexec= ... i'm not seeing where it's implemented, so it most likely isn't.

[ncmprhnsbl]

there could also be an issue with whether pipewire has got it together at this point in the startup..**

a quick check seems this might be the case.. maybe a sleep will do the trick..

[vinnie]

..or, i am over complicating this and the cheat should just be eg. volume=50% and to fix in documentation..

You could also add the % only if it's missing, also because I really don't see any reason to put a number in the of thousands dimension for specify the volume .
But I think it's overcomplicating, 0-100 without percentage seems to me the most intuitive thing of all.

the whole guiexec is a work in progress atm(you may have noticed in the other thread)

yes, I noticed, I had focused on login so I could look at one configuration file.

RE cliexec= ... i'm not seeing where it's implemented, so it most likely isn't.

As for the use of the pipe as a separator, I don't know what kind of limitations the insertion of these scripts at startup may have, though, I was thinking if, in case you wanted to write a longer script, maybe it would be possible to insert in the same "/config/" dir a "script.sh" and then refer to it with a cliexec="./script.sh"

a quick check seems this might be the case.. maybe a sleep will do the trick..

[ncmprhnsbl]

As for the use of the pipe as a separator, I don't know what kind of limitations the insertion of these scripts at startup may have, though, I was thinking if, in case you wanted to write a longer script, maybe it would be possible to insert in the same "/config/" dir a "script.sh" and then refer to it with a cliexec="./script.sh"

was going to say that for anything more complex than a simple command use a script
as for where, the script can be anywhere but think the path would need to be recognizable eg. /mnt/sda1/config/script.sh .. i don't think ./ would mean the config directory..
if i implement cliexec, most likely in etc/init.d/prelogin i'm not sure where that would regard as ./ ..

[vinnie]

Sorry I have a problem and I would like to try to start some commands before xorg is started, I remembered cliexec in configurations however I am not sure if it works as I expected.
I tried uncommenting the example “cliexec=echo ‘test’ > /tmp/test” and restart but during startup I have to enter the root password for that command to be started and then every time I open a virtual terminal on xfce I have to enter the root password for that command to be started again.
I'm pointing this out here both because I don't know if this is the correct behavior of this configuration and also because in the meantime I'm taking the opportunity to ask where I should put a command that gets started before xorg runs.

[ncmprhnsbl]

I tried uncommenting the example “cliexec=echo ‘test’ > /tmp/test” and restart but during startup I have to enter the root password for that command to be started and then every time I open a virtual terminal on xfce I have to enter the root password for that command to be started again.

surprising that anything at all happens, because i didn't think cliexec= was implemented, or at least i havn't found it yet
but.. i have found: /etc/local.d .. where you can place a executable script that should run at startup (before xorg) i've used it in the past to set the powerstate of a ati gpu for a laptop.
so.. if you make a module containing /etc/local.d/your_script , this should work for your use case.

[vinnie]

Thanks ncmprhnsbl, I had tried using /etc/X11/xinit/xinitrc but I am not convinced it worked well, I put these commands in it:

Code: Select all

ir-keytable -c
ir-keytable -p mce_kbd -w /usr/lib/udev/rc_keymaps/mce_keyboard.toml
ir-keytable -k 0x400=KEY_A
exec dbus-launch --exit-with-session /usr/bin/startxfce4

Basically I'm configuring an IR keyboard and unfortunately it seems that for some strange xorg problem it has to be configured outside X otherwise it doesn't work properly.
I'll try the file you pointed me to (the combo with your explanation of how to edit the files_change.xzm was providential!).

[vinnie]

i have found: /etc/local.d .. where you can place a executable script that should run at startup (before xorg) i've used it in the past to set the powerstate of a ati gpu for a laptop.

Unfortunately it doesn't work for me, I don't know if there are any other problems but if I put the script in that directory it doesn't seem to start at startup.

I tried to put a marker to check whether the script had been started

Code: Select all

[guest@porteus ~]$ cat /etc/local.d/irkb_loadscript.sh 
#!/bin/bash
sleep 5
ir-keytable -c -p mce_kbd --write=/etc/rc_keymaps/mce_key_1044.toml --sysdev=rc0
touch /tmp/irk_worked

but after startup the jsaoid file /tmp/irk_worked is not there.

In the meantime, I will try to take inspiration from this topic and see if I can somehow get the script started from open.rc (good resource: 1 2)

[vinnie]

Ok, probably it's not the best way but with openrc approach it's working.
You have to add a script in /etc/init.d:

Code: Select all

#!/usr/bin/openrc-run
description="My script to start 1044 ir keyboard before xorg"
start() {
   sleep 5
   ir-keytable -c -p mce_kbd --write=/etc/rc_keymaps/mce_key_1044.toml --sysdev=rc0
}

and add a voice in /mnt/sdxy/config/services as you teach me in the past

Code: Select all

cat /mnt/sda3/config/services
...
### start ir 1044 keyboard custom config at boot
irkb_configure

The downside is that then the script appears as a daemon started in rc-status.

I have to add also that because of the xorg problem it seems that if I remove and reinsert the receiver I have to restart the script by going to another virtual console with ctrl+alt+f2 and give rc-server irkb_configure restart. But this is another problem.

[ncmprhnsbl]

Unfortunately it doesn't work for me,

tbh, i'm not sure it worked for my case, it's been a while since i used it.
i've saw somewhere in my researches(i've been checking out alpine), that the script should be named foo.start to run at startup (or foo.stop to run at shutdown)
it's possible that this functionality changed or stopped working when we changed from sysv init(with openrc service management) to openrc init...
but yes, the init.d approach is good, didn't think of that..

The downside is that then the script appears as a daemon started in rc-status.

i'll have to look into that, i'm not sure if there's a way of making it a "one shot" service,, ie. that runs then exits.
must say, i had to web search "IR keyboard"

[vinnie]

that the script should be named foo.start to run at startup (or foo.stop to run at shutdown)

Ah I had not tried using specific names....

must say, i had to web search "IR keyboard"

Oh thank you, you don't have to bother so much, at the end it works now, of course maybe it doesn't work precisely as I would like (i.e. plug and play) however at least it works!
The thing on the internet you can find quite a few people who had problems after updates.
Probably the most appropriate way should be by configuring /etc/rc_maps.cfg then everything would be fixed automatically when connecting the keyboard, however it is not very clear how to configure that file and if it would work.

[ncmprhnsbl]

The downside is that then the script appears as a daemon started in rc-status.

i wonder if it's simple as just exiting after:

Code: Select all

#!/usr/bin/openrc-run
description="My script to start 1044 ir keyboard before xorg"
start() {
   sleep 5
   ir-keytable -c -p mce_kbd --write=/etc/rc_keymaps/mce_key_1044.toml --sysdev=rc0 || exit 1
   exit 0
}

(just added the failure "|| exit 1" for kicks)

[vinnie]

I tried it on the fly with those two additional exits actually doesn't seem to change how the script works.
If the receiver is not connected the service exits with error and results stopped in "rc status" both with || exit 1 and without.
putting exit 1 at the end instead for "rc status" the service always result stopped even if it is successful.

I will be away for a while without a computer in the next few days, don't be alarmed, I will be back to molest this forum in a few weeks