Allow non-us keyboards - Githubissues

heads105 commented 5 years ago

The recovery shell assumes a US keyboard layout. The following patch adds the loadkmap command to busybox so that I can do: # loadkmap < /boot/uk.bmap and have a UK keyboard layout.

--- orig_heads/config/busybox.config    2019-04-28 10:17:10.245087714 +0100
+++ heads/config/busybox.config 2019-04-28 10:50:15.240518227 +0100
@@ -361,7 +361,7 @@
 CONFIG_DEFAULT_SETFONT_DIR=""
 # CONFIG_FEATURE_LOADFONT_PSF2 is not set
 # CONFIG_FEATURE_LOADFONT_RAW is not set
-# CONFIG_LOADKMAP is not set
+CONFIG_LOADKMAP=y
 # CONFIG_OPENVT is not set
 # CONFIG_RESET is not set
 # CONFIG_RESIZE is not set

tlaurion commented 5 years ago

@heads105 : you might want to add a board "export CONFIG_KMAP=uk" and add logic to /etc/init to validate keymap.map existence and even validate it prior to invoking the loadmap command.

Please do a PR for changes, so that credits/accountability of the changes go to you to facilitate maintenance, but also to facilitate merging of changes. Else, someone else has to create a branch, test it, commit it and push it.

Thanks!

heads105 commented 5 years ago

Hi @tlaurion , will do the PR. For this change it's just adding the loadkmap function to busybox. I was thinking that it might be too disruptive to add all the possible keymap files too, so this was just so that one could be loaded manually. I think something like a signed rc file might be good.

heads105 commented 5 years ago

@tlaurion I just did the trivial version of this PR first. It's sufficient just to enable this command to start with. Can work on something more sophisticated later.

tlaurion commented 5 years ago

fixed in #556

tlaurion commented 5 years ago

@heads105: Extending #556 by providing keymaps and providing a function through a fileselector (eg. of usage) would be welcomed, and was asked in #551.

Not sure what the best implementation would be and neither checked what would be the space cost of including all keymaps.

But a simple solution would be to create a board exported config variable to US, and offer the possibility to the user to change it, and save the change in the rom following #494 logic

tlaurion commented 5 years ago

@heads105 do you want to make that work?

heads105 commented 5 years ago

@tlaurion What I'd prefer is an rc file so that any arbitrary action could be performed at boot, including loading a keymap file. What do you think about that?

tlaurion commented 5 years ago

The way things are currently implemented is through exports in board config files, which gets exported in /etc/config and can be overwritten by rom present files being placed in /etc/config.user at runtime.

The most easy implementation is the one previously siggested. I'm not convinced of putting service related files ATM.

But I'm open to see what other advantages would come out of this as compared to actual way of doing things.

On August 21, 2019 3:54:34 PM UTC, heads105 notifications@github.com wrote:

@tlaurion What I'd prefer is an rc file so that any arbitrary action could be performed at boot, including loading a keymap file. What do you think about that?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/osresearch/heads/issues/555#issuecomment-523522647

-- Sent from /e/ Mail

tlaurion commented 4 years ago

@heads105 : up to the task?

tlaurion commented 4 years ago

Some notes

Could create a heads module downloading http://deb.debian.org/debian/pool/main/k/kbd/kbd_2.0.3.orig.tar.gz and export most common kmaps following https://bbs.archlinux.org/viewtopic.php?id=191064

Text based keymaps are highly compressible, not sure about bmap that loadkmap supports. Those would need to be generated by the build system I guess.

On my side I am asked a lot for german keyboard, french keyboard... We could add as asked for, and Heads could save the config in /etc/user.config as config overlay and save that in cbfs, asking user to reseal measurements on next boot when changed.

tlaurion commented 1 year ago

Some traces revisiting this, years later.

