No plans to deliver a "suck it" message, though Suck It Message Potential (SIMP) would exist

by Michael S. Kaplan, published on 2010/07/02 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/07/02/10032473.aspx

I switched to a Dvorak layout last year (not 'the', 'a': I used MS's keyboard layout generator to add some keys for non-English text). I also use an unlabeled keyboard (nothing written on the keys), to prevent me from looking at the keys.

While this works OK for me, almost no-one can use my computer with this setup. I use another 'normal' keyboard plugged into an USB port with a 'normal' layout (actually, it's the French layout right now, since I live in France for the moment). Of course, using Windows' normal drivers I have to change manually the encoding when I need to use the other keyboard. This is not only inconvenient, it's also quite annoying because for some reason the input layout changes erratically sometimes (I don't know if it's a Windows bug or I keep pressing the shortcut keys; I changed those and it still happens occasionally), often enough to be unpleasant.

As far as I know, the two solutions are to (a) use a custom keyboard that sends different keycodes than usual, or (b) somehow use a driver that interprets the two keyboards differently.

The first approach I don't like, because (1) I'm a software guy, (2) it costs money, and (3) it's not easy anyway, because I want things like AltGr+ScanCode to do different things on different keyboards (for example, the French keyboard uses different key combinations and dead-keys than mine does) so I'm not sure there are enough scancodes to cover both keyboards and still respect the layouts I like.

So, it's a problem that can be solved by drivers, I believe it can be done quite easily. Since I'm not any good with Windows' internals, it not something I can easily make myself, but I'd be surprised if it's very hard to do, and also if no-one needed yet. Backwards-compatibility shouldn't be very hard either, since most people won't really need this...

I blew this one big time, since he was looking forward to a response and I am taking years to say that no, the situation has not improved since I wrote Using multiple keyboards 4.5 years ago.

I disagree that it would be easy, however -- remember that there are already are drivers in place here and the OS is expecting specific scan codes to do the processing. Solving this would not just be a simple driver problem, since you also need work on the Win32 side to know what is going to which threadgroup, making it readable, and sending it there....

As I pointed out then, Raw Input gives you a mechanism to accomplish getting data from multiple devices and sorting out which is which, but then it leaves you to handle all of the work to determining if its a keyboard and converting all of the keydown and keyup messages to characters and such -- essentially duplicating all of the work that happens in the input queue most likely by creating two input queues of your own and injecting the keydown messages into them as if they were straight input and then getting the results back.

This would in theory be possible, and interesting enough of a project that if someone were going to pay me for the time to do it I might be interested. :-)

But it wouldn't be productive work, unless I was going to be working for the Surface team to provide a multiple user input story (which would benefit from that effort!).

I even prototyped something like it last year to prove to myself it could work (it did no processing, just verified you could get the two devices' input and recognize something and that's it), but I can't find the project on any of my machines. If I find it, I'll blog again and post it for any industrious programmers who want to tell some of the most senior and respected architects in Windows who claim it can't be done without major architectural changes that they can suck it (because you were able to get it done!).

I did not have any plans to deliver the aforementioned suck it message when the prototype was being done; it's just that I was once kind of thinking of working for the Surface team and thought a working model that could have provided such obvious though unrealized suck it message potential (also known as SIMP) would have made a hell of a job interview, like Feng Yuan's Windows Graphics Programming: Win32 GDI and DirectDraw did for his entry to Microsoft only more in my ornery style of doing things! :-)

For now it is just a huge amount of time for the minimal benefit of using two different layouts hooked to two different keyboards....

Probably better to just install two shortcuts for the two layouts and leave a note at each keyboard saying how to switch to it, and maybe some instructions on how to use the Keyboard Convert Service I blogged about previously to recover the text if people forget to use the shortcut.

A workaround could be to use the SGCAPS feature of MSKLC and replace the "CAPS LOCKed keyboard" keys with the standard QWERTY-layout.

This way you reprogram the CAPS LOCK key to be a QWERTY LOCK key.

It works easier and more reliable than the standard available keycombination and you can tell by the CAPS LOCK LEDs whether QWERTY or Dvorak layout is active.

There's a chronic mild problem on Linux that U+00FF is the terminal driver's default erase-the-last-character character, but since most people are used to hitting the Backspace key, it is therefore mapped to U+00FF (and the Delete key to U+0008). However, especially when connecting remotely, it's not that uncommon to be using a keyboard which maps Backspace to U+0008, the effect of which is that attempts to erase don't work, and so one must change the mapping with the command-line utility "stty".

A friend of mine therefore solves this problem by having two scripts on his system whose names are \x08 and \xFF (which Linux file systems allow) that set the erase-character character to U+0008 and U+00FF respectively. When logging in, therefore, he presses Backspace and Enter, and all is well; if the driver is already correctly set, nothing happens; if it isn't, the correct script runs and sets the driver to the correct value.

Bogdan is right on at least one count: it is way too easy to hit the default key combination that changes from one keyboard layout to another. I don't know how many times I have gone back and reset those key combinations to "None" after making some seemingly irrelevant Regional Options change. No action item here, just venting.