Help me help my brother's dog [not spam]
Hello all, Recently, my brother's dog has been trained to react to the smoke alarm - all well and good since my brother is deaf. Unfortunately, the double beep which the USB hotplugging gives when he boots (recognising mouse) and plugs in his camera also sets the dog off! So, question is, how might I go about getting rid of the beeps? I've unplugged the on-board 'speaker', but that's not really a permanent fix... Still, if it means resorting to the source I'll leave it at that! Cheers Dylan -- It is a dark day...
On Monday 31 March 2003 10:23 am, Dylan wrote:
Hello all,
Recently, my brother's dog has been trained to react to the smoke alarm - all well and good since my brother is deaf. Unfortunately, the double beep which the USB hotplugging gives when he boots (recognising mouse) and plugs in his camera also sets the dog off!
So, question is, how might I go about getting rid of the beeps? I've unplugged the on-board 'speaker', but that's not really a permanent fix... Still, if it means resorting to the source I'll leave it at that!
So what's wrong with unplugging the speaker? There might be lots of boops and beeps from other places than just the boot process that could set him off.. Since your brother doesn't need the speaker, I would think that would be the best solution.
Cheers Dylan
-- +----------------------------------------------------------------------------+ + Bruce S. Marshall bmarsh@bmarsh.com Bellaire, MI 03/31/03 10:31 + +----------------------------------------------------------------------------+ "You might be a high-tech Red-neck if: you can remember 7 computer passwords but not your anniversary"
On Monday 31 March 2003 16:32, Bruce Marshall wrote:
On Monday 31 March 2003 10:23 am, Dylan wrote:
Hello all,
Recently, my brother's dog has been trained to react to the smoke alarm - all well and good since my brother is deaf. Unfortunately, the double beep which the USB hotplugging gives when he boots (recognising mouse) and plugs in his camera also sets the dog off!
So, question is, how might I go about getting rid of the beeps? I've unplugged the on-board 'speaker', but that's not really a permanent fix... Still, if it means resorting to the source I'll leave it at that!
So what's wrong with unplugging the speaker? There might be lots of boops and beeps from other places than just the boot process that could set him off.. Since your brother doesn't need the speaker, I would think that would be the best solution.
Well, nothing in principle I suppose, short of diagnosing certain (admittedly unlikely) BIOS errors. But I consider it a sledgehammer solution. It's tantamount to saying, "oh, my program's got a bug due to the hardware: better redign the computer". Anyway, discovering the software solution will teach me more about how the system works. Cheers Dylan -- It is a dark day...
Recently, my brother's dog has been trained to react to the smoke alarm - all well and good since my brother is deaf. Unfortunately, the double beep which the USB hotplugging gives when he boots (recognising mouse) and plugs in his camera also sets the dog off!
Are we allowed to laugh at that? I couldn't help myself...
So, question is, how might I go about getting rid of the beeps? I've unplugged the on-board 'speaker', but that's not really a permanent fix... Still, if it means resorting to the source I'll leave it at that!
Does it still sound if you mute the speaker? When the battery in my laptop is low I turn the speaker volume right down because it beeps through the (surprisingly powerful) speaker to warn of a fading battery. (It did it on a plane once, at night when just about everyone else was asleep. At full volume, the high pitched squeal woke just about everyone in the cabin. <blush>). -- "...our desktop is falling behind stability-wise and feature wise to KDE ...when I went to Mexico in December to the facility where we launched gnome, they had all switched to KDE3." - Miguel de Icaza, March 2003
On Monday 31 March 2003 16:33, Derek Fountain wrote:
Recently, my brother's dog has been trained to react to the smoke alarm - all well and good since my brother is deaf. Unfortunately, the double beep which the USB hotplugging gives when he boots (recognising mouse) and plugs in his camera also sets the dog off!
Are we allowed to laugh at that? I couldn't help myself...
I did when he told me!
So, question is, how might I go about getting rid of the beeps? I've unplugged the on-board 'speaker', but that's not really a permanent fix... Still, if it means resorting to the source I'll leave it at that!
Does it still sound if you mute the speaker? When the battery in my laptop is low I turn the speaker volume right down because it beeps through the (surprisingly powerful) speaker to warn of a fading battery. (It did it on a plane once, at night when just about everyone else was asleep. At full volume, the high pitched squeal woke just about everyone in the cabin. <blush>).
It's the little piezo-disc 'speaker' thing which makes the console beep, so I don't see any way to mute it...? Dylan -- It is a dark day...
On Monday 31 March 2003 7:33 am, Derek Fountain wrote:
Recently, my brother's dog has been trained to react to the smoke alarm - all well and good since my brother is deaf. Unfortunately, the double beep which the USB hotplugging gives when he boots (recognising mouse) and plugs in his camera also sets the dog off!
Are we allowed to laugh at that? I couldn't help myself...
So, question is, how might I go about getting rid of the beeps? I've unplugged the on-board 'speaker', but that's not really a permanent fix... Still, if it means resorting to the source I'll leave it at that!
Does it still sound if you mute the speaker? When the battery in my laptop is low I turn the speaker volume right down because it beeps through the (surprisingly powerful) speaker to warn of a fading battery. (It did it on a plane once, at night when just about everyone else was asleep. At full volume, the high pitched squeal woke just about everyone in the cabin. <blush>).
That would probably help, but I think what the Bruce is looking for is a way to keep sound in general working, but either mute or otherwise change the sound generated by USB plug/unplug events. Is that correct, Bruce? OTOH, I don't have a solution on hand, but I'll try to do a bit o' research for you... -Nick
On Monday 31 March 2003 18:50, Nick LeRoy wrote: <SNIP>
That would probably help, but I think what the Bruce is looking for is a way to keep sound in general working, but either mute or otherwise change the sound generated by USB plug/unplug events. Is that correct, Bruce?
That's it, but my name's Dylan!
OTOH, I don't have a solution on hand, but I'll try to do a bit o' research for you...
-Nick
Dylan -- It is a dark day...
On Monday 31 March 2003 9:50 am, Nick LeRoy wrote:
On Monday 31 March 2003 7:33 am, Derek Fountain wrote:
Recently, my brother's dog has been trained to react to the smoke alarm - all well and good since my brother is deaf. Unfortunately, the double beep which the USB hotplugging gives when he boots (recognising mouse) and plugs in his camera also sets the dog off!
Are we allowed to laugh at that? I couldn't help myself...
So, question is, how might I go about getting rid of the beeps? I've unplugged the on-board 'speaker', but that's not really a permanent fix... Still, if it means resorting to the source I'll leave it at that!
Does it still sound if you mute the speaker? When the battery in my laptop is low I turn the speaker volume right down because it beeps through the (surprisingly powerful) speaker to warn of a fading battery. (It did it on a plane once, at night when just about everyone else was asleep. At full volume, the high pitched squeal woke just about everyone in the cabin. <blush>).
That would probably help, but I think what the Bruce is looking for is a way to keep sound in general working, but either mute or otherwise change the sound generated by USB plug/unplug events. Is that correct, Bruce?
OTOH, I don't have a solution on hand, but I'll try to do a bit o' research for you...
Hmmm.... It looks like it should involve a couple of quick hacks to /etc/hotplug/hotplug.functions -Nick
On Mon, 31 Mar 2003 09:53:58 -0800 Nick LeRoy <nleroy@cs.wisc.edu> wrote:
Recently, my brother's dog has been trained to react to the smoke alarm - all well and good since my brother is deaf. Unfortunately, the double beep which the USB hotplugging gives when he boots (recognising mouse) and plugs in his camera also sets the dog off!
That would probably help, but I think what the Bruce is looking for is a way to keep sound in general working, but either mute or otherwise change the sound generated by USB plug/unplug events. Is that correct, Bruce?
OTOH, I don't have a solution on hand, but I'll try to do a bit o' research for you...
There is a setting in .Xdefaults called "VisualBell" I havn't messed with it, but from what I hear, it changes the beep to a flash in the xterm. I don't know if that with help with the usb signal though. .Xdefaults xterm*VisualBell: true I bet there is a way to set it for the console too. I would do a web search for Visual Bell. -- use Perl; #powerful programmable prestidigitation
On Monday 31 March 2003 18:32, zentara wrote:
On Mon, 31 Mar 2003 09:53:58 -0800
Nick LeRoy <nleroy@cs.wisc.edu> wrote:
Recently, my brother's dog has been trained to react to the smoke alarm - all well and good since my brother is deaf. Unfortunately, the double beep which the USB hotplugging gives when he boots (recognising mouse) and plugs in his camera also sets the dog off!
That would probably help, but I think what the Bruce is looking for is a way to keep sound in general working, but either mute or otherwise change the sound generated by USB plug/unplug events. Is that correct, Bruce?
OTOH, I don't have a solution on hand, but I'll try to do a bit o' research for you...
There is a setting in .Xdefaults called "VisualBell"
I havn't messed with it, but from what I hear, it changes the beep to a flash in the xterm. I don't know if that with help with the usb signal though.
.Xdefaults xterm*VisualBell: true
Yes, we did that fight from the start, but it only catches the bell events for X.
I bet there is a way to set it for the console too. I would do a web search for Visual Bell.
Good idea. -- It is a dark day...
On Monday 31 March 2003 18:53, Nick LeRoy wrote: <SNIP>
Hmmm.... It looks like it should involve a couple of quick hacks to /etc/hotplug/hotplug.functions
OK, I found a section: do_beep () { test "$HOTPLUG_BEEP" = yes || return debug_mesg "BeepInfo: TYPE=$TYPE ACTION=$ACTION DRIVERS=$DRIVERS" \ "DEVICE=$DEVICE" if [ "$1" = 0 ] ; then echo -en "\033[10;1200]\a\033[10;262]" > /dev/console else echo -en "\033[10;300]\a\033[10;262]" > /dev/console debug_mesg "low beep caused by retval $1" fi } which I edited to look like this: do_beep () { test "$HOTPLUG_BEEP" = yes || return debug_mesg "BeepInfo: TYPE=$TYPE ACTION=$ACTION DRIVERS=$DRIVERS" \ "DEVICE=$DEVICE" if [ "$1" = 0 ] ; then # echo -en "\033[10;1200]\a\033[10;262]" > /dev/console else # echo -en "\033[10;300]\a\033[10;262]" > /dev/console debug_mesg "low beep caused by retval $1" fi } thinking this would simply stop the BEEP being sent to the console. Well, no BEEPs. But no mouse either! Obviously I'm missing something here, but what? Cheers Dylan -- It is a dark day...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 31 March 2003 10:11 am, Dylan wrote:
On Monday 31 March 2003 18:53, Nick LeRoy wrote: <SNIP>
Hmmm.... It looks like it should involve a couple of quick hacks to /etc/hotplug/hotplug.functions
OK, I found a section:
do_beep () { test "$HOTPLUG_BEEP" = yes || return [...]
This should have been a major clue -- $HOTPLUG_BEEP is a reference to an environment variable, and the implication here is that if it isn't set to "yes", then the script will return immediately. (no changes to the script are needed, just somehow set HOTPLUG_BEEP to a non "yes" value) I believe this is set in the "sysconfig editor" [under YAST]. A quick grep shows that this is actually configured/defined/explained/whatever in the file /etc/sysconfig/hotplug, which reads in part: # If you like acoustical feedback at plugin then set this to 'yes'. It will # beep like cardmgr does: Two beeps, one for module loading another for # interface setup. High beep at success, low beep at failure. HOTPLUG_BEEP=yes so changing this line and running SuSEconfig should disable the beep [and it should survive the next "update" of your system where a change to .../hotplug.functions would get overwritten] - -- Yet another Blog: http://osnut.homelinux.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: http://osnut.homelinux.net/TomEmerson.asc iD8DBQE+iIogV/YHUqq2SwsRArfQAJ0TGpqhkUfM6Rr2n3dpOu/7STctjgCePrzD rVliqOP06NleI2oGWEfocwY= =N1c0 -----END PGP SIGNATURE-----
On Monday 31 March 2003 19:34, Tom Emerson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 31 March 2003 10:11 am, Dylan wrote:
On Monday 31 March 2003 18:53, Nick LeRoy wrote: <SNIP>
Hmmm.... It looks like it should involve a couple of quick hacks to /etc/hotplug/hotplug.functions
OK, I found a section:
do_beep () { test "$HOTPLUG_BEEP" = yes || return
[...]
This should have been a major clue -- $HOTPLUG_BEEP
You are SOOO right! now you mention it I see it! Wood, trees, where? Dylan -- It is a dark day...
On Monday 31 March 2003 19:34, Tom Emerson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 31 March 2003 10:11 am, Dylan wrote:
On Monday 31 March 2003 18:53, Nick LeRoy wrote: <SNIP>
Hmmm.... It looks like it should involve a couple of quick hacks to /etc/hotplug/hotplug.functions
OK, I found a section:
do_beep () { test "$HOTPLUG_BEEP" = yes || return
[...]
This should have been a major clue -- $HOTPLUG_BEEP is a reference to an environment variable, and the implication here is that if it isn't set to "yes", then the script will return immediately. (no changes to the script are needed, just somehow set HOTPLUG_BEEP to a non "yes" value)
I believe this is set in the "sysconfig editor" [under YAST]. A quick grep shows that this is actually configured/defined/explained/whatever in the file /etc/sysconfig/hotplug, which reads in part:
# If you like acoustical feedback at plugin then set this to 'yes'. It will # beep like cardmgr does: Two beeps, one for module loading another for # interface setup. High beep at success, low beep at failure. HOTPLUG_BEEP=yes
so changing this line and running SuSEconfig should disable the beep [and it should survive the next "update" of your system where a change to .../hotplug.functions would get overwritten]
My question remains tho - why did commenting out those lines make the mouse fail to initialize? Dylan -- It is a dark day...
Dylan wrote:
My question remains tho - why did commenting out those lines make the mouse fail to initialize?
The reason it failed is that an if statement in a shell script needs something to execute. You commented out the only executible clause in the script. If you need to do something like that in the future, the following works: if (<some condition>) then ; # Commented out code else . . fi Regards, Paul Varner
On Monday 31 March 2003 20:51, Paul Varner wrote:
Dylan wrote:
My question remains tho - why did commenting out those lines make the mouse fail to initialize?
The reason it failed is that an if statement in a shell script needs something to execute. You commented out the only executible clause in the script. If you need to do something like that in the future, the following works:
if (<some condition>) then ; # Commented out code else . . fi
OK, I didn't know that, but I'm still confused as to why the detection and initialization failed. Dylan -- It is a dark day...
Dylan wrote:
On Monday 31 March 2003 20:51, Paul Varner wrote:
Dylan wrote:
My question remains tho - why did commenting out those lines make the mouse fail to initialize?
The reason it failed is that an if statement in a shell script needs something to execute. You commented out the only executible clause in the script. If you need to do something like that in the future, the following works:
if (<some condition>) then ; # Commented out code else . . fi
OK, I didn't know that, but I'm still confused as to why the detection and initialization failed.
Because the script had a syntax error. To the shell interpeter that portion of the script now looked like: if (whatever) then else code fi instead of: if (whatever) then code else code fi Regards, Paul
On Monday 31 March 2003 21:56, Dylan wrote:
OK, I didn't know that, but I'm still confused as to why the detection and initialization failed.
I don't think it failed, I think it never ran at all. I suspect the script hit the faulty if-statement and exited with an error. Try this, for example #!/bin/bash do_beep(){ if [ "$1" = 0 ]; then echo foo fi } echo script starting do_beep echo script ending If you run this script, you get the output script starting script ending Now try commenting out the "echo foo" line. You'll see the script doesn't output anything except an error message "unexpected token fi". I think somewhere in your boot messages, you'll see a similar error message.
You can place a single ; inside the block. if [ something ] ; then ; fi On Monday 31 March 2003 03:19 pm, Anders Johansson wrote:
On Monday 31 March 2003 21:56, Dylan wrote:
OK, I didn't know that, but I'm still confused as to why the detection and initialization failed.
I don't think it failed, I think it never ran at all. I suspect the script hit the faulty if-statement and exited with an error. Try this, for example
#!/bin/bash
do_beep(){ if [ "$1" = 0 ]; then echo foo fi
}
echo script starting do_beep echo script ending
If you run this script, you get the output
script starting script ending
Now try commenting out the "echo foo" line. You'll see the script doesn't output anything except an error message "unexpected token fi". I think somewhere in your boot messages, you'll see a similar error message.
~ my puter does not beep, because the tiny speaker is unplugged on motherboard best wishes ____________ sent on Linux ____________
On Tuesday 01 April 2003 03:36, mike wrote:
You can place a single ; inside the block.
if [ something ] ; then ; fi
Sure. But the idea of my example was to demonstrate that if you do what Dylan did, no part of the script gets run. Not even the correct bits before the error.
On Monday 31 March 2003 10:53 am, Dylan wrote:
On Monday 31 March 2003 19:34, Tom Emerson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 31 March 2003 10:11 am, Dylan wrote:
On Monday 31 March 2003 18:53, Nick LeRoy wrote: <SNIP>
Hmmm.... It looks like it should involve a couple of quick hacks to /etc/hotplug/hotplug.functions
OK, I found a section:
do_beep () { test "$HOTPLUG_BEEP" = yes || return
[...]
This should have been a major clue -- $HOTPLUG_BEEP is a reference to an environment variable, and the implication here is that if it isn't set to "yes", then the script will return immediately. (no changes to the script are needed, just somehow set HOTPLUG_BEEP to a non "yes" value)
I believe this is set in the "sysconfig editor" [under YAST]. A quick grep shows that this is actually configured/defined/explained/whatever in the file /etc/sysconfig/hotplug, which reads in part:
# If you like acoustical feedback at plugin then set this to 'yes'. It will # beep like cardmgr does: Two beeps, one for module loading another for # interface setup. High beep at success, low beep at failure. HOTPLUG_BEEP=yes
so changing this line and running SuSEconfig should disable the beep [and it should survive the next "update" of your system where a change to .../hotplug.functions would get overwritten]
My question remains tho - why did commenting out those lines make the mouse fail to initialize?
My guess would be a phase of moon issue... Try it again and verify that it works w/o that change, and breaks with it. My guess is that for some random reason it just happenned to fail on your test. -Nick
* Dylan <dylan@dylan.me.uk> (Mon, Mar 31, 2003 at 07:11:05PM +0100)
On Monday 31 March 2003 18:53, Nick LeRoy wrote: <SNIP>
Hmmm.... It looks like it should involve a couple of quick hacks to /etc/hotplug/hotplug.functions
OK, I found a section:
do_beep () { test "$HOTPLUG_BEEP" = yes || return debug_mesg "BeepInfo: TYPE=$TYPE ACTION=$ACTION DRIVERS=$DRIVERS" \ "DEVICE=$DEVICE" if [ "$1" = 0 ] ; then echo -en "\033[10;1200]\a\033[10;262]" > /dev/console else echo -en "\033[10;300]\a\033[10;262]" > /dev/console debug_mesg "low beep caused by retval $1" fi }
which I edited to look like this:
do_beep () { test "$HOTPLUG_BEEP" = yes || return debug_mesg "BeepInfo: TYPE=$TYPE ACTION=$ACTION DRIVERS=$DRIVERS" \ "DEVICE=$DEVICE" if [ "$1" = 0 ] ; then # echo -en "\033[10;1200]\a\033[10;262]" > /dev/console else # echo -en "\033[10;300]\a\033[10;262]" > /dev/console debug_mesg "low beep caused by retval $1" fi }
thinking this would simply stop the BEEP being sent to the console. Well, no BEEPs. But no mouse either!
Obviously I'm missing something here, but what?
What's wrong with just setting HOTPLUG_BEEP to no ? I assume that's suse 8.X , there is no HOTPLUG_BEEP in 7.3 Kind regards, -- Gerhard den Hollander Phone :+31-10.280.1515 Global IT Support manager Direct:+31-10.280.1539 Jason Geosystems BV Fax :+31-10.280.1511 (When calling please note: we are in GMT+1) gdenhollander@jasongeo.com POBox 1573 visit us at http://www.jasongeo.com 3000 BN Rotterdam JASON.......#1 in Reservoir Characterization The Netherlands This e-mail and any attachment is/are intended solely for the named addressee(s) and may contain information that is confidential and privileged. If you are not the intended recipient, we request that you do not disseminate, forward, distribute or copy this e-mail message. If you have received this e-mail message in error, please notify us immediately by telephone and destroy the original message.
Hi Dylan,
Recently, my brother's dog has been trained to react to the smoke alarm - all well and good since my brother is deaf. Unfortunately, the double beep which the USB hotplugging gives when he boots (recognising mouse) and plugs in his camera also sets the dog off!
So, question is, how might I go about getting rid of the beeps? I've unplugged the on-board 'speaker', but that's not really a permanent fix... Still, if it means resorting to the source I'll leave it at that!
The gurus here will give you the technical responses, which will leave you with some ideas, however I am on the dog's side. Thinking laterally, the dog has been trained to respond to the smoke alarm and obviously has learnt the basics. There will be other beeps and sounds which will also cause him to also respond. If you extend the training you should be able to have him respond after a few beeps, not the first one. So that he doesn't respond to the unplugging or plug in, but he responds to the smoke alarm that continues beyond a couple of beeps. At present he would also probably respond to the low battery "single beep" of the smoke alarm ! So it really depends on what you want, I am sure the dog will fit in to the plan. Good luck, John This email has been pre-scanned using the latest Anti Virus software for your peace of mind.
Thank you all for the proddings! The config variable does the trick nicely (as it should!) What's more, I've learnt a bit more about scripts - yeehaa! Dylan On Monday 31 March 2003 16:23, Dylan wrote:
Hello all,
Recently, my brother's dog has been trained to react to the smoke alarm - all well and good since my brother is deaf. Unfortunately, the double beep which the USB hotplugging gives when he boots (recognising mouse) and plugs in his camera also sets the dog off!
So, question is, how might I go about getting rid of the beeps? I've unplugged the on-board 'speaker', but that's not really a permanent fix... Still, if it means resorting to the source I'll leave it at that!
Cheers Dylan
-- It is a dark day...
-- It is a dark day...
participants (12)
-
Anders Johansson -
Bruce Marshall -
Derek Fountain -
Dylan -
Gerhard den Hollander -
John -
mike -
Nick LeRoy -
Paul Varner -
pinto -
Tom Emerson -
zentara