2015-04-12 11:27 GMT+02:00 Ilya Zakharevich <nospam-ab...@ilyaz.org>:
> > Note also that (since always), MSKLC generated drivers have never allowed > > us to change the mapping of scancodes (from hardware keyboards) to > virtual > > keys, aka "vkeys", or to "WM_SYSKEY" (this is hardwired in a lower > internal > > level). > > Wrong. Look for any French or German keyboard. > Wrong. I use a French keyboard everyday. And even used MSKLC for extending this French keyboard (but now with weird compatibility problems in Windows Server 2012 and Windows 8+, this is a separate issue). Seriously, how can you imagine that I never looked at a French keyboard ? You're still speaking about something else, I just spoke about MSKLC which has not been revized at all to generate compatible drivers. But even if it did, it DOES NOT support the extended interface in "kdh.h" (which is NOT the ".klc" format that MSKLC supports) And yes, MSKLC *does not* allow changing the mapping of scancodes (from hardware keyboards) to vkeys, it just allows editing the mapping from sequences of vkeys(+limited keyboard states) to ONE and only ONE code point. the first part is not accessible (and not described at all in .klc source files which have nothing in common to the internal binary structures generated in installable keyboard drivers, and used then by the kernel) and it offers absolutely no way to describe a layout geometry (as needed for touch interfaces) where we can reposition the vkeys accurately (for example for typing with left-hand only, or for an ABCD disposition, or for defining other custom input methods similar to phones using 10 digits or using predictive "T9" methods, or for creating specific selection grid layouts for symbols and emojis with mutliple selectable sets): MSKLC still assumes legacy 101/102 key geometries (and does not in fact distinguish the numeric keypad, with the *only* exception of the decimal separator key which is distinguished). And there's no way to change the layout of "function keys" (those keys that are show with a black/dark grey background in this editor): you can only defined mappings for the vkeys in the alphanumeric part plus the spacebar. Everything else is assumed (there's also no distinction of the two Alt keys for keymaps that want to distinguish Ctrl+LeftAlt and Ctrl+AltGr which may also be Shifted) In fact the *.klc source file format (specific to the MSKLC tool) is not even documented (and not supported at all by "klc.h" which just describes the binary structures: the kernel has abosutely no support for processing .klc files directly, it just wants the binary-encoded tables exposed by the driver that must be compiled). And did I say that the MSKLC tool does not even worok in Windows 8+ or Windows Server 2012 +? It cannot compile the driver (fails to launch the linker of the Windows SDK, even if it's correctly installed). To run this tool you still need to use it in previous versions of Windows. The generated driver however is installable in later versions of Windows (with some quirks to coexist with the onscreen interface). And even in Windows 8 and Windows Server 1012 here are TWO distinct touch interfaces: - one compatible with accessibility options tools (works even without a touch screen, you can click on it with your mouse, or touch it), - another newer one specific for touch screens (not available without a touch screen, but when it exists, its really behaves differently but with too frequent bugs if you use it simultaneously with a physical keyboard, notably each time you have used it to touch the onscreen shift keys, whose state is incorrectly defined; the only way to solve these bugs in Windows 8 is to disable the touch screen device completely, but it is enabled autiomatically...).
