Ignore custom keyboard scan codes

[nvaccessAuto]

Reported by jteh on 2013-08-25 01:37
Some computer manufacturers use custom keyboard scan codes to indicate custom buttons or other behaviour; e.g. wireless toggle, screen brightness, gyroscope movement, etc. This causes multiple issues:

• Just as for most other key presses, NVDA silences speech when these are detected. This is okay for buttons, but is a major annoyance for gyroscope movement which can happen unintentionally.
• Some of these scan codes are scan codes for normal keys (characters, etc.) but with the extended flag. Unfortunately, GetKeyNameText, which we use as a fallback when we can't get a name for the key via other means, ignores the extended flag unless it is significant for a standard key. In one case, this means that gyroscope movement is treated as a character, which triggers quick navigation in browse mode.

From what I've been able to determine, these custom scan codes have no vk code mapping, so they get a vk code of 0xff. If they have no vk code, this should mean Windows doesn't know about them, in which case we almost certainly don't care about them.

Therefore, we should ignore key presses with a vk code of 0xff. I haven't decided whether we should just avoid generating gestures for them altogether or whether we should generate gestures but avoid silencing speech and give them a name which indicates they are unknown.

[nvaccessAuto]

Comment 1 by Brendon22 on 2013-08-25 07:12
Hello,

A Notebook that does this. Is the HP ProBook 4340s just for the record.

[nvaccessAuto]

Comment 3 by James Teh <jamie@... on 2013-08-26 01:00
In [f9abcca]:

Physical movement and other events on some newer computers are no longer treated as inappropriate key presses. Previously, this silenced speech and sometimes triggered NVDA commands.

Some devices notify about these events using non-standard scan codes, for which GetKeyNameText returns inappropriate names. These report a vk code of 0xFF, so handle this appropriately.
These will now report as unknown in input help mode and can be mapped as gestures if desired using the log.
Re #3468.

[nvaccessAuto]

Comment 4 by James Teh <jamie@... on 2013-08-26 01:03
In [38791e8]:

Merge branch 't3468' into next

Incubates #3468.

Changes:
Added labels: incubating

[nvaccessAuto]

Comment 6 by ondrosik on 2013-08-27 19:33
It works here in my HP probook 4340S e. g. NVDA doesn't move to the next list on the webpage or interupts speech when laptop is tilted. But When I enable imput help mode, NVDA says unknown every time when the event is registered. E. g. when I move the laptop to the left or right. Is this expected behavior?
Tested with next-9648,0c89e45

[nvaccessAuto]

Comment 7 by jteh on 2013-08-28 00:30
This is intentional, though it could be argued that it's undesirable. The reason for this is that these unknown keys are sometimes associated with buttons (e.g. wireless toggle, screen brightness, etc.) and someone might want to map these to commands in a plugin. (If you look in the log, you'll see it logs a gesture like unknown_xx, where xx is a unique code.) We could just ignore the keys completely (so they wouldn't report in input help), but that would also make it impossible to map them. I'm open to feedback on this, but it's worth noting that allowing them to be mapped could be useful in some cases; e.g. touch sensitive buttons.

[nvaccessAuto]

Comment 8 by ondrosik on 2013-08-28 08:56
I understand. I just imagine beginner user. If he/she use something like cooling pad, where the laptop is slightly tilted every time, NVDA produces unknown message every few seconds (that was my issue here too). But as the imput help mode is not used in dayly bases we should probably leave this as is and maybe wait if more users will experience this.

[nvaccessAuto]

Comment 9 by James Teh <jamie@... on 2013-08-29 03:44
In [3420e88]:

When reporting unknown scan codes in input help, include the scan code.

This won't be meaningful to the user, but at least they'll understand when different keys (real or fake) are being sent.
Also, make sure the code part is always two digits, even if it only needs to be one, as that makes it clearer that it's a code.
Re #3468.

[nvaccessAuto]

Comment 10 by James Teh <jamie@... on 2013-08-29 03:45
In [79bb0e7]:

Merge branch 't3468' into next

Incubates #3468.

[nvaccessAuto]

Comment 11 by ondrosik on 2013-09-03 05:31
I think that current solution is fine, it works atleast for my laptop so I moved to next version completelly. Imput help mode reports values as 25, 26, 27 and 28 as expected.

[nvaccessAuto]

Comment 12 by Michael Curran <mick@... on 2013-09-16 23:51
In [55903f8]:

Merge branch 't3468'. Fixes #3468

Changes:
Removed labels: incubating
State: closed

[nvaccessAuto]

Comment 13 by mdcurran on 2013-09-16 23:51
Changes:
Milestone changed from next to 2013.3