Instructable: Keyboard System

Step 3 Alternate Keyboard Layout

This is a screen view of an alternate keyboard layout, as it appears when the wheel button is pressed. Note that the normal display is faded to a watermark appearance while the layout is shown transparently over it. One or more characters from the alternate layout may then be generated. (For logistics, see steps 4 thru 7.)

Also note that the screen layout has the same shape as the keyboard itself. If a respective key is pressed on the keyboard while the screen layout is shown, the appropriate alternate character will be generated at the cursor, in the current application.

Once the alternate character set is de-activated (by one of Steps 4 thru 7), the alternate keyboard layout disappears from the screen and the display returns to normal brightness. Typing then continues with the primary keyboard layout.

Naturally, the programming for this functionality would also need to run transparently to every software application, so that all the normal keyboard characters are available within each application.

The following are the four options to be expanded upon and evaluated by this forum. My hope is that one may be selected as most preferable, with respect to ease in programming or integration within common operating systems.

Comments

[Mr.Grinch]

From my experience in programming. it doesn't sound like you need to adapt the screen fading to every program for them to fade out, just each operating system, Microsoft, Linux, and Mac that says to fade the whole screen and open the application- "alt_keys" for example. Also if you need help with configuring the keys to work correctly as stated by "Nah", you should contact Microsoft and Mac and Linux and talk to the programmers of the operating systems to figure it out. My blackberry has something like that, pushing "sym" pops up a screen and "A" turns into "]" and "E" to "{" the calculator works the same way. it all depends on how the operating system is configured.

[Scrupulous]

Yeah, we figured that would be one of the better ways to do it. Of course, emulation is another way, etc. If you know any contacts at one or more of these companies, it may be helpful. One of the main ideas on this is to free one hand to use the mouse full-time.

[nah]

I'm not sure if this is the best place to put this, but it makes sense to me so, here we go. I was thinking about what all the alternate keyboard layout system entailed, and realized that some care needed to be taken in it's implementation. A potential problem is using keys before an OS (and thus drivers) has been loaded. An example of this is accessing the BIOS, which may require a function key to be pressed (i.e. F2, which I think is fairly common one.) Unfortunately some systems have been known to require nearly random key combinations. There are two solutions I can think of to this: 1) Have the keyboard default to generating the F-keys and a few other select scancodes. 2) Provide for the alternate layouts to be accessible with out the need for drivers. This would require that the keyboard be able to switch layouts prior to any drivers being loaded, as well as the standard scancodes for all keys being generated . The first option is technically simpler, but poses the problem of selecting the right keys. The second option is more difficult but ensures compatibility. I would say that the second option is the better, but it does preclude the possibility of using the mouse or some other device as the only way of cycling through layouts. If there are any other thoughts or comments on this, I would like to hear them.

[Scrupulous]

If the layout switch is integrated with the keyboard, all required keys would be accessible before any drivers are loaded (if it can emulate a 101-key), correct? In this case, the additional programming could then detect the initial position of that on-board switch, and provide an appropriate screen display if necessary. With your key labeling scenario, additional actions may not even be required once the driver is loaded. But, maybe a way to allow a second device to interject with the layout controlling would be good. Is that what you're thinking? By the way, the screen layout wouldn't need to be so big. And the previous display wouldn't need to be lightened anywhere but behind the hand. (I know, that might be the last thing you want to concern yourself with.)

[nah]

That's part of it, but in someways it gets a bit more convoluted. I've attached the USB document that gives the standard scancodes for different keys (page 54) as well as if they are present on "boot" keyboards. The scancodes of our keyboard need to at least partly match that standard. The convolution comes in if we try to used the keyboard HID. They scancodes provided are based on physical location of the keys, not so much what character(s) they are associated with. What's more, every key always sends the same code, regardless of if a modifier key is being held down.

I'll give an example which will, hopefully, help things make sense. Lets suppose that one of the alternate layouts has a key designated as "/" and one as "?". For a normal American system you would need to have 0x38 send for the "/", but for "?" you need to set either left or right shift (0xE1and 0xE5 respectivley) then send 0x38, then unset shift. Also, if you hold the shift key, and press the "/" key, you will get a"?".

There is something of a solution, and that's write custom drivers for the keyboard layout but use the same scancodes as the USB standard. I think this can be made to work in a pinch sans drivers, but the keys wont be labeled anywhere near correctly, and may behave oddly. It may also be possible to initialize the keyboard with HID drivers and set to work (though not optimally) with them if custom drivers aren't present. I'm not well enough versed in USB to know if this is, or is not, correct. I hope someone who knows more can set me straight.

[Scrupulous]

I really appreciate the progress you have already made. If you can get this to work, you can consider yourself a part-owner. But, to complicate things even more, could you take a look at my recent response to infiniteregress, when you get a chance? It details a fairly unique strategy.