lkml.org 
[lkml]   [2006]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 001/001] INPUT: new ioctl's to retrieve values of EV_REP and EV_SND event codes
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/

\
 
 \ /
  Last update: 2006-04-26 21:11    [W:0.110 / U:23.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site