Re: [PATCH 001/001] INPUT: new ioctl's to retrieve values of EV_REP and EV_SND event codes

[bjdouma <bjdouma@xs4all.nl>]

On Wed, Apr 26, 2006 at 10:24:32AM -0400, Dmitry Torokhov wrote:

> Are you saying that both bits were set to 0 or that you could not hear
> the tone after killing bell? If latter then it is sort of pcspkr
> problem as from input core POV tone is still active.
> 
> Btw, your patch - did it resemble something like attached?

> Index: linux/drivers/input/input.c
> ===================================================================
> --- linux.orig/drivers/input/input.c
> +++ linux/drivers/input/input.c
> @@ -155,6 +155,9 @@ void input_event(struct input_dev *dev, 
>  			if (code > SND_MAX || !test_bit(code, dev->sndbit))
>  				return;
>  
> +			if (!!test_bit(code, dev->snd) != !!value)
> +				change_bit(code, dev->snd);
> +
>  			if (dev->event) dev->event(dev, type, code, value);
>  
>  			break;

Before I made the change of dev->snd to an int array, yes it did
exactly this same thing.

Basically what I'm saying is that when you query the input driver
for the state of EV_SND, it doesn't tell you much about what tone
is actually audible, if at all.

Let me give two examples.  I am using here my program inputcntrl
that I am working on -- basically a wrapper with a parser and
interpreter around some of the uinput driver's functions (if you
want a copy of the WIP tree, let me know).

Just regard both examples as a complete session, i.e. no other
commands influencing the pcspkr are interspersed in what you see
below (/dev/input/pcspkr happens to be a symlink to /dev/input/event1).

These examples are with your latest small patch in place, the one
doing the change_bit(code, dev->snd).



Example i.

$> inputcntrl -d /dev/input/pcspkr set-snd 'bell=0;tone=0'    # part 1; reset
$> inputcntrl -d /dev/input/pcspkr set-snd bell=1
$> inputcntrl -d /dev/input/pcspkr get-snd bell,tone
SND_BELL               1
SND_TONE               0
	tone 1000Hz, see pcspkr.c

$> inputcntrl -d /dev/input/pcspkr set-snd tone=1200
$> inputcntrl -d /dev/input/pcspkr get-snd bell,tone
SND_BELL               1
SND_TONE               1
	tone 1200Hz
	note that bell remains 1
	ok, let's conclude that if bell=1 then sound=1000Hz unless tone=1

$> inputcntrl -d /dev/input/pcspkr set-snd 'bell=0;tone0'    # part 2; reset
$> inputcntrl -d /dev/input/pcspkr set-snd tone=1200
$> inputcntrl -d /dev/input/pcspkr get-snd bell,tone
SND_BELL               0
SND_TONE               1
	tone 1200Hz

$> inputcntrl -d /dev/input/pcspkr set-snd bell=1
$> inputcntrl -d /dev/input/pcspkr get-snd bell,tone
SND_BELL               1
SND_TONE               1
	tone 1000Hz
	oddness: state of EV_SND (1,1) is same as in part 1,
	only now is sound a tone of 1000Hz.
	conclusion in part 1 apparently wrong.
	so when state is (1,1), actual sound can be anything



Example ii.

$> inputcntrl -d /dev/input/pcspkr set-snd 'bell=0;tone=0'    # part 3; reset
$> inputcntrl -d /dev/input/pcspkr set-snd tone=1200
inputcntrl -d /dev/input/pcspkr get-snd bell,tone
SND_BELL               0
SND_TONE               1
	tone 1200Hz

$> inputcntrl -d /dev/input/pcspkr set-snd bell=1
$> inputcntrl -d /dev/input/pcspkr get-snd bell,tone
SND_BELL               1
SND_TONE               1
	tone 1000Hz

$> inputcntrl -d /dev/input/pcspkr set-snd bell=0
$> inputcntrl -d /dev/input/pcspkr get-snd bell,tone
SND_BELL               0
SND_TONE               1
	silence!, but SND_TONE = 1!
	on top of that, state is same as in part 2, only then
	we heard a tone of 1200Hz, now we have silence


bjd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/