Weird keyboard layout behaviour on Gnome 3

[ilmaisin]

I am trying to run the Orbiter space flight simulator with Wine, Gnome 3 on Fedora 24. I am using a non-QWERTY layout as the default. That makes Orbiter's keyboard commands less convenient.

On Windows, Orbiter works on scancodes independent of the keyboard layout. What is really strange, changing keyboard layout from Gnome's menu has no effect on Orbiter, while it works for non-scancode based apps on Wine. Only after I change the layout using the setxkbmap command, it affects Orbiter as well. Then Gnome's keyboard layout configuration stops working altogether for the session or until i open the Gnome Control Center's locale config panel.

Is there some easy way to work around this? Should I open a bug report?

[Emdzej]

Hello!

Download latest winetricks then install hid package from it and try again. Try with emulating the desktop too and change wineprefix from 64 bit to 32 bit and retest also check here - https://appdb.winehq.org/objectManager. ... &iId=22675

[ilmaisin]

Installing hid package didn't have any effect on keyboard behaviour, nor did emulating desktop. The prefix is already 32 bit.

[Bob Wya]

On Windows, Orbiter works on scancodes independent of the keyboard layout. What is really strange, changing keyboard layout from Gnome's menu has no effect on Orbiter, while it works for non-scancode based apps on Wine. Only after I change the layout using the setxkbmap command, it affects Orbiter as well. Then Gnome's keyboard layout configuration stops working altogether for the session or until i open the Gnome Control Center's locale config panel.

Is there some easy way to work around this? Should I open a bug report?

The keyboard scancodes appear to be handled by queue.c for the wineserver process and then dispatched to appropriate Wine thread/window. Certainly running the wineserver process with debugging turned on, in the foreground, shows that it is intercepting all keyboard scan codes (when a Wine window under it's control has focus).

I think issue that is the Wine behaviour - if didn't hook into the low-level keyboard API. This is necessary - to bypass your Linux DE/Window Manager keyboard shortcuts. Otherwise Windows games wouldn't register keyboard scancodes as your DE/Window Manager would have intercepted and processed them first.

Surely the issue is with the Orbiter game - not having re-bindable controls. Post a bug report / feature request with the Orbiter developer.
It's 2016 people!! Re-bindable controls they're a thing!!

Bob

[ilmaisin]

Orbiter actually does have re-bindable controls, via the keymap.cfg. That would be one possible workaround.

But is there any option to make WINE to "hook into the low-level keyboard API"?

[Bob Wya]

Orbiter actually does have re-bindable controls, via the keymap.cfg. That would be one possible workaround.

But is there any option to make WINE to "hook into the low-level keyboard API"?

Sorry bad use of double negatives and such. My point was that Wine has to hook into the low level keyboard input (by design it's desktop / platform agnostic). I would recommend just rebinding the controls with the keymap.cfg file. I downloaded Orbiter and tested that approach. Seems to work fine on this end!

Bob

[ilmaisin]

Yes, maybe I'll do that. One thing still puzzles me: why does Wine + Orbiter ignore the Gnome's keyboard layout switching, but for example for Wine + Notepad it works fine.

[ilmaisin]

I am still wondering how and why does Wine look the scancodes from the default layout of GNOME. I mean, the default layout isn't necessarily the english QWERTY. The xev command shows scancodes properly, but apps in Wine see the situation like the keyboard was physically rewired to the default setting (the uppermost in the list) of GNOME.

Edit: On the note, on Ubuntu 16.04's Unity desktop, the scancodes depend on the currently selected keyboard layout instead of the default one. Less weird, but still a clearly wrong behaviour. Wine should send the actual scancodes to the apps utilizing them, as they too are readily available.