Re: [PATCH] USB: driver for CM109 chipset

On 7/12/07, Vojtech Pavlik [off-list ref] wrote:

On Thu, Jul 12, 2007 at 10:47:22AM -0400, Dmitry Torokhov wrote:

quoted

On 7/2/07, Vojtech Pavlik [off-list ref] wrote:

quoted

On Mon, Jun 25, 2007 at 10:29:13AM -0400, Dmitry Torokhov wrote:

quoted

Hi Alfred,

On 6/25/07, Alfred E. Heggestad [off-list ref] wrote:

quoted

From: Alfred E. Heggestad <redacted>

This driver adds support for USB VoIP phones using the CM109 chipset,
such as the KIP-1000. Keypad is scanned and events are reported to
the input subsystem. The buzzer can be activated by sending SND_TONE
or SND_BELL to the input device.
The driver has been tested with linux 2.6.21.3 on i386 and AMD64,
and linux 2.6.21.1 on Broadcom BCM3302 (MIPS, OpenWRT Project)
The current patch applies cleanly and is tested on linux 2.6.22-rc4
More testing and code review is welcome..

Thank you for your patch. I have couple of comments:

- "input_dev->cdev.dev = &intf->dev;" should be "input_dev->dev.parent
= &intf->dev;"
- do not access input->private directly; use input_set_drvdata() and
input_get_drvdata() helpers.
- error handling for input_register_device();
- I guess we need KEY_POUNDSIGN because I don't like that business
with key_shift + key_3 (I did not like it in yealink either...)

Probably a KEY_KPPOUND. We should be sending the keypad keys on phones.

Hmm, they use KEY_0 through KEY_9 now.

Which results in the phone sending 'é+ěščřžýáí' instead of '0123456789'
on a Czech keyboard, which is definitely not what's intended. Similarly
for many other European keyboards.

Hmm, I uttely confused. Why when atkbd emits KEY_0 it you get 0 in the
shell (don't you?) but different result with phone keypad?

quoted

I wonder how userspace would do
if we changed these to KEY_KP0..KEY_KP9.

I think the userspace is using X keysyms in this case anyway, so it
should just work.

quoted

Do you think I could reuse 84 for KEY_KPPOUND? KEY_103RD wasn't that
popular I think...

I'll have to figure out where does KEY_103RD come from. I believe it was
defined as a key similar to KEY_102ND on specific national keyboards.
Brazil springs to mind, but I might be completely wrong. If it's not in
use today, we might as well kill it and reuse the code.

You had it in the beginning but it was removed around 2.6.2 so 84 is
free at the moment.

quoted

I also wonder if we should just expand KEY_MAX to 1023 and add all the
telephony codes (and pretty much the rest of HUT) so we have unique
events for different things...

I don't think that it'd be a huge problem to expand KEY_MAX. I'm not
entirely convinced we want to have a different event code for every
different key numbered '5'.

But they are different as in people expect different actions when they
press 5 on the keyboard, keypad, remote control and phone, don't they?
Well, maybe not... I can argue both ways I guess... It's more like
people may not want input from certain devices be used by certain
programs (like they don't like RC cause numbers to be printed in the
shell). So far they used grabbing on the devices but I don't think
this is sustainable in the long run.

-- 
Dmitry