[883650 ms] UsbSnoop - MyDispatchInternalIOCTL(f56b8e80) : fdo=82adb998, Irp=848e0008, IRQL=2
[883650 ms] >>> URB 68 going down >>>
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
PipeHandle = 83a38fdc [endpoint 0x00000081]
TransferFlags = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000001
TransferBuffer = 857fc078
TransferBufferMDL = 00000000
UrbLink = 00000000
[883970 ms] UsbSnoop - MyInternalIOCTLCompletion(f56b8db0) : fido=848db578, Irp=82ae9a78, Context=855c96d0, IRQL=2
[883970 ms] <<< URB 67 coming back <<<
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
PipeHandle = 83a38fdc [endpoint 0x00000081]
TransferFlags = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000001
TransferBuffer = 85768370
TransferBufferMDL = 831f13d8
00000000: 0c
UrbLink = 00000000
[883970 ms] UsbSnoop - DispatchAny(f56b7610) : IRP_MJ_INTERNAL_DEVICE_CONTROL
[883970 ms] UsbSnoop - MyDispatchInternalIOCTL(f56b8e80) : fdo=82adb998, Irp=82ae9a78, IRQL=2
[883970 ms] >>> URB 69 going down >>>
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
PipeHandle = 83a38fdc [endpoint 0x00000081]
TransferFlags = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000001
TransferBuffer = 85768370
TransferBufferMDL = 00000000
UrbLink = 00000000
On Thu, 17 May 2007, Tomas Carnecky wrote:
> Despite it's a Microsoft product, it's actually very nice and useful. A
> little pad with a few buttons and connectors for a headset. It's an USB
> device, but it doesn't represent itself as an input/HID device:
> HID device not claimed by input or hiddev
> What would be the best way to have this device appear in the system?
> Having a separate driver/device node? Or is it possible to have a small
> driver that would translate the gamevoice commands into evdev messages
> and have a new /dev/input/eventX device appear?
> I could write something like that myself, my C skills are good enough
> for that, I'd just need some advice how to use the kernel USB/evdev
> interfaces.
Hi Tomas,
the reason for hid-input not claiming the device is very probably that the
report descriptor of the device doesn't comply with what the in-kernel
HID-input driver is accepting.
Could you please
- compile the kernel with CONFIG_HID_DEBUG and send me the output you
receive when you connect the device
- if you'd like to work on it yourself, try to analyze the hid report
descriptor (it will be in the kernel log after you plug the device into
CONFIG_HID_DEBUG compiled kernel) and see what types of collection types
and usages does it contain. Please look at the code in
drivers/hid/hid-input.c:hidinput_connect() to understand which HID
devices are being claimed by the hid-input subsystem (the very first
loop over all the collections is the most important one)
--
Jiri Kosina
Jiri Kosina wrote:
> On Thu, 17 May 2007, Tomas Carnecky wrote:
>
>> Despite it's a Microsoft product, it's actually very nice and useful. A
>> little pad with a few buttons and connectors for a headset. It's an USB
>> device, but it doesn't represent itself as an input/HID device:
>> HID device not claimed by input or hiddev
>
> Could you please
>
> - compile the kernel with CONFIG_HID_DEBUG and send me the output you
> receive when you connect the device
usb 2-5: new low speed USB device using ohci_hcd and address 4
usb 2-5: configuration #1 chosen from 1 choice
drivers/hid/usbhid/hid-core.c: report descriptor (size 61, read 61) =
05 0b 09 05 a1 01 05 09 19 11 29 18 15 00 25 01 75 01 95 08 81 22 05 08
09 3a a1 02 05 09 19 11 29 17 15 00 25 01 75 01 95 07 b1 a2 c0 06 ff ff
09 01 15 00 25 01 75 01 95 01 b1 22 c0
drivers/hid/hid-core.c: report (size 1) (unnumbered)
drivers/hid/hid-core.c: report 0 (size 1) = 00
hid-debug: input Button.0011 = 0
hid-debug: input Button.0012 = 0
hid-debug: input Button.0013 = 0
hid-debug: input Button.0014 = 0
hid-debug: input Button.0015 = 0
hid-debug: input Button.0016 = 0
hid-debug: input Button.0017 = 0
hid-debug: input Button.0018 = 0
drivers/hid/hid-core.c: report (size 1) (unnumbered)
drivers/hid/hid-core.c: report 0 (size 1) = 00
hid-debug: input Button.0011 = 0
hid-debug: input Button.0012 = 0
hid-debug: input Button.0013 = 0
hid-debug: input Button.0014 = 0
hid-debug: input Button.0015 = 0
hid-debug: input Button.0016 = 0
hid-debug: input Button.0017 = 0
hid-debug: input Vendor-specific-FF.0001 = 0
INPUT[INPUT]
Field(0)
Usage(8)
Button.0011
Button.0012
Button.0013
Button.0014
Button.0015
Button.0016
Button.0017
Button.0018
Logical Minimum(0)
Logical Maximum(1)
Report Size(1)
Report Count(8)
Report Offset(0)
Flags( Variable Absolute NoPrefferedState )
FEATURE[FEATURE]
Field(0)
Logical(LED.003a)
Usage(7)
Button.0011
Button.0012
Button.0013
Button.0014
Button.0015
Button.0016
Button.0017
Logical Minimum(0)
Logical Maximum(1)
Report Size(1)
Report Count(7)
Report Offset(0)
Flags( Variable Absolute NoPrefferedState Volatile )
Field(1)
Usage(1)
Vendor-specific-FF.0001
Logical Minimum(0)
Logical Maximum(1)
Report Size(1)
Report Count(1)
Report Offset(7)
Flags( Variable Absolute NoPrefferedState )
HID device not claimed by input or hiddev
Additional info: HID device has two collections (whatever those are, I
have _no_ idea):
collection 00: type: 1, usage: 000b0005, level: 00000000
collection 01: type: 2, usage: 0008003a, level: 00000001
The usage of the first one means 'Telephony/Headset', the second one
'LEDs/Usage Selected Indicator' (IDs taken from [1]).
The culprit is the IS_INPUT_APPLICATION() macro, which only accepts
certain 'usage' types. Should it also accept this particular one, too,
or even the whole 'Telephony' group? Or maybe add a (configurable)
'quirk' to enable the GameVoice device?
tom
[1] http://www.freebsddiary.org/APC/usb_hid_usages.php
On Thu, 17 May 2007, Tomas Carnecky wrote:
> Additional info: HID device has two collections (whatever those are, I
> have _no_ idea):
If you are interested what usages and collections are (and if you are
going to write the support for this device, you probably are :) ), please
see http://www.usb.org/developers/hidpage - namely
http://www.usb.org/developers/devclass_docs/HID1_11.pdf and possibly also
http://www.usb.org/developers/devclass_docs/Hut1_12.pdf
> The culprit is the IS_INPUT_APPLICATION() macro, which only accepts
> certain 'usage' types. Should it also accept this particular one, too,
> or even the whole 'Telephony' group? Or maybe add a (configurable)
> 'quirk' to enable the GameVoice device?
We don't want neither the 'Telephony' nor 'LEDs' usages to be claimed by
the hid-input system, that seems to make a little sense.
So either the device is bogus and has broken report descriptor (which we
could fix in runtime), or it really can't be handled by hid-input (I have
no idea about the purpose and internal working of the device in question,
sorry).
Either we can fix the hiddev_connect() so that the device would be claimed
by hiddev (*) and you can write the driver for this device easily in
userland, or you could try to write generic in-kernel hid-telephony.c
handler of all telephony devices (but I doubt this is doable in a
reasonable way).
(*) I currently have no idea why this device is not claimed by hiddev
though - it seems to have all collections of type
HID_COLLECTION_APPLICATION which obviously are not IS_INPUT_APPLICATION()
... could you please put debugging output into hiddev_connect() to examine
why your device is not being claimed by hiddev?
Thanks,
--
Jiri Kosina
Jiri Kosina wrote:
> We don't want neither the 'Telephony' nor 'LEDs' usages to be claimed by
> the hid-input system, that seems to make a little sense.
I changed the IS_INPUT_APPLICATION() macro to accept 'Telephony/Headset'
and now the kernel has created a new event device node for the device
and it correctly generates evdev events if I press the keys on the pad.
(The LEDs can't be controlled, they light up if a key is pressed, they
are 'passive' from the POV of the kernel). So right now, I couldn't be
happier with how it works :)
>
> So either the device is bogus and has broken report descriptor (which we
> could fix in runtime), or it really can't be handled by hid-input (I have
> no idea about the purpose and internal working of the device in question,
> sorry).
GameVoice is used for VoIP communication between players. It consists of
a software and the small pad with eight buttons and connectors for the
headset. One of the buttons can be used to mute the microphone, the
others are labeled '1' - '4', 'TEAM', 'ALL' and 'COMMAND'. The idea is
that you can have up to four 'groups' of players and communicate only to
certain groups by 'activating' the buttons, you can also speak to your
whole team or all players. The command button is used for voice commands
(for example, you press the button, say 'throw grenade' and the software
translates it to a predefined key sequence). That's more or less how
it's supposed to work.
Google gives you lots of images if you search for 'gamevoice':
http://pcdreitz.wintotal-forum.de/pys/gamevoice.jpg
>
> Either we can fix the hiddev_connect() so that the device would be claimed
> by hiddev (*) and you can write the driver for this device easily in
> userland, or you could try to write generic in-kernel hid-telephony.c
> handler of all telephony devices (but I doubt this is doable in a
> reasonable way).
I'd much rather have this handled by hid-input, there's no reason to
have an additional driver (neither in the kernel nor in userland). It
'just works' with hid-input.
tom
On Fri, 18 May 2007, Tomas Carnecky wrote:
> > We don't want neither the 'Telephony' nor 'LEDs' usages to be claimed
> > by the hid-input system, that seems to make a little sense.
> I changed the IS_INPUT_APPLICATION() macro to accept 'Telephony/Headset'
> and now the kernel has created a new event device node for the device
> and it correctly generates evdev events if I press the keys on the pad.
> (The LEDs can't be controlled, they light up if a key is pressed, they
> are 'passive' from the POV of the kernel). So right now, I couldn't be
> happier with how it works :)
Hi Tomas,
unfortunately, I can hardly accept such a patch to go into mainline,
sorry. If the device has only Telephony/Headset application and no other
input-compatible usage, we just can't blindly pass it exclusively to
hid-input subsystem.
> GameVoice is used for VoIP communication between players. It consists of
> a software and the small pad with eight buttons and connectors for the
> headset. One of the buttons can be used to mute the microphone, the
> others are labeled '1' - '4', 'TEAM', 'ALL' and 'COMMAND'. The idea is
> that you can have up to four 'groups' of players and communicate only to
> certain groups by 'activating' the buttons, you can also speak to your
> whole team or all players. The command button is used for voice commands
> (for example, you press the button, say 'throw grenade' and the software
> translates it to a predefined key sequence). That's more or less how
> it's supposed to work.
But all this is handled actually by userspace applications, right? Or do
you want this whole functionality to go into a specialized kernel driver?
Or does this require some interaction/processing between hardware and the
driver?
> I'd much rather have this handled by hid-input, there's no reason to
> have an additional driver (neither in the kernel nor in userland). It
> 'just works' with hid-input.
Well, if the only purpose of this device is to pass status of pressed
buttons into userspace driver (which is the case, as far as I understand
it), it's just broken that it has 05 0b (i.e. Telephony/Headset) in its
report descriptor.
Either fixing the report descriptor on the fly or adding a special quirk
to force hid-input to claim the device would be needed. Would you care to
create such patch?
Or did I just get it wrong and the device has also other purposes that
should be handled by the kernel driver, than just trivial mapping of a few
buttons into corresponding input events?
Thanks,
--
Jiri Kosina
Jiri Kosina wrote:
> On Fri, 18 May 2007, Tomas Carnecky wrote:
>> GameVoice is used for VoIP communication between players. It consists of
>> a software and the small pad with eight buttons and connectors for the
>> headset. One of the buttons can be used to mute the microphone, the
>> others are labeled '1' - '4', 'TEAM', 'ALL' and 'COMMAND'. The idea is
>> that you can have up to four 'groups' of players and communicate only to
>> certain groups by 'activating' the buttons, you can also speak to your
>> whole team or all players. The command button is used for voice commands
>> (for example, you press the button, say 'throw grenade' and the software
>> translates it to a predefined key sequence). That's more or less how
>> it's supposed to work.
>
> But all this is handled actually by userspace applications, right? Or do
> you want this whole functionality to go into a specialized kernel driver?
> Or does this require some interaction/processing between hardware and the
> driver?
There's no further processing needed in the kernel. The userspace
application would receive these input events and act accordingly, like:
read data from the soundcard and send it to the VoIP server, or only
certain channels based on which buttons are currently pressed etc.
> Well, if the only purpose of this device is to pass status of pressed
> buttons into userspace driver (which is the case, as far as I understand
> it), it's just broken that it has 05 0b (i.e. Telephony/Headset) in its
> report descriptor.
>
> Either fixing the report descriptor on the fly or adding a special quirk
> to force hid-input to claim the device would be needed. Would you care to
> create such patch?
I already thought about this option (to whitelist this particular
vendor/device ID as an hid-input device), but I first wanted some
feedback on the whole situation. As for the patch, I have zero knowledge
of the hid subsystem.. but if you give me a go on this, I'll try to dig
into the code and make a patch :)
> Or did I just get it wrong and the device has also other purposes that
> should be handled by the kernel driver, than just trivial mapping of a few
> buttons into corresponding input events?
This pad has no other purposes than just having eight buttons. Mapping
these buttons into input events is all that is needed to make a useful
userspace application for it.
Considering how many users actually have this device and try to get it
working under Linux (probably only me), I wouldn't be mad if you
rejected a patch. I don't even know if I will ever write an userspace
application for it! But, I have this device lying around on my table and
in my old Windows days it was quite useful, so I'd like to share my
findings with others.
tom
On 5/17/07, Tomas Carnecky <[email protected]> wrote:
> Despite it's a Microsoft product, it's actually very nice and useful. A
> little pad with a few buttons and connectors for a headset. It's an USB
> device, but it doesn't represent itself as an input/HID device:
> HID device not claimed by input or hiddev
Is the audio part of the device USB audio class compliant?
Lee
On Fri, 18 May 2007, Lee Revell wrote:
> > Despite it's a Microsoft product, it's actually very nice and useful. A
> > little pad with a few buttons and connectors for a headset. It's an USB
> > device, but it doesn't represent itself as an input/HID device:
> > HID device not claimed by input or hiddev
> Is the audio part of the device USB audio class compliant?
Seems like the device is a bit strange - it in fact, as far as my
understanding goes (see the previous posts in this thread), doesn't have
any noticeable USB audio capabilities at all - it is just a HID device
with a few buttons (plus additional audio connector, which only "forwards"
the sound to a real audio device).
So it's just a trivial HID device with probably a bit strange report
descriptor, it seems to me. It even has only one interface (the HID one).
--
Jiri Kosina
On Sat, 19 May 2007, Tomas Carnecky wrote:
> There's no further processing needed in the kernel. The userspace
> application would receive these input events and act accordingly, like:
> read data from the soundcard and send it to the VoIP server, or only
> certain channels based on which buttons are currently pressed etc.
Thanks. Now it's clear that the HID report descriptor of the device is
just bogus, it simply makes no sense to claim this kind of device to be
'Telephony/Headset'.
> I already thought about this option (to whitelist this particular
> vendor/device ID as an hid-input device), but I first wanted some
> feedback on the whole situation. As for the patch, I have zero knowledge
> of the hid subsystem.. but if you give me a go on this, I'll try to dig
> into the code and make a patch :)
Adding a HID_QUIRK_HIDINPUT quirk makes maybe a more sense than fixing
this particular report descriptor to stop pretending that the device is
Telephony/Headset - we might in future discover that there are more
devices that have broken report descriptors and that we want to be forced
to be handled by hid-input subsystem.
So, could you please test whether the quick and untested patch below
(against 2.6.22-rc1) works as expected with the device?
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 7f81789..8696dbe 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -976,7 +976,7 @@ int hidinput_connect(struct hid_device *
if (IS_INPUT_APPLICATION(hid->collection[i].usage))
break;
- if (i == hid->maxcollection)
+ if (i == hid->maxcollection && (hid->quirks & HID_QUIRK_HIDINPUT) == 0)
return -1;
if (hid->quirks & HID_QUIRK_SKIP_OUTPUT_REPORTS)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index f6c4145..62a7f1e 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -209,6 +209,9 @@
#define USB_DEVICE_ID_MGE_UPS 0xffff
#define USB_DEVICE_ID_MGE_UPS1 0x0001
+#define USB_VENDOR_ID_MICROSOFT 0x045e
+#define USB_DEVICE_ID_SIDEWINDER_GV 0x003b
+
#define USB_VENDOR_ID_NEC 0x073e
#define USB_DEVICE_ID_NEC_USB_GAME_PAD 0x0301
@@ -290,6 +293,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_DINOVO_EDGE, HID_QUIRK_DUPLICATE_USAGES },
{ USB_VENDOR_ID_BELKIN, USB_DEVICE_ID_FLIP_KVM, HID_QUIRK_HIDDEV },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_SIDEWINDER_GV, HID_QUIRK_HIDINPUT },
{ USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_01, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_10, HID_QUIRK_IGNORE },
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 827ee74..6e45d10 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -276,6 +276,7 @@ struct hid_item {
#define HID_QUIRK_DUPLICATE_USAGES 0x00200000
#define HID_QUIRK_RESET_LEDS 0x00400000
#define HID_QUIRK_SWAPPED_MIN_MAX 0x00800000
+#define HID_QUIRK_HIDINPUT 0x01000000
/*
* This is the global environment of the parser. This information is
Jiri Kosina wrote:
> On Fri, 18 May 2007, Lee Revell wrote:
>
>>> Despite it's a Microsoft product, it's actually very nice and useful. A
>>> little pad with a few buttons and connectors for a headset. It's an USB
>>> device, but it doesn't represent itself as an input/HID device:
>>> HID device not claimed by input or hiddev
>> Is the audio part of the device USB audio class compliant?
>
> Seems like the device is a bit strange - it in fact, as far as my
> understanding goes (see the previous posts in this thread), doesn't have
> any noticeable USB audio capabilities at all - it is just a HID device
> with a few buttons (plus additional audio connector, which only "forwards"
> the sound to a real audio device).
Exactly, it isn't a 'sound' device at all. It has a USB plug and plain
old headset/microphone cables which have to be put into the soundcard.
The pad itself has connectors for the headset/microphone, but those are
simply forwarded to the soundcard (there's the 'mute' button which can
be used to mute the microphone, and a volume wheel, but that's all it
can do with the sound).
>
> So it's just a trivial HID device with probably a bit strange report
> descriptor, it seems to me. It even has only one interface (the HID one).
>
Someone at Microsoft probably thought, Hey, there's this
Telephony/Headset category, why not use that?
tom
Jiri Kosina wrote:
> On Sat, 19 May 2007, Tomas Carnecky wrote:
>> I already thought about this option (to whitelist this particular
>> vendor/device ID as an hid-input device), but I first wanted some
>> feedback on the whole situation. As for the patch, I have zero knowledge
>> of the hid subsystem.. but if you give me a go on this, I'll try to dig
>> into the code and make a patch :)
>
> Adding a HID_QUIRK_HIDINPUT quirk makes maybe a more sense than fixing
> this particular report descriptor to stop pretending that the device is
> Telephony/Headset - we might in future discover that there are more
> devices that have broken report descriptors and that we want to be forced
> to be handled by hid-input subsystem.
>
> So, could you please test whether the quick and untested patch below
> (against 2.6.22-rc1) works as expected with the device?
Applied to -rc1, rebased to -rc2, works as expected. Thanks.
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 7f81789..8696dbe 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -976,7 +976,7 @@ int hidinput_connect(struct hid_device *
> if (IS_INPUT_APPLICATION(hid->collection[i].usage))
> break;
>
> - if (i == hid->maxcollection)
> + if (i == hid->maxcollection && (hid->quirks & HID_QUIRK_HIDINPUT) == 0)
> return -1;
>
> if (hid->quirks & HID_QUIRK_SKIP_OUTPUT_REPORTS)
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index f6c4145..62a7f1e 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -209,6 +209,9 @@
> #define USB_DEVICE_ID_MGE_UPS 0xffff
> #define USB_DEVICE_ID_MGE_UPS1 0x0001
>
> +#define USB_VENDOR_ID_MICROSOFT 0x045e
> +#define USB_DEVICE_ID_SIDEWINDER_GV 0x003b
> +
> #define USB_VENDOR_ID_NEC 0x073e
> #define USB_DEVICE_ID_NEC_USB_GAME_PAD 0x0301
>
> @@ -290,6 +293,7 @@ static const struct hid_blacklist {
> { USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_DINOVO_EDGE, HID_QUIRK_DUPLICATE_USAGES },
>
> { USB_VENDOR_ID_BELKIN, USB_DEVICE_ID_FLIP_KVM, HID_QUIRK_HIDDEV },
> + { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_SIDEWINDER_GV, HID_QUIRK_HIDINPUT },
>
> { USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_01, HID_QUIRK_IGNORE },
> { USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_10, HID_QUIRK_IGNORE },
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 827ee74..6e45d10 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -276,6 +276,7 @@ struct hid_item {
> #define HID_QUIRK_DUPLICATE_USAGES 0x00200000
> #define HID_QUIRK_RESET_LEDS 0x00400000
> #define HID_QUIRK_SWAPPED_MIN_MAX 0x00800000
> +#define HID_QUIRK_HIDINPUT 0x01000000
>
> /*
> * This is the global environment of the parser. This information is
>
Tomas Carnecky wrote:
> Despite it's a Microsoft product, it's actually very nice and useful. A
> little pad with a few buttons and connectors for a headset. It's an USB
> device, but it doesn't represent itself as an input/HID device:
> HID device not claimed by input or hiddev
>
> I plugged it into a windows box and the USB protocol it uses looks very
> simple (see attachment): everytime I press one of the eight buttons, it
> sends one byte, a bitmap of the pressed buttons.
>
> What would be the best way to have this device appear in the system?
> Having a separate driver/device node? Or is it possible to have a small
> driver that would translate the gamevoice commands into evdev messages
> and have a new /dev/input/eventX device appear?
>
> I could write something like that myself, my C skills are good enough
> for that, I'd just need some advice how to use the kernel USB/evdev
> interfaces.
>
From your description it sounds as though it would be useful in
applications where voice connect was useful and visual wasn't, such as
blind users and embedded applications where a USB pluggable interface
might be useful in unusual situations.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
