From: "Giel de Nijs" <giel@caffeinetrip.com>
To: Dmitry Torokhov <dtor@insightbb.com>
Cc: linux-kernel@vger.kernel.org, Vojtech Pavlik <vojtech@suse.cz>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Matt Domsch <matt_domsch@dell.com>,
Rezwanul Kabir <rezwanul_kabir@dell.com>,
linux-input@atrey.karlin.mff.cuni.cz
Subject: Re: [patch 0/2] [PATCH] input: correctly handle keys without hardware release event
Date: Mon, 14 May 2007 08:16:29 +0200 [thread overview]
Message-ID: <929318d30705132316w300fe8e4ue98a02e85cd82cfb@mail.gmail.com> (raw)
In-Reply-To: <200705132344.19311.dtor@insightbb.com>
On 5/14/07, Dmitry Torokhov <dtor@insightbb.com> wrote:
> > This patch adds a soft release key mask to input_dev, to enable keyboard
> > drivers to determine which keys never generate a hardware release event and
> > hence add a release event after every press event of such keys. The mask is
> > controlled by ioctls.
>
> I don't think we want to add all the infrastructure for the benefit of single
> driver. Can we add a quirk to atkbd and activate it based on DMI?
As the atkbd.c driver already had a work-around for exactly the same problem
with some (I think) Korean keyboards (KEY_HANGEUL and KEY_HANJA), adding
this infrastructure (well, one pointer and two ioctls) seemed a logical step.
If you prefer a hack just in atkbd.c and activate it on Dell laptops, I see
what I can do. The problem with that is that I don't know the scancodes of
all keys on all models (and future models) that exhibit this behaviour. I'll
implement what I know, though (it'll take some time because I'll be
travelling quite a lot very soon).
Greetings,
Giel
prev parent reply other threads:[~2007-05-14 6:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-11 17:23 [patch 0/2] [PATCH] input: correctly handle keys without hardware release event Giel de Nijs
2007-05-11 17:23 ` [patch 1/2] input: add soft release key mask to keyboard driver Giel de Nijs
2007-05-11 17:23 ` [patch 2/2] input: add ioctls to console for soft release mask read/write Giel de Nijs
2007-05-14 3:44 ` [patch 0/2] [PATCH] input: correctly handle keys without hardware release event Dmitry Torokhov
2007-05-14 6:16 ` Giel de Nijs [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=929318d30705132316w300fe8e4ue98a02e85cd82cfb@mail.gmail.com \
--to=giel@caffeinetrip.com \
--cc=dtor@insightbb.com \
--cc=linux-input@atrey.karlin.mff.cuni.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=matt_domsch@dell.com \
--cc=mjg59@srcf.ucam.org \
--cc=rezwanul_kabir@dell.com \
--cc=vojtech@suse.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).