2003-07-15 07:33:39

by B. D. Elliott

[permalink] [raw]
Subject: "Where's the Beep?" (PCMCIA/vt_ioctl-s)

On my old DELL LM laptop the -2.5 series no longer issues any beeps when
a card is inserted. The problem is in the kernel, as the test program
below (extracted from cardmgr) beeps on -2.4, but not on -2.5.

===========================================================
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/ioctl.h>

#define BEEP_TIME 150
#define BEEP_OK 1000
#define BEEP_WARN 2000
#define BEEP_ERR 4000

#include <sys/kd.h>

static void beep(unsigned int, unsigned int);

int
main(int argc, char **argv)
{
beep(500, 1000);
beep(500, 2000);
beep(500, 4000);
return 0;
}

static
void beep(unsigned int ms, unsigned int freq)
{
int fd, arg;

fd = open("/dev/tty0", O_RDWR);
if (fd < 0)
return;
arg = (ms << 16) | freq;
ioctl(fd, KDMKTONE, arg);
close(fd);
usleep(ms*1000);
}
===========================================================

--
B. D. Elliott [email protected]


2003-07-15 07:39:07

by NeilBrown

[permalink] [raw]
Subject: Re: "Where's the Beep?" (PCMCIA/vt_ioctl-s)

On Tuesday July 15, [email protected] wrote:
> On my old DELL LM laptop the -2.5 series no longer issues any beeps when
> a card is inserted. The problem is in the kernel, as the test program
> below (extracted from cardmgr) beeps on -2.4, but not on -2.5.

CONFIG_INPUT_PCSPKR

needs to be =y or =m and the module loaded.

NeilBrown

2003-07-15 10:07:33

by Junio C Hamano

[permalink] [raw]
Subject: Re: "Where's the Beep?" (PCMCIA/vt_ioctl-s)

>>>>> "NB" == Neil Brown <[email protected]> writes:

NB> On Tuesday July 15, [email protected] wrote:

>> On my old DELL LM laptop the -2.5 series no longer issues any beeps when
>> a card is inserted. The problem is in the kernel, as the test program
>> below (extracted from cardmgr) beeps on -2.4, but not on -2.5.

NB> CONFIG_INPUT_PCSPKR
NB> needs to be =y or =m and the module loaded.

That's true, but I wonder why PC Speaker is under *INPUT*
category...

2003-07-15 14:15:18

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: "Where's the Beep?" (PCMCIA/vt_ioctl-s)

On Tue, 15 Jul 2003 17:53:13 +1000, Neil Brown said:
> On Tuesday July 15, [email protected] wrote:
> > On my old DELL LM laptop the -2.5 series no longer issues any beeps when
> > a card is inserted. The problem is in the kernel, as the test program
> > below (extracted from cardmgr) beeps on -2.4, but not on -2.5.
>
> CONFIG_INPUT_PCSPKR
>
> needs to be =y or =m and the module loaded.

Argh. Is *THAT* what it was?? ;)

Will those keeping the "How-to 2.6" documents please put this one in there, near
the description of CONFIG_VT_CONSOLE and friends? ;)


Attachments:
(No filename) (226.00 B)

2003-07-15 16:35:57

by James Simmons

[permalink] [raw]
Subject: Re: "Where's the Beep?" (PCMCIA/vt_ioctl-s)


> That's true, but I wonder why PC Speaker is under *INPUT*
> category...

Because many keyboards have built in speakers.


2003-07-15 18:50:58

by Valdis Klētnieks

[permalink] [raw]
Subject: Re: "Where's the Beep?" (PCMCIA/vt_ioctl-s)

On Tue, 15 Jul 2003 17:53:13 +1000, Neil Brown said:
> On Tuesday July 15, [email protected] wrote:
> > On my old DELL LM laptop the -2.5 series no longer issues any beeps when
> > a card is inserted. The problem is in the kernel, as the test program
> > below (extracted from cardmgr) beeps on -2.4, but not on -2.5.
>
> CONFIG_INPUT_PCSPKR
>
> needs to be =y or =m and the module loaded.

Double ARGH. Now I know *why* I didn't have it.

You also need CONFIG_INPUT_MISC in order to be able to *SEE* this option in menuconfig.


Attachments:
(No filename) (226.00 B)

2003-07-17 20:54:17

by Riley Williams

[permalink] [raw]
Subject: RE: "Where's the Beep?" (PCMCIA/vt_ioctl-s)

Hi James.

>>>> On my old DELL LM laptop the -2.5 series no longer issues
>>>> any beeps when a card is inserted. The problem is in the
>>>> kernel, as the test program below (extracted from cardmgr)
>>>> beeps on -2.4, but not on -2.5.

>>> CONFIG_INPUT_PCSPKR needs to be =y (or =m and the module
>>> loaded).

>> That's true, but I wonder why PC Speaker is under *INPUT*
>> category...

> Because many keyboards have built in speakers.

What sort of logic is that !!!

The ONLY reason I can think of for treating a speaker as an INPUT
device is if that speaker is wired up in a way that allows it to
be used as a microphone, the way some baby-intercoms do. If this
is the reason, then don't expect any sort of quality from it, and
please also separate this use from the more conventional one.

Best wishes from Riley.
---
* Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14-Jul-2003

2003-07-20 23:35:14

by NeilBrown

[permalink] [raw]
Subject: RE: "Where's the Beep?" (PCMCIA/vt_ioctl-s)

On Thursday July 17, [email protected] wrote:
> Hi James.
>
> >>>> On my old DELL LM laptop the -2.5 series no longer issues
> >>>> any beeps when a card is inserted. The problem is in the
> >>>> kernel, as the test program below (extracted from cardmgr)
> >>>> beeps on -2.4, but not on -2.5.
>
> >>> CONFIG_INPUT_PCSPKR needs to be =y (or =m and the module
> >>> loaded).
>
> >> That's true, but I wonder why PC Speaker is under *INPUT*
> >> category...
>
> > Because many keyboards have built in speakers.
>
> What sort of logic is that !!!
>
> The ONLY reason I can think of for treating a speaker as an INPUT
> device is if that speaker is wired up in a way that allows it to
> be used as a microphone, the way some baby-intercoms do. If this
> is the reason, then don't expect any sort of quality from it, and
> please also separate this use from the more conventional one.

The problem here is really with the name 'INPUT'. It is not an
'input' subsytem, but rather an 'event' subsystem. It handles events
like key presses, mounts movements, speaker beeps, LED on/off etc.

It could quite reasonable also be used for APCI events like power
status changes and power-button events, but I don't know that anyone
has any plans for that.

I gather the event subsystem was conceived to help managed the wide
variety of input devices (USB, PS/2, serial, etc) and was
inadvertantly misnamed 'input'.

find linux -type f | xargs perl -pi -e 's/input/event/i'

or something like that :-)

NeilBrown