Excessive CPU usage makes JS keyboard layouts unusable, requires support for XKB format

[dispoclavier]

The Dvorak-left remapped layout available here as well as a dumbed-down POC layout based on it both start working smoothly, but after a few dozen words of plain English, nothing fancy, some keystrokes are skipped, then the keyboard stops working entirely, the pointer becomes tiny, slow and unresponsive, the ventilator starts at maximum level, and I almost have to shut down the Chromebook. Merely displaying the power-off menu may also fix it, for the system to recover and become responsive again.

This is not like #100, yet the issues may be related.

By contrast, test-typing on a built-in XKB layout even at high speed works flawlessly. I need to mention too that the issue occurs on a high‑end enterprise Chromebook (model DRALLION360-SSVR C5N-A4J-M5R-D2Y-E5O) with an Intel Core i5 CPU, and the device is new (65% off), so this is scarcely a hardware issue.

The available XKB keyboard layouts do not cater enough for the needs of the locales, because locale support is incomplete, since even standards may not support the required features. E.g. the French NF Z71‑300(A):2019 does not efficiently support punctuation spacing as required when writing French.

Hence the need for the ability to add custom keyboard layouts. Yet given that the JS-based custom keyboard layout scheme is not usable, adding support for XKBCOMP seems an efficient short-term solution, allowing users to load a compiled XKB layout file after opening a session. Optimal is the ability to install extra keyboard layouts in XKB format, so this should be the ultimate design goal.