lkml.org 
[lkml]   [2007]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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.

    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/

    \
     
     \ /
      Last update: 2007-05-18 23:47    [W:0.030 / U:30.184 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site