linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Reitmayr <treitmayr@devbase.at>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Linux-Input <linux-input@vger.kernel.org>
Subject: Re: Usage of new KEY_NUMERIC_* codes in an existing driver (yealink)
Date: Sat, 23 Aug 2008 14:39:16 +0200	[thread overview]
Message-ID: <1219495156.6680.4.camel@localhost> (raw)
In-Reply-To: <20080822155829.ZZRA012@mailhub.coreip.homeip.net>

Thanks Dmitry,
I will take a look at the cm109 driver to see how setkeycode/getkeycode
support is implemented and how this fits into the yealink code.
As soon as I have done that (and cleaned up a few things) I will post
the code as a patch.
Best regards,
-Thomas


Am Freitag, den 22.08.2008, 16:02 -0400 schrieb Dmitry Torokhov:
> Hi Thomas,
> 
> On Fri, Aug 22, 2008 at 07:01:28PM +0200, Thomas Reitmayr wrote:
> > Hi,
> > I am in the process of extending the existing yealink driver, partly to
> > support various other models. The existing driver as included in the
> > current kernel uses the shift key to report the keys "*" and "#", but I
> > am hesitating to do the same bad "trick" for the other models.
> > 
> > As I would like to eventually submit the extended driver upstream, what
> > is the recommended strategy in my situation regarding usage of the new
> > KEY_NUMERIC_* codes? Use them only for the new models (which would
> > result in an ugly mix), or also update the codes for the existing
> > USB-P1K model (which would break userspace programs but finally fix
> > things for some foreign keyboard layouts), 
> 
> Do you think that we need to add more keymaps to the kernel? What I
> woudl like to see is adding setkeycode/getkeycode support to yealink
> so proper keymap can be loaded from userspace (udev, hal, whatever)
> when a device is plugged into a box. USB-P1K coudl also get the new
> keymap loaded from userspace while keeping the current legacy keymap
> for existing users.
> 
> >or for the existing USB-P1K
> > model report the old and the new codes (which might look like two key
> > presses)?
> 
> No, that is not a good idea.
> 
> > Thanks for your advice,
> > -Thomas
> > 
> > PS: The updated driver is available at
> > http://www.devbase.at/svn/view.cgi/yealink-module/trunk/?root=voip
> > (still including #if's reg. kernel versions, some comments to be
> > corrected, etc.)
> > 
> 
> Would you mind posting it as a patch - it is much easier to comment on
> it in e-mail... Thanks!
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2008-08-23 12:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-22 17:01 Usage of new KEY_NUMERIC_* codes in an existing driver (yealink) Thomas Reitmayr
2008-08-22 20:02 ` Dmitry Torokhov
2008-08-23 12:39   ` Thomas Reitmayr [this message]

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=1219495156.6680.4.camel@localhost \
    --to=treitmayr@devbase.at \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).