Re: SideWinder GameVoice driver

[Jiri Kosina <jikos@jikos.cz>]

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
-
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/