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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/26/06, bjdouma <[email protected]> wrote:

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.


I agree but I still questinon usefullness of that data.

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


<..skipped..>

OK, so the first example illustrates that input core does not provide
"tone" data - no surprise here. The scond example proves that pcspkr
driver does not handle concurrent access very well. Still the input
core behaved exactly as it was supposed to, everythng is fine as far
as I can see.

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux