Message-ID: <464E23CA.8040400@dbservice.com>
Date: Sat, 19 May 2007 00:08:10 +0200
From: Tomas Carnecky <tom@dbservice.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070420)
MIME-Version: 1.0
To: Jiri Kosina <jikos@jikos.cz>
CC: linux-kernel@vger.kernel.org
Subject: Re: SideWinder GameVoice driver
References: <464C5FAC.8060609@dbservice.com> <Pine.LNX.4.64.0705171623280.27422@twin.jikos.cz> <464C708C.6090808@dbservice.com> <464CA34F.8090509@dbservice.com> <Pine.LNX.4.64.0705172309240.27422@twin.jikos.cz> <464D4F31.6000100@dbservice.com> <Pine.LNX.4.64.0705182304400.27422@twin.jikos.cz>
In-Reply-To: <Pine.LNX.4.64.0705182304400.27422@twin.jikos.cz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3005
Lines: 59

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