All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alfred E. Heggestad" <aeh@db.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] input: driver for USB VoIP phones with CM109 chipset
Date: Fri, 08 Feb 2008 22:23:50 +0100	[thread overview]
Message-ID: <47ACC866.6010206@db.org> (raw)
In-Reply-To: <20080207165144.ZZRA012@mailhub.coreip.homeip.net>

Dmitry Torokhov wrote:
> Hi Alfred,
> 
> On Thu, Feb 07, 2008 at 07:38:10PM +0100, Alfred E. Heggestad wrote:
>> From: Alfred E. Heggestad <aeh@db.org>
>>
>> This driver adds support for USB VoIP phones using the CM109 chipset,
>> such as Komunikate KIP-1000 and Genius G-talk. 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 phone keymap
>> can be selected in run-time by using the "phone" module parameter.
>> The driver has been tested with linux 2.6.24 on i386, and also tested
>> to build cleanly on AMD64.
>> More testing and code review is welcome..
>>
> 
> For a long time I was sitting on the patch not sure what to do about
> the pound key, but I think we need to allocate separate keycodes for
> remote controls and phones that work regardless of users keymap.
> 

ok, let us define a new KEY_KPPOUND in linux/input.h

this also means that any application wanting to use this key must
be updated to read this new keycode.

do you want me to add a new value for KEY_KPPOUND in linux/input.h
and include it in the next patch, or can you add that value to the
tree first?


> Another item is keymap for different devices - the best way to handle
> it I think it to implement getkeycodes and setkeycodes methods for
> the input device and have alternative keymaps loaded from userspace
> instead of adding module parameters.
> 

I agree - I dont want to upgrade the driver code whenever there is a
new phone with different key-mapping.

regarding get/set-keycodes, please let me know how I should
proceed on this one..


> The rest of the driver looks great and I am sorry I was ignoring it
> for so long.
> 

no worries, I am happy to fix the remaining issues and submit new
versions of the patch..


/alfred


  reply	other threads:[~2008-02-08 21:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-07 18:38 [PATCH] input: driver for USB VoIP phones with CM109 chipset Alfred E. Heggestad
2008-02-07 21:59 ` Dmitry Torokhov
2008-02-08 21:23   ` Alfred E. Heggestad [this message]
2008-06-21 22:23   ` Alfred E. Heggestad
2008-06-24  4:59     ` Dmitry Torokhov
2008-06-25 20:07       ` Alfred E. Heggestad
2008-06-26 10:31         ` Oliver Neukum
2008-02-09 19:12 ` Pavel Machek
2008-03-03 22:07   ` Alfred E. Heggestad
2008-03-03 22:13     ` Pavel Machek
     [not found] ` <200802091023.02580.oliver@neukum.org>
2008-03-03 22:10   ` Alfred E. Heggestad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47ACC866.6010206@db.org \
    --to=aeh@db.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.