#389 Numeric keypad keys not working when NumLock enabled

[Anonymous]

Originally created by: yoshimat... (code.google.com)@gmail.com

*What steps will reproduce the problem?*
1. NumLock LED ON before run fgfs.
2. Run fgfs.
3. Monitor devices/status/keyboard/event from property tree.
4. Type 0 1 2 3 4 5 6 7 8 9 keys on numeric keypad, but nothing happens.
. Enter / * - +  keys on numeric keypad work correctly.
0 1 2 3 4 5 6 7 8 9 keys under function keys work correctly.
5. Type NumLock (LED OFF)
6. Now, 0 1 2 3 4 6 7 8 9 keys on numeric keypad work correctly.

*Any output in the console (black window)?*
No.

*What FlightGear version are you using (when using GIT version, please
mention date)?*

Windows 1.9.0, 1.9.1, 2.0.0, 2.4.0rc1: reproduces this problem.
Windows 1.0.0 (last plib version): No problem.
Ubuntu (with the same dual-boot machine): No problem.

*What operating system and graphics card?*
Windows XP

*Please provide any additional information below or as attachment (Avoid
expiring external links, such as to imageshack/pastebin/...).*

On Japanese FlightGear forum, some windows users have been reported same problem since v1.9.0.

There happens no problem if NumLock LED OFF before fgfs run.
There happens problem if NumLock LED ON before fgfs run, as described above.

According to comments on OSG Changeset 7978 (http://www.openscenegraph.org/projects/osg/changeset/7978), I guess similar correction for OSG GraphicsWindowWin32.cpp is required to toggle the NumLock state correctly for non-US (?) keyboard.

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

Hm, not sure if that's an OSG problem. I thought we're still using PLIB for keyboards/joysticks. And I'm also seeing this on Linux. Whenever NumLock is enabled, the numeric keys on the numpad are ignored. For me it doesn't matter though, if NumLock was enabled/disabled before or after launching fgfs. When it's on, keys are ignored.

FGKeyboardInput::doKey receives the keycodes, however it drops any numpad keys when NumLock is enabled, since it the keycode is assumed "out of range" (keycodes of 0xff7f-0xff99 are reported, but keycodes beyond 0x400 (1024) are ignored).
Also not sure what the intended behaviour was. Would we just report these keycodes - so it's up to the keyboard.xml to map these keycodes to something - or would we expect the keys to report the same keycode - no matter what the NumLock state is...?

Labels: Inputs
Cc: cumuluni...@gmail.com
Status: Accepted

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

(No comment was entered for this change.)

Summary: Numeric keypad keys not working when NumLock enabled

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

Indeed, we use keyboard events from OSG - not PLIB.

@Torsten: can you test this on your Windows machine? The OSG fix for Linux/X11 was done by Melchior - probably he had noticed issues with a German keyboard on X11 when he made the patch. There was no related fix for Windows. There's a chance, something weird still with Windows/German keyboards. Otherwise we'll need a Japanese keyboard to reproduce this :).

But, as described above, NumLock generally doesn't work for me on Linux. I need to disable NumLock, otherwise NumPad won't work.

[Anonymous]

Originally posted by: yoshimat... (code.google.com)@gmail.com

Hi.

Thanks for comments.
I'm not familiar with programing stuff, but if some tests are required with Japanese keyboard, please notice here (with executable windows binary).

Here is additional information.

*What operating system and graphics card?*
Windows XP, Japanese 109 USB keyboard(*1).

*1 Picture of Japanese 109 keyboard can be found in http://en.wikipedia.org/wiki/IBM_PC_keyboard.
Nowadays, I believe 109 USB keyboard is the mainstream in Japan.

As summary, at least for my machine, the problem occurs when:
- NumLock enabled before running fgfs.
- NumLock enabled during fgfs running.
but the problem doesn't occur when:
- NumLock initially disabled.
-- During fgfs running, num keys works correctly both for NumLock enabled and disabled.

toshi

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

Toshi, maybe you could help in providing debug information. Should allow us to find out if OSG is the problem, or if it's fgfs itself.
If you start fgfs with the command-line option
   --log-level=debug
you'll see more debug information (lot's more). When fgfs is running, open the property browser and configure the property
   /sim/logging/classes
and set it to "input" (limits debug information again, so only input info is printed).
You should then (only) see debug message in the log window like
   "Key value 65507 out of range"
or
   "User pressed key 3 with modifiers 4".

Try that with NUM Lock initially enabled or initially disabled. See what happens if you try to toggle NUM lock at run-time and then press the 0,1,2,3 keys on the NUM pad.

[Anonymous]

Originally posted by: yoshimat... (code.google.com)@gmail.com

Hi,

Thank you for your good advice.
Here is my test results with 2.4.0rc4, Windows XP, Japanese 109 USB keyboard.

---
(A) Initial NumLock state: On

(A-1) NumLock state in runtime: On
0: Key value 65438 out of range
1: Key value 65436 out of range
2: Key value 65433 out of range
3: Key value 65435 out of range
.: User pressed key 46 with modifiers 0
NumLock: Key value 65407 out of range

(A-2) NumLock state in runtime: Off
0: User pressed key 364 with modifiers 0
1: User pressed key 363 with modifiers 0
2: User pressed key 359 with modifiers 0
3: User pressed key 361 with modifiers 0
.: User pressed key 127 with modifiers 0
NumLock: Key value 65407 out of range

(B) Initial NumLock state: Off

(B-1) NumLock state in runtime: On
0: User pressed key 48 with modifiers 0
1: User pressed key 49 with modifiers 0
2: User pressed key 50 with modifiers 0
3: User pressed key 51 with modifiers 0
.: User pressed key 46 with modifiers 0
NumLock: Key value 65407 out of range

(B-2) NumLock state in runtime: Off
Same as (A-2)
---

As I couldn't stop "Running Main Loop" message repeats, I should also press PrintScreen immediately after I pressed a key...

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

There's two issues here:
1. On Linux, the numeric numpad keys weren't working at all when NumLock was off. They need to be mapped to appropriate keys (i.e. arrow keys etc).
2. On Windows, OSG obviously tries to map numpad keys to arrow keys when NumLock is off - but that only seems to work when NumLock was off at startup.
As a fix/work-around, we can extend the keycode mapping of FG: http://www.gitorious.org/fg/flightgear/commit/d3c06bd19b785bbd2a09bed27de66bf721ad7504
I believe that's a general NumPad issue, not specific to Japanese keyboards.

Not tested for Windows yet. Toshi, you could test the recent fgfs binary:
http://flightgear.simpits.org:8080/job/Windows-release/lastSuccessfulBuild/artifact/flightgear/projects/VC90/Win32/Release/

Status: Testing

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

(No comment was entered for this change.)

Labels: Milestone-2.4.0

[Anonymous]

Originally posted by: yoshimat... (code.google.com)@gmail.com

Test report for the latest fgfs.exe build #211 (2011/08/07 9:39:25)
with 2.4.0rc4, Windows XP, Japanese 109 USB keyboard.

(A) Initial NumLock state: On

(A-1) NumLock state in runtime: On

5Enter+-*/ keys act as intended.
  5: User pressed key 53 with modifiers 0 (acts as 5 key)

01234 6789. keys act as if NumLock is off.
  0: User pressed key 364 with modifiers 0 (acts as Ins key)
  1: User pressed key 363 with modifiers 0 (acts as End key)
  2: User pressed key 359 with modifiers 0 (acts as arrow key)
  3: User pressed key 361 with modifiers 0 (acts as PgDn key)
  .: User pressed key 127 with modifiers 0 (acts as Del key)
  NumLock: Key value 65407 out of range

(A-2) NumLock state in runtime: Off
All keys act as intended.
  0: User pressed key 364 with modifiers 0 (acts as Ins key)
  1: User pressed key 363 with modifiers 0 (acts as End key)
  2: User pressed key 359 with modifiers 0 (acts as arrow key)
  3: User pressed key 361 with modifiers 0 (acts as PgDn key)
  .: User pressed key 127 with modifiers 0 (acts as Del key)
  NumLock: Key value 65407 out of range

(B) Initial NumLock state: Off

(B-1) NumLock state in runtime: On
All keys act as intended.
  0: User pressed key 48 with modifiers 0 (acts as 0 key)
  1: User pressed key 49 with modifiers 0 (acts as 1 key)
  2: User pressed key 50 with modifiers 0 (acts as 2 key)
  3: User pressed key 51 with modifiers 0 (acts as 3 key)
  5: User pressed key 53 with modifiers 0 (acts as 5 key)
.: User pressed key 46 with modifiers 0 (acts as . key)
  NumLock: Key value 65407 out of range

(B-2) NumLock state in runtime: Off
All keys act as intended.
  Same as (A-2).
---

Behavior of (A-1) was changed.
To control plane, there would be no problem (big advance).
To input characters, there still are problem.

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

Ok, thanks for testing. I was afraid there was still an issue for Windows. I'm almost sure though, that is an actual issue with the OSG library. I'll double check, and report this to the OSG-devel-list. Means we're likely not to have a fix for FG2.4.0.

Status: Accepted

[Anonymous]

Originally posted by: gijsrooy

Am I correct this wasn't fixed before the 2.4.0 release? In that case, the Milestone-2.4.0 tag isn't applicable here.

Labels: -Milestone-2.4.0

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

The main issue is fixed: num pad always works for controlling the aircraft (which is independent of num lock state) - that's why it was tagged with 2.4.0. What's not fixed is using the num pad on data input fields in the GUI (since the num lock state makes a difference there). However, that's an OSG issue - not an FG issue to be precise. I hope OSG fixes this before we release 2.6.0...

[Anonymous]

Originally posted by: gijsrooy

The only remaining issue seems to be an OSG issue (if it hasn't been fixed in the meantime), so closing this one.

Status: Fixed