RFR: 8278924: [Linux] Robot key test can fail if multiple keyboard layouts are installed

[Martin Fox]

On Mon, 17 Jan 2022 20:25:08 GMT, Martin Fox <duke at openjdk.org> wrote:

> The Robot implementation on Linux did not consult the current layout when mapping from a KeyCode to a hardware code. Internally it retrieved results for all the layouts but just picked the first one it saw leading to random effects. Though not part of the original bug report, the code also ignored the shift level when choosing which result to pick. On a French layout the dollar sign is on two keys (AltGr 4 is the second one) and the code could choose either one. Same is true for pound.
> 
> This PR consults the current layout and only on shift level 0 which is the same level used in get_glass_key to figure out which KeyCode to assign when generating a KeyEvent.

For anyone else looking at this code: the GTK documentation on how groups and levels work doesn't match the behavior seen on X11 systems. This whole area is sketchily documented. A quick summary:

The keymap includes information on all of the keyboard layouts the user has installed. A call like `gdk_keymap_get_entries_for_keyval` returns results that span all the installed layouts and it's up to the client to sift through them to find the entries relevant to the current layout. The layout is specified in the `group` field which is an index into the user's list of configured layouts with 0 at the top (as presented in the UI). The `level` field indicates the modifier state (0 for unshifted, 1 for shifted, etc.)

Under certain circumstances all of the results may be in group 0 even if that's not the active layout. I've seen this happen when the current layout is non-Latin (e.g. Russian) or when querying values on the numeric keypad. So if all the results are in group 0 the group fields should be ignored.

If the user configures a non-Latin layout GTK (or XKB) will append an additional U.S. QWERTY layout/group under the hood. Presumably this is added to ensure there's always a Latin layout around to resolve accelerators like Ctrl+C.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/718#issuecomment-1500958794