[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <464D4F31.6000100@dbservice.com>
Date: Fri, 18 May 2007 09:01:05 +0200
From: Tomas Carnecky <tom@...ervice.com>
To: Jiri Kosina <jikos@...os.cz>
CC: linux-kernel@...r.kernel.org
Subject: Re: SideWinder GameVoice driver
Jiri Kosina 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 :)
>
> So either the device is bogus and has broken report descriptor (which we
> could fix in runtime), or it really can't be handled by hid-input (I have
> no idea about the purpose and internal working of the device in question,
> sorry).
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.
Google gives you lots of images if you search for 'gamevoice':
http://pcdreitz.wintotal-forum.de/pys/gamevoice.jpg
>
> Either we can fix the hiddev_connect() so that the device would be claimed
> by hiddev (*) and you can write the driver for this device easily in
> userland, or you could try to write generic in-kernel hid-telephony.c
> handler of all telephony devices (but I doubt this is doable in a
> reasonable way).
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.
tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists