How into implementing a proper keyboard driver?

[Demindiro]

When you see yourself forcing some thing to be some entirely different kind of thing it is usually a sign of something needing to be reworked

On the contrary, treating mouse axes as keys simplifies things. In my window manager I will need to parse keyboard events anyways so I can interpret Super + any other key as a command (e.g. on my Linux desktop Super + C switches focus to the next window, which I will also implement in my WM).

Axis values mean nothing in themselves without knowing what they represent.

But I do know what they mean? Mouse{X,Y} means a movement happened along a certain axis.

A driver can still use separate keycodes for joysticks. Such keys can be mapped later to Mouse{X,Y} when appropriate.

Joy sticks again have an entirely different purpose, you don't point at things with a joy stick.

In shooter games you very much point at things

[Gigasoft]

On the contrary, treating mouse axes as keys simplifies things. In my window manager I will need to parse keyboard events anyways so I can interpret Super + any other key as a command (e.g. on my Linux desktop Super + C switches focus to the next window, which I will also implement in my WM).

Although a window manager processes both mouse and keyboard inputs, their processing should have little in common. With key and character input, there is typically a concept of a "current" window that will receive the input, whereas for mouse input, movement controls a cursor and button presses are sent to whatever is under the cursor. Yes, I've used systems where this wasn't the case, which wasn't much fun.

Mouse{X,Y} means a movement happened along a certain axis.

Except they don't, when those are remapped joystick axes. Then they represent the current absolute position of the stick. When using a joystick to control a cursor, the position is sampled at regular intervals, converted to a velocity and integrated over time. With a mouse, each report represents a definite distance that the mouse has moved since the last report. So you basically end up making each mouse driver having to simulate a joystick or vice versa.

In games, using a joystick for aiming simulates the challenge of handling a heavy firearm in real life, or it is done because it is convenient to have all game controls accessible without shifting your hand. Clicking on buttons in an UI is not supposed to be challenging, that's why no one expects to operate a computer with a joystick. In the rare case where you would want to do this, it is better to have a separate component that translates joystick input to cursor input, thereby isolating the UI from idiosyncracies of joysticks.

[Octocontrabass]

With the traditional processing of PC keyboard input, a single keypress can generate multiple characters if an accent key is pressed followed by another key for which no corresponding accented character exists.

Quite a few keyboard layouts don't have any dead keys, including the very popular US English QWERTY layout.

For example, ~ followed by G outputs ~g. I recommend keeping to this tradition. Linux forces me to press space in between, or the ~ just doesn't register, which is always a frustration when being used to Windows.

The third option is to output "g̃". Perhaps someone out there would find this behavior useful.

[eekee]

Years ago, I found using keys as extra mouse buttons under FVWM to be very nice, and I've missed it ever since. It's rather like how you play a shooter with the mouse and keyboard: you work the mouse with one hand, and some keys on one side of the keyboard with the other. (If I remember right, many gamers will tell you this is the best control system.)


Regarding the dead=~ issue, you either want to be capable of sending multiple events at once, (and keeping them in the right order!) or perhaps report characters as strings. Strings could contain UTF-8 sequences and, of course, multiple characters.


Wouldn't gamers with depth-reporting keyboards use the depth feature in a similar way to how they use joysticks? I'm just throwing this in to confuse the matter further.


Generalizing, here's my maxim of simplification:
Many design decisions which simplify one area of a system complexify another.