You are not logged in.
why
when no-de users plug in usb, printer, or mouse, there is no sound. we dont know whether they are ready or not.
how
this might be the most light-weight implementation; there is no daemon! I use systemd and udev to keep track of the insert and remove(yes! we also have remove sound) events.
install
like all my other apps for linux users, there is no config at all. after you install the app, you are done.
https://aur.archlinux.org/packages/device-sound-git/
plug in your mouse or usb, and hear it!
if you like it, dont forget to vote. and check out my other apps too
"After you do enough distro research, you will choose Arch."
Offline
Very nice work first try, first vote, love it!
Thanks!
What about using a non-windows8 (un)plug sound? I like it, but it makes me recall about my windows pc!
ps: Can you help me understand what the .service does? I mean, it hasn't to be enabled, it is only called from within the udev rules. It wasn't enough to call your /usr/bin/device-sound script with an argument to tell it to play the plug or unplug sound? May be i misunderstood....by the way, really thanks! Great work, and nice idea!
Last edited by nierro (2013-06-17 10:23:54)
Offline
@falconindy: that was what i thought, but i'm not that good at scripting, so i believed there was actually a good reason.
Offline
@falconindy
udev does not allow long running process. after 3 or 5 secs, the process will be killed. Using systemd forking seems to be the most elegant way to work around this.
@nierro
the idea is simple:
1. udev gets the event
2. delegate the task to systemd (workaround)
3. systemd calls device-sound to make the sound
"After you do enough distro research, you will choose Arch."
Offline
@Taylorchu: thanks for the explanation!
So, will you change default sound?
By the way, again, thank you for providing us this package!
Offline
@falconindy
udev does not allow long running process. after 3 or 5 secs, the process will be killed. Using systemd forking seems to be the most elegant way to work around this.
Are you playing a notification sound or an entire opera? I'm aware of the limitations of processes spawned by udev...
@nierro
the idea is simple:
1. udev gets the event
2. delegate the task to systemd (workaround)
3. systemd calls device-sound to make the sound
If you're afraid of cutting off your soundtrack after the cgroup container timeout, you're still doing it wrong.
1) Use ENV{SYSTEMD_WANTS}, not RUN+=
2) Use Type=oneshot, not forking. This lets you avoid your hack of calling "systemctl restart".
3) Call aplay directly from the service. Really, your script has no logic that couldn't be handled directly in the service.
Offline
@falconindy
1. I read the doc about systemd again, and I realize that "Type=forking" is not the forking I thought. Systemd's implementation already has "forking", so using oneshot might be cleaner.
2. RemainAfterExit is by default no. so both start and restart are fine. ENV{SYSTEMD_WANTS} is buggy; it does not catch "remove event". (maybe it is just for me.)
3. why not make it flexible?
BTW, thanks for pointing that out..I feel that systemd project needs to expand the documentation (add some examples).
do you develop systemd?
Last edited by taylorchu (2013-06-18 06:30:51)
"After you do enough distro research, you will choose Arch."
Offline