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 platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
