Add alternative setup (user side) documentation - initial version

[braoult]

A first draft about user-side configuration (see #69 and #13 discussion)

[suabo]

If you still want to change something before merging you can do that. I think it's pretty good already. I had no clue how to set it up that way. I will also add it to the wiki after merging.

What you think about taking the wiki into the repo? We could just add everything to docs. This would make it easier to push changes to the actual wiki since it is a separated repository. Now I have checked out the wiki into the default name folder "g910-gkey-macro-support.wiki" since it was already in the .gitignore file. Another benefit of adding it would be that everybody can suggest changes to the wiki and downloads it with the clone or zip. I can't see any disadvantages.

[braoult]

I am not very found of GitHub specific git extensions (wiki, pull requests, etc...), I am often lost with them. So yes, the more it looks like git, the best it is (for me). Having the wiki in docs will also allow people to clone repo with all information, this is the minimum a developer could expect when working offline, I believe.

About this pull request, I have feelings on what I could improve: Finding a way to avoid the fix for default F13-F22 bindings to some stupid different keys. xkb is not something I am fluent in, and more, for my own distribution, I am unsure about the difference between all keyboards choices (which ones make this mapping).
If we could get rid of this fix for second-level setup, using G-keys as any other key would be really straightforward.

I think you can merge for the time being, this configuration should work, to make the G-keys look like... keys (managed and handled by applications).

[suabo]

I am not very found of GitHub specific git extensions (wiki, pull requests, etc...), I am often lost with them. So yes, the more it looks like git, the best it is (for me). Having the wiki in docs will also allow people to clone repo with all information, this is the minimum a developer could expect when working offline, I believe.

So I'm going to add the wiki to the repo. And also add your contribution to the wiki.

If we could get rid of this fix for second-level setup, using G-keys as any other key would be really straightforward.

I'm sorry but i can't help you with this. All the configurations you did I have seen for the first time.
Should i follow the instructions to test if it works in my environment?

[braoult]

I will not be here the next few days to help you, but surely yes, you can test it. As it is only changes in some files, it is easy to revert.

In fact, my #12 and #15 issues were already about this "G-keys are full keys, but no more than keys" matter.

[suabo]

Okay, it's gonna be easy to do so I'll look into this next.
I'm not sure about it, but i think you can use any of the in libusb defined keys.

Maybe you can try BTN_[0-9] or KEY_MACRO[1-9] then and don't have to mess with other apps also binding to those keys.

[braoult]

Okay, it's gonna be easy to do so I'll look into this next. I'm not sure about it, but i think you can use any of the in libusb defined keys.

Yes, this is what I did in #6, when I added F13-F21 keys.

Good idea for MACRO keys. I just I added KEY_MACRO{1..19} in uinput_all_keys.py and char_uinput_mapper.py as a first step; if my memory is correct, I believe this is all that is needed to be able to use them.

The last thing I will need to do is to see how it is handled on X side.

Unfortunately, I don't think I will be able to test it in the next few days, so be patient ;-)

And bad news: I am not happy anymore with this keyboard (the Romer-G is much inferior to Cherry mechanical systems), and I ordered a Corsair K70 Cherry MX Brown. Why Japanese layout ? For the supplementary keys near the space bar (that I will use for the Super/Hyper modifiers). I usually receive Japanese orders within 1 week (I live in France), so my contributions here should stop soon.

EDIT: KEY_MACROxx should translate to X11's XF86Macroxx (as defined in /usr/share/X11/xkb/symbols/inet, evdev section). If it works, this will shorten my howto a lot ;-)

[braoult]

Apparently, KEY_MACRO1 (and others) is unknown in Python :

AttributeError: module 'uinput' has no attribute 'KEY_MACRO1'. Did you mean: 'KEY_MACRO'?

Is there a way to find the list of what is implemented in Python uinput (I use Python 3.10.7) ?

[suabo]

Yes there is. I just found out about it yesterday, when i was implementing the direct uinput binding to keys.
There is not all the keys implemented which are defined in uinput linux module:
https://github.com/tuomasjjrasanen/python-uinput/blob/master/src/ev.py

Have you seen I already pushed a branch with the feature here. This way you don't need to change code in the driver to use uinput keys not defined in the driver itself. They have to be defined in python-uinput. I didn't made a pull request since I want to merge the other pull request with the bug fix for re-attachment of kernel driver first. It contains a lot of changes to handling uinput and usb devices so I'll have to rework the feature after the merge.