[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.023 / U:25.756 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site