loadkmap only supports binary keymaps that need to be generated with loadkeys (kdb package)
We could either musl-cross-make compile selected numbers of keyboard-lang.bmap to be loaded directly by loadkmap (supported directly from busybox today) : easy path
build loadkeys and pack it under initrd alongside with a bigger number of text based keymaps highly compressed by default at initrd xz creating (total size of all 173 i386 keyboards compressed under non-maximum xz compression and efficient dictionnary size is lower then 100Kb
Or find a package containing bmap files already compiled and create a module that extracts desired binary keymaps.

Important articles:

https://bbs.archlinux.org/viewtopic.php?id=191064
http://mstempin.free.fr/index.php?2005/08/08/14-generating-busybox-binary-keymaps is from where loadkeys -b bogus output below comes from resulting in :
```
loadkeys -b ca-fr-legacy.map > ca-fr-legacy.bmap
unknown keysym 'Mu'
unknown keysym 'Mu'
unknown keysym 'Mu'
unknown keysym 'Mu'
lk_add_key called with bad keycode -1
```
Which fails to generate needed ca-fr-legacy.bmap

Manually transferring map -> bmap present under /usr/lib/kbd/keymaps/xkb/ and provided by kbd-misc, manually extracted and then transformed to bmap files and compressing the properly formatted files results in the following expeced to work subset of keymaps:

[user@sys-firewall test]$ ls -al *.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 az.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 ca-eng.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 cm.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 cn-altgr-pinyin.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 cn.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 cz-dvorak-ucw.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 de-us.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 ee-dvorak.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 ee-us.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 gb-dvorak.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 gb-dvorakukp.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 ge-ru.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 gh-akan.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 gh-avn.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 gh-ewe.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 gh-ga.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 gh-generic.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 gh.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 hr-us.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 id.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 ie-UnicodeExpert.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 ie-ogam_is434.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 in-eng.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 it-ibm.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 it-us.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 jp-OADG109A.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 jp-dvorak.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 jp-kana86.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 jp.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 ke.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 kr-kr104.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 kr.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 md-gag.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 mm.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 mt-alt-us.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 ng-igbo.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 ng-yoruba.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 ng.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 nl-us.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 pl-dvorak.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 ro-winkeys.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 se-us.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 tm-alt.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 tm.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 us-dvorak-alt-intl.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 us-dvorak-classic.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 us-dvorak-l.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 us-dvorak-r.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 us-dvorak.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 us-euro.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 us-haw.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 us-norman.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 us-workman.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 us.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 uz-latin.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 vn-us.bmap
-rw-r--r-- 1 user user 33031 Dec  1 14:52 vn.bmap

Compressed with non-optimized xz results into a 12k space for all the above keymaps. Might be the best approach to just dump them under tree, but that would be present to all boards (where 12k is not a lot and might be even better then that with actual build system compression)

Options could provide a selector to test selection prior of saving the default under config.user to be kept persistent between firmware upgrades.

Thoughts welcome

tlaurion commented 1 year ago

Note that a lot of useful keymaps (including ca-fr-legacy, in my case) fails to be generated with documented error, which workaround would be to generate keymaps through dumpkeys after loading the correct keyboard layout through e.g. setxkbmap as documented here: https://bugzilla.suse.com/show_bug.cgi?id=1185192

That might be the proper way to generate required missing keymaps.

tlaurion commented 1 year ago

From Quick size comparison test adding bmaps for https://github.com/osresearch/heads/issues/555

We learn that with those keymaps added: master had 4350616 bytes free while same board tested had 4335256 bytes free.

Basically, compressed keymaps heads.cpio packed under into initrd.cpio.xz consumed 4350616-4335256=15360 bytes (15kb) more. Not that bad, but still something.

To attain internationalization goal, I think this is not much and a good start to build on.

tlaurion commented 1 year ago

From https://output.circle-artifacts.com/output/job/e4d6440f-cb5f-4a11-9d42-aa9811f147ed/artifacts/0/build/x86/x230-hotp-maximized/heads-x230-hotp-maximized-v0.2.0-1302-ge1f3185.rom

loadkmap < /etc/keymaps/az.bmap from heads " works tm" (to the extent of seeing that keys associated typed text on tscreen is not US anymore.

Quick test was not successful into generating ca-fr-legacy.bmap as of now and will require to test different processes to attain some success level needed for this to go forward.

tlaurion commented 1 year ago

@heads105 : any suggestions from where to get either already prepared bmap files or an alternative to the proposed course of action? As said previously, not all map files can be translated into bmap through patched (now mainsteam from a while) loadkeys -b target.map > target.bmap without error.

linuxboot / heads

Allow non-us keyboards #555