Case shift of o in colemak_dh_iso_us

[fleetingbytes]

I modified the colemak_dh_iso_us layout to bring back the caps lock key and then I used it with caps lock on. When I press keycode 39 (mapped to the letter "o"), without any further modifiers, a lowercase "o" appears. All other letter keycodes obey caps lock and type their respective uppercase variants.

I guess this is because originally (somewhere in the included layouts) keycode 39 used to be mapped to ";" which was unaffected by caps lock (numbers and symbols are usually unaffected by case switch, but see the standard German QWERTZ for an exception to this).

I "fixed" this by adding the following line:

keycode 39 = +o       O        oacute        Oacute             Control_o

Note the + before o in column 0.

This could be mentioned in a comment above line 67. I'd be happy to create such a MR but I feel my extra line of code does not really address the root cause of the issue. To me it appears to be rather a hack on top of something more sinister going on here, see also issue #73.

We should first try to deliver a layout where caps lock works as usual and only then have a single line to comment/uncomment which would toggle keycode 58 between behaving as caps lock or backspace.

[stevep99]

I'm guessing there is some inherited configuration from Qwerty in the underlying system. I'm not familiar enough with XKB to know the answer. From what I gather XKB is a huge complex mess.

It would be nice to have a fix for this, but TBH, these days people are increasingly using firmware in their keyboards or software remappers at the USB level. I think this is probably a better approach longer term as it gives more flexibility esp if you want other features such as layers, and avoids platform-specific changes to XKB config.

[fleetingbytes]

Let's not get too cynical about XKB, especially when this keymap file is actually not XKB xmodmap (see 2nd paragraph of man keymaps description). These keymap files are a life saver when you (a colemak-typing system admin) have to install a distro from its base image and thus spend a lot of time in the console - or maybe you don't even want a graphical user interface at all.

A keyboard which is programmable is a convenience, yes, but only if you're ok with a subset of an existing keyboard layout. If you want to roll your own, you need a good foundation. Keymaps are such a foundation.

[stevep99]

Yeah I wasn't trying to be too cynical about XKB and you are right that these are console keymaps. Although if you look at the XKB xmodmap files, they are virtually identical so there could be some hidden common functionality. It's just that my past experience trying to do things in XKB wasn't especially pleasant.

So let me this time try a more useful suggestion: Have you tried out the standard Colemak console files https://colemak.com/Unix#Linux_in_text_console_mode
Vanilla Colemak has the same O position so if the issue is fixed there, it should be easy to transfer to Colemak-DH too.

[DreymaR]

From a technical and specific point of view, for semantic purposes, my impression is that xmodmap is not XKB. They both stem from X.Org and work(ed) under the X server, but they're different beasts. Just to clarify; I hope I'm not wrong about that.

So technically, I believe it's 'X xmodmap' or better, just 'xmodmap', not 'XKB xmodmap'. Isn't it?

They certainly work differently! XKB is indeed a huge complex mess – even we who love and use it will agree to that, once you get into its innards. By contrast, xmodmap is a much simpler but also more limited protocol ... and also mostly deprecated by now from what I gather. And yet, it's still in use, and it's still quite simple to use compared to XKB.

My Linux support for the BigBagOfTrix is limited to XKB only. It really can work wonders once you manage to wrangle that beast properly, and fortunately the xkb-data specifications are still supported on Wayland even with the X server gone.