00:00:25

The code is pushed. Thank you!

23:19:35

I just looked at my last comment and the last "git merge" is of course superfluous.

21:13:00

Thank you for the new patch! Shall I mention you as "wallex" or "Walther" in the commit message?

I applied it to my local git repository already but off the top of my head I think you can do the following to update your git repository: git fetch && git rebase origin/master && git merge origin/master

20:03:01

I see no "Browse" and "attach file" at the top of the page when displaying this task (nor anywhere else for that matter)...

Anyway, I didn't know how C++ default parameter values worked, which is why I had used the Java-version of overloading functions. Here is the updated patch with the required changes (against GIT of a few days ago, as I am not sure how to update GIT without it reverting my changes): http://pastebin.com/m5035a6a7

22:28:17

Please use a default parameter for 'force' in KeyGrabber::load() and WindowManager::doReloadKeygrabber(). You can attach the new patch to the task by using the 'Browse' and 'Attach file' buttons at the top of the page. I'll try the patch then. Thank you for your work!

21:06:32

Bah, I see no way to attach files, so I link to the pastebin entry instead: http://pastebin.com/m42b343af

The only drawback I see is that usually there is a MappingKeyboard AND a MappingModifier request when switching input device, which causes PekWM to parse the keybindings twice.

Other than that, I have tested and the code works well. Even if it feels a little hackish at places.

16:01:20

Bah, it looks like I HAVE to make PekWM handly KeySyms and convert to KeyCodes as needed. Why? Because ActionEvent is a constant field inside the ActionPerformed class, so I cannot modify its contents (eg: updating the keycode when input mappings change). The other option is to no longer tag the ActionEvents as const, but I do not know if this method would be acceptable.

I can make my way through either way, but I really would like to know what is the stance on the devs regarding what solution approach I should take...

10:22:53

Oh ignore that. I realized I could extend a class and store both the keysym and keycode to facilitate things. Though now I am studying the behaviour of the classes KeyGrabber::Chain and ActionEvent to know whether I need to add a new field to both, only to Chain, or if ActionEvent should store the sym rather than keycode (the field is called sym already, why?).

09:49:51

Hmm... I see two approaches to fixing this. The main problem is that XGrabKey and XKeyEvent both work on keycodes, but the keycode values change when there is a input-device context-switch. Fluxbox (and perhaps other window managers) get around this by re-reading the key-binding config file and re-grabbing all keys. On PekWM this would be a trivial call to doReloadKeygrabber() from WindowManager::handleMappingEvent() (with the small obstacle that doReloadKeygrabber will do nothing if the mtime of the keys config file has not changed).

An approach that would not require re-reading the configuration file would be to change the usage of KeyCodes into KeySyms (as KeySyms are unique for each symbol) in the code. That way the Keycodes can be resolved right before grabbing the keys, and a remap could be handled without having to reread the key configuration file.

The problem this approach causes is the need to convert from keysyms to keycode or vice-versa in different parts of the code :/ I wonder if the following "hack" would be acceptable in order to simplify this process: After a XNextEvent call, the keycode field of the XKeyEvent is changed to be the KeySym when it is a KeyPress/Release event (this way it would work all over the code where KeySyms rather than KeyCodes would be stored).

I am just asking which approach would be best to take in order to maximize the chances of my upcoming patch to be submitted to the tree.

12:45:43

From PScreen.cc around line 140:

 // Figure out what keys the Num and Scroll Locks are
 _num_lock = getMaskFromKeycode(XKeysymToKeycode(_dpy, XK_Num_Lock));
 _scroll_lock = getMaskFromKeycode(XKeysymToKeycode(_dpy, XK_Scroll_Lock));

This should be called and windows re-grabbed on modifier changes, makes this a candidate for a separate method.

12:42:43

I made a bug-report with the xorg INPUT driver folks as it seemed it was a bug on X11-xorg, however it appears the problem is PekWM does not regrab the new keycodes when there is a keymap change. From http://bugs.freedesktop.org/show_bug.cgi?id=20984

"Since with XGrabKey you grab keycodes only instead of keysyms, it makes things tricky when you use two keyboards with different mappings. Client programs are informed about the keymap change with a KeymapNotify event and then clients are expected to regrab the new keycodes."

And this is what isn't happening with PekWM, it works correctly under Fluxbox and the like. I am trying to debug the code into figuring out how to make it work, but it doesn't help I am a rookie at X11 coding...

00:23:10

Hmm, it seems different than I expected at first. If I set the following key: "KeyPress = "F12" { Actions = "SendKey F5" }" and the x11 joystick driver is configured to send F12 as one of the buttons, then xev will report:

- If I press F12 on the keyboard, it reports F5. - If I press the button on the joystick, it reports F12.

Furthermore, if I "restart" PekWM, it breaks: - If I press F12 on the keyboard, xev reports F12 - If I press the button on the joystick, no recognized button is displayed! - Many of the usual keybindings no longer work D:

But this is if I restart PekWM while the joystick is connected. If I disconnect it and then restart, usual key behaviour works again (and once I plug the joystick, it works again but key presses are not caught by PekWM).

It seems PekWM simply does not handle multiple input devices through HAL?

Maybe I could get working on this since it is quite important to me to have PekWM handle incoming key events from my gamepad...