On 22/10/14 15:20, Giedrius Statkevicius wrote: : > My questions are these: > - Does any system with the accelerometer whose ACPI id is HPQ0004 or > HPQ6007 run into the same issues? > - If so, what are the scancodes reported by atkbd? > - If not, then where can I find some documentation to find about this? > HP doesn't seem to have published any. > > If other people have the same issue with the same scancodes on > accelerometers with different ACPI ids we can go ahead and do what this > patch does without reacting to what hardware the user has. > > And a general question about what other people think of doing this? > Maybe there is some better way I don't know of. Hi, On the HP laptop I had (with HPQ0004), no fake keys were reported. 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 "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 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). Is there maybe some general policy about what do to hardware that generate such special scancodes? Cheers, Éric -- 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
