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...

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 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 Mon, 31 Mar 2003 09:53:58 -0800 Nick LeRoy 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: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...

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...

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

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

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.

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.

* Dylan (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.