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] [day] [month] [year] [list]
Date:	Wed, 22 Oct 2014 19:45:33 +0300
From:	Giedrius Statkevicius <giedriuswork@...il.com>
To:	Éric Piel <eric.piel@...mplin-utc.net>,
	Darren Hart <dvhart@...radead.org>
CC:	platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] platform: hp_accel: add a i8042 filter to remove
 accelerometer data

On 2014.10.22 17:19, Éric Piel wrote:
> On the HP laptop I had (with HPQ0004), no fake keys were reported.
I guess this is a new "feature", then.

> It should be noted that on my laptop, the accelerometer is completely
> decoupled from the hard disk. For example, when freefall is detected,
> nothing else happens (that's why you need to run a daemon that will
> listen to the event, and park the disk head). Looking at the bug report,
> it seems your laptop does a lot behind the OS, because apparently the
> disk head is parked automatically. So maybe the scancodes is a new

I'm sorry if I made the impression that it happens automatically but
actually I am running a daemon compiled from
Documentation/laptops/freefall.c. Nothing else is running on top of
linux to park the head when a free fall is detected.

> "feature" they have added in order to more easily report what's
> happening in the back.
> Now, more related to your proposed solution: is this really what we
> want? What's wrong with the current state excepted for some warning
> messages in dmesg? Do we really want to plain drop this information

Well, these are not just a few messages but a lot of them and they clog
the system log, makes it hard to notice the actual useful information,
wastes disk space, etc.

> provided by the hardware? How about just associating the scancodes to
> meaningful keycodes? (I guess one reason no to do that is that it'd
> likely require creating new keycodes corresponding to these pretty
> atypical events in the input layer).

The free fall detection is already handled by lis3lv02d and hp_accel on
hp laptops with this feature and information is provided through
/dev/freefall so, in my opinion, the way to go is to completely drop
these scancodes.

> 
> Is there maybe some general policy about what do to hardware that
> generate such special scancodes?

Really not sure. BTW, I wonder if the same stuff happens on HPQ6007.

Thanks,
Giedrius
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