Ignore custom keyboard scan codes #3468

Closed
nvaccessAuto opened this Issue Aug 25, 2013 · 11 comments

2 participants

@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]:
```CommitTicketReference repository="" revision="f9abcca561cedfe6455ec74d7ece43bd27fa2604"
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]:
```CommitTicketReference repository="" revision="38791e89aecc99b56640e4906fb6e87eb5e1c05f"
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]:
```CommitTicketReference repository="" revision="3420e88a096d485dcf4e816064191b53bcd179d9"
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]:
```CommitTicketReference repository="" revision="79bb0e7136fcd4d22c8902769e4fac36366a2dbb"
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]:
```CommitTicketReference repository="" revision="55903f8f093626b3d26ad8b83132590ad495aa4c"
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

@nvaccessAuto nvaccessAuto added the bug label Nov 10, 2015
@jcsteh jcsteh was assigned by nvaccessAuto Nov 10, 2015
@nvaccessAuto nvaccessAuto added this to the 2013.3 milestone Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment