linux-kernel - Re: [PATCH 2/2] eeepc-wmi: Add support for T101MT Home/Express Gate key

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTi=U2Qkqv7FKfe18f0a=8Xg0QwRX_cxFj-j7ZPC=@mail.gmail.com>
Date:	Mon, 28 Mar 2011 14:14:33 +0000
From:	Corentin Chary <corentin.chary@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Corentin Chary <corentin.chary@...il.com>,
	Chris Bagwell <chris@...bagwell.com>,
	Matthew Garrett <mjg@...hat.com>,
	acpi4asus-user@...ts.sourceforge.net,
	platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
	vojtech@...e.cz
Cc:	Seth Forshee <seth.forshee@...onical.com>
Subject: Re: [PATCH 2/2] eeepc-wmi: Add support for T101MT Home/Express Gate key

On Mon, Mar 28, 2011 at 1:46 PM, Seth Forshee
<seth.forshee@...onical.com> wrote:
> On Sun, Mar 27, 2011 at 12:11:16PM -0700, Dmitry Torokhov wrote:
>> > If we do set up auto-repeat and increase REP_DELAY, I'm guessing this
>> > would enable auto-repeat for all other keys defined in driver?  That
>> > needs to have some thought on if could have negative impact (any other
>> > keys not using auto-release?).
>>
>> Right. Right now there are 4 autoreprat options (in general):
>>
>> - hardware autorepeat (if hardware supports it);
>> - input core software autorepeat (one delay and rate per input device);
>> - driver-implemented software autorepeat - in cases when different
>>   repeat rate is needed;
>> - userspace autorepeat (like X does nowadays);
>>
>> Well, 4th option is not mutually exclusive with the other 3...
>
> Currently all the other keys are using autorelease, so the autorepeat
> setting shouldn't be affecting them at all. So the concern is whether
> enabling autorepeat could become a problem the next time some oddball
> key shows up on a machine.

As far as I know, the only key that could be like that (not yet
mapped, but I've seen it somewhere) is a "Camera Autofocus Key". For
this key we don't really care about "repeating", we just need to send
"press" and "release" events correctly, and userspace will keep
adjusting the autofocus while the key is pressed.

> Corentin, you were concerned about the loss of information to userspace,
> but it seems the only way to maintain the hardware events is to drop the
> use of sparse-keymap altogether. Do you have an opinion on how to
> proceed?

I really don't think dropping sparse-keymap for a single key on a
single model is a good idea.

On my side I'd have used another keycode for 0xea events, and reported
press and release events as they come, since it's more a "two-in-one"
key than a key with hardware autorepeat.

But since Dmitry and Chris seems to prefer the autorepeat approach
with a single key code, if it works then it's ok, we just need to set
REP_DELAY, report press and release events, and drop 0xea events.

> I'm leaning towards using the input core autorepeat, since it seems to
> get the closest to typical key behavior.

-- 
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/