SideWinder GameVoice driver

SideWinder GameVoice driver

[Tomas Carnecky]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

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.

tom

[-- Attachment #2: gamevoice.txt --]
[-- Type: text/plain, Size: 1523 bytes --]

[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

Re: SideWinder GameVoice driver

[Jiri Kosina]

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

Re: SideWinder GameVoice driver

[Tomas Carnecky]

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

Re: SideWinder GameVoice driver

[Tomas Carnecky]

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

Re: SideWinder GameVoice driver

[Jiri Kosina]

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

Re: SideWinder GameVoice driver

[Tomas Carnecky]

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

Re: SideWinder GameVoice driver

[Jiri Kosina]

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

Re: SideWinder GameVoice driver

[Tomas Carnecky]

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

Re: SideWinder GameVoice driver

[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

Re: SideWinder GameVoice driver

[Tomas Carnecky]

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
> 

Re: SideWinder GameVoice driver

[Lee Revell]

On 5/17/07, Tomas Carnecky <tom@dbservice.com> 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

Re: SideWinder GameVoice driver

[Jiri Kosina]

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

Re: SideWinder GameVoice driver

[Tomas Carnecky]

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

Re: SideWinder GameVoice driver

[Bill Davidsen]

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 <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot