8360647: [XWayland] [OL10] NumPad keys are not triggered

[azvegint]

When we try to pass XK_KP_0 to NotifyKeyboardKeysym in Remote Desktop API, it presses/releases SHIFT + XK_KP_Insert.

To get the same result as XTest api when using NotifyKeyboardKeysym we should use XK_KP_Insert instead of XK_KP_0 regardless of NumLock state. Similarly for other Numpad keys.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8360647: [XWayland] [OL10] NumPad keys are not triggered (Bug - P3)

Reviewers

• Sergey Bylokhov (@mrserb - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26170/head:pull/26170
$ git checkout pull/26170

Update a local copy of the PR:
$ git checkout pull/26170
$ git pull https://git.openjdk.org/jdk.git pull/26170/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26170

View PR using the GUI difftool:
$ git pr show -t 26170

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26170.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back azvegint! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@azvegint This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8360647: [XWayland] [OL10] NumPad keys are not triggered

Reviewed-by: serb

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 26 new commits pushed to the master branch:

• 54e3762: 8361504: RISC-V: Make C1 clone intrinsic platform guard more specific
• 974ad4e: 8359868: Shenandoah: Free threshold heuristic does not use SoftMaxHeapSize
• 117f0b4: 8361426: (ref) Remove jdk.internal.ref.Cleaner
• ... and 23 more: https://git.openjdk.org/jdk/compare/05c9eec8d087cbfffed19031a531b72ad18a52cf...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

@azvegint The following label will be automatically applied to this pull request:

• client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (7096b725)

[mrserb]

To get the same result as XTest api when using NotifyKeyboardKeysym we should use XK_KP_Insert instead of XK_KP_0 regardless of NumLock state. Similarly for other Numpad keys.

Will Java receive the same keycodes if these events come from native code?

[azvegint]

Will Java receive the same keycodes if these events come from native code?

Yes, java receives the same events for both remote desktop emulated keystrokes and physical keystrokes, whether NumLock is on or off.

[prrace]

The test expects to receive Insert (not 0) even if numlock is on ? Why is that ?

It isn't really mentioned but this about Robot, isn't it ?
What happens if a user types directly ?

Can you please put an evaluation in the bug report.
Also is this a regression of JDK-8351907 ? Looks that way since it is reported as working in JDK 25 b23.

[azvegint]

The test expects to receive Insert (not 0) even if numlock is on ? Why is that ?
It isn't really mentioned but this about Robot, isn't it ? What happens if a user types directly ?

The test doesn't care which button is pressed. It stores the keyCode-keyChar pair in a map received from the keyPressed event.
Later, it checks whether the keyChar in the subsequent keyReleased event for the same keyCode matches the keyChar in the keyPressed event for that keyCode. It just checks for consistency.

jdk/test/jdk/java/awt/event/KeyEvent/KeyCharTest/KeyCharTest.java

Lines 45 to 55 in 518536c

	public void keyPressed(KeyEvent e){
	transMap.put(e.getKeyCode(), e.getKeyChar());
	}
	public void keyReleased(KeyEvent e){
	Object value = transMap.get(e.getKeyCode());
	if (value != null && e.getKeyChar() != ((Character)value).charValue()) {
	throw new RuntimeException("Wrong KeyChar on KEY_RELEASED "+
	KeyEvent.getKeyText(e.getKeyCode()));
	}
	}

Before the fix, it was receiving:

• Numlock on: KEY_PRESSED with keyChar=Undefined keyChar and KEY_RELEASED with keyChar='0' / NumPad-0 keyCode
• Numlock off: Undefined keyChar was received in both cases; the test didn't fail. / Insert keyCode

After the fix, everything is consistent, and the same key events are reported as if they were pressed by a user.

Can you please put an evaluation in the bug report.

Sure.

Also is this a regression of JDK-8351907 ? Looks that way since it is reported as working in JDK 25 b23.

Yes, it is.

[honkar-jdk]

@azvegint This is in regards to the regression test for this fix. The existing test /awt/event/KeyEvent/KeyCharTest/KeyCharTest.java does not correctly reproduce the issue when Numlock is not "ON" on the testing system.

To better replicate the problem without the fix, adding a new test for this changeset might be a good idea.

• Test only the Numpad keys (0x60 to 0x6F)
• Automate Numlock set and reset (reset can be done in the finally block)

robot.keyPress(KeyEvent.VK_NUM_LOCK);
robot.keyRelease(KeyEvent.VK_NUM_LOCK);
for(int vkey = 0x60; vkey <= 0x6F; vkey++) {
    try {
        robot.keyPress(vkey);
        robot.keyRelease(vkey);
        System.out.println(KeyEvent.getKeyText(vkey) + " " + vkey);
    } catch (RuntimeException e) {
    }
}