[lkml]   [2007]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SideWinder GameVoice driver
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-05-18 23:47    [W:0.064 / U:2.196 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site