linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dtor@insightbb.com>
To: Carlos Corbacho <cathectic@gmail.com>
Cc: linux-input@atrey.karlin.mff.cuni.cz,
	"Éric Piel" <Eric.Piel@tremplin-utc.net>
Subject: Re: wistron_btns - Is polling always required?
Date: Fri, 20 Jul 2007 00:06:35 -0400	[thread overview]
Message-ID: <200707200006.35795.dtor@insightbb.com> (raw)
In-Reply-To: <f7o5fo$b3c$1@sea.gmane.org>

Hi Carlos,

On Thursday 19 July 2007 13:03, Carlos Corbacho wrote:
> I've been looking over the wistron_btns driver (again), and am rather
> puzzled by some of the latest additions to it.
> 
> In particular, laptops such as the 3020 and 5020 series (both identical, bar
> different AMD processors) are being polled to map their extra keys -
> however, both these laptops (and, AFAIK, most modern Acer laptops since at
> least 2005) do _not_ require this - all the extra keys are already emitting
> scancodes.
> 
> From what I can see, it would be surely better to drop the BIOS probing and
> polling on the newer laptops, and then either:
> 
> A) Use the setkeycode ioctl for these particular laptops
> 
> Pro: 
> For users with x86-64 Acer laptops that produce scancodes, wistron_btns
> could be made to work, since the BIOS probing and polling code is now
> unnecessary.
> 
> Con:
> Should setkeycode really be used in a kernel driver? (I don't know what the
> official policy is here)
> 
> B) Let userspace map the scancodes to keycodes (such as HAL 0.5.10 and above
> is doing at the moment) (i.e. cut back wistron_btns to _just_ the older
> models that really do need polling to generate keycodes).
> 
> Pro:
> Don't have to update the kernel for every single new Acer model and keyboard
> layout found (in the case of HAL, it would just be the hal-info package,
> which contains all this kind of information).
> 
> Con:
> Not everyone may be using HAL - potential for inconsistency in keyboard
> mappings.
> 

I was not aware that these models can deliver events for hotkeys via
atkbd. I think option B is best since interrupt-driven mode is always
better than polling. I am CC-ing Eric Piel who did most of the work
on new models support in wistron_btns.

-- 
Dmitry

  reply	other threads:[~2007-07-20  4:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-19 17:03 wistron_btns - Is polling always required? Carlos Corbacho
2007-07-20  4:06 ` Dmitry Torokhov [this message]
2007-07-22 14:14   ` Carlos Corbacho
2007-07-25 21:41     ` Éric Piel
2007-07-27 11:20       ` Carlos Corbacho
2007-07-27 13:07         ` Éric Piel
2007-07-27 13:27           ` Carlos Corbacho

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=200707200006.35795.dtor@insightbb.com \
    --to=dtor@insightbb.com \
    --cc=Eric.Piel@tremplin-utc.net \
    --cc=cathectic@gmail.com \
    --cc=linux-input@atrey.karlin.mff.cuni.cz \
    /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).