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]

Date:	Mon, 28 Mar 2011 08:46:06 -0500
From:	Seth Forshee <seth.forshee@...onical.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Corentin Chary <corentin.chary@...il.com>
Cc:	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
Subject: Re: [PATCH 2/2] eeepc-wmi: Add support for T101MT Home/Express Gate
 key

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.

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'm leaning towards using the input core autorepeat, since it seems to
get the closest to typical key behavior.

Seth

--
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/