I'm wondering how the generic, builtin PC-Speaker (config option
"INPUT_PCSPKR") can be used as an input device.
If it can not be used for input, why is it under the input config section:
"Device Drivers"
+ -> "Input Device Support"
+ -> "Miscellaneous devices"
+ -> "PC Speaker Support"
When booting, it is "enumerated" as an input device: (from dmesg)
input: PC Speaker as /devices/platform/pcspkr/input/input2
Just trying to figure out the rationale behind the choice...
On 02/15/2008 10:19 PM, Linda Walsh wrote:
> I'm wondering how the generic, builtin PC-Speaker (config option
> "INPUT_PCSPKR") can be used as an input device.
>
> If it can not be used for input, why is it under the input config section:
>
> "Device Drivers"
> + -> "Input Device Support"
> + -> "Miscellaneous devices"
> + -> "PC Speaker Support"
>
> When booting, it is "enumerated" as an input device: (from dmesg)
>
> input: PC Speaker as /devices/platform/pcspkr/input/input2
>
> Just trying to figure out the rationale behind the choice...
Again :)
Search archives...
On Fri, 15 Feb 2008 13:19:11 PST, Linda Walsh said:
> I'm wondering how the generic, builtin PC-Speaker (config option
> "INPUT_PCSPKR") can be used as an input device.
>
> If it can not be used for input, why is it under the input config section:
>
> "Device Drivers"
> + -> "Input Device Support"
> + -> "Miscellaneous devices"
> + -> "PC Speaker Support"
>
> When booting, it is "enumerated" as an input device: (from dmesg)
>
> input: PC Speaker as /devices/platform/pcspkr/input/input2
>
> Just trying to figure out the rationale behind the choice...
The last time around for this question, I was half-paying attention, and
the rationale sounded like "We had an input device framework, no output
device framework, and too many bad shrooms to do something comprehensible".
(This is such a *frequent* FAQ, even all the time since 2.6.0 escaped, that
maybe we need to add a 3-4 line explain to the Kconfig 'help' stanza for
CONFIG_INPUT_PCSPKR - although for some reason, INPUT_SPARCSPKR and
INPUT_M68K_BEEP don't seem to cause the same questions....)
[email protected] wrote:
> The last time around for this question, I was half-paying attention, and
> the rationale sounded like "We had an input device framework, no output
> device framework, and too many bad shrooms to do something comprehensible".
>
---
Yeah, hmm...the question I'd have then is the "only" output device
that doesn't fit into a better category?
Could there be other OUTput devices in this category? Would
renaming the category to something like "Miscellaneous I/O Devices" be
reasonable? Are keyboard status lights considered output devices?
Are "force-feedback" devices meaning devices like a rumble-gamepad
device? Isn't that providing output via feedback?
Though, I would agree, most of these devices would be thought of
as "input" devices. Dang PC-SPEAKER...um...since the driver is config'ed
with the 'input' interface, dang, it really seems like it should be an
entry under sound.
I can see the problem and I'm not familiar enough with the underlying
drivers to know how the PC-Speaker would best be handled.
> (This is such a *frequent* FAQ, even all the time since 2.6.0 escaped, that
> maybe we need to add a 3-4 line explain to the Kconfig 'help' stanza for
> CONFIG_INPUT_PCSPKR - although for some reason, INPUT_SPARCSPKR and
> INPUT_M68K_BEEP don't seem to cause the same questions....)
>
----
No matter where it is in the 'kernel configuration', it sure seems
strange (in "user land"), to see the PC-Speaker be recognized as an
input device -- especially in light of the fact that "all speakers
are microphones" (http://www.zyra.org.uk/sp-mic.htm). Would some user
wonder whether or not their speaker has some dual-circuitry to listen
as well as output (ala TV sets being 2-way video devices in Max Headroom)?