If you were designing new -- how about a 120% or a 150% keyboard?

[Morituri]

If you were designing a keyboard, and somebody told you that you absolutely didn't have to worry about driver support - that you could have the keyboard itself directly send any character in Unicode and it would come through on any operating system without any software configuration on the computer side required - and you could use more keys, if you wanted, to get the job done completely ignoring the standard layouts .... What would you want? How should it work?

I am a hardcore geek. I would be all over the math symbols, the APL set, and the Greek alphabet. Modifier keys for the main typing area labeled 'Greek' and 'Math' like on the Knight keyboard? Would mean I didn't have to disrupt my typing (and more importantly my train of thought) to go to the character picker three times a sentence when writing in some topics. Combining diacritics from the 300 block? Hell yes. Accents are another thing that always slows me down and disrupts my typing, especially when I need something that hasn't been coded into the default altgr combos.

Other people? I dunno, when my buddies are writing home they'd probably want to be able to flip it directly into Cryrillic, Hiragana, or Jamo, depending on where they're from. Or even Hebrew, depending on whom they're writing to.

Mostly I'd want programmable macro keys. Maybe a pad of 35 of them, off to the left of the main typing area opposite the numpad, with all the logic required to program them and play them back resident on the keyboard itself with no need for drivers on the computer side.

So... I put it to you. If you had the opportunity to build a keyboard - with no real constraints on desk space - using anything from 150 to 300 keys and able to input pretty much 90% of everything people find practical uses for from Unicode - how would you lay it out? How big would you make it? What modifiers and modes should it use? How much space to devote to the inevitable macro pad?

'Cos.... I can hack a keyboard controller to inject any Unicode character straight into pretty much anything that will take a USB keyboard. A thing that's halfway between an exploit and a feature allows 'character stream' devices to be piped through the HID interface with a little fancy protocol footwork. So, assuming I want to make something a whole lot more intuitive to use than typing the damn decimal keycodes on the numpad with the alt-key held down, and honestly don't care if it's a whole meter wide and weighs fifteen kilos or more, what could I make that would serve YOUR interests as well?

[GEIST]

As far as I know most people would like to have a keyboard as small as possible, but if you're out for some more keys maybe a numpad will do it. If not you could try something like the Genovation Controlpad CP24 or a CP48

or something from X-keys

or a ortholinear keyboard, if you like it plain

[chzel]

Kbdfr incoming in 3...2....1...

[kbdfr]

Kbdfr incoming in 3...2....1...

Indeed

My solution (it has actually been my daily driver for a couple of years now)
is a Tipro point of sale keyboard with additional pads,
which has plate-mounted MX black switches and a metal backplate
and where every single key (even the space key ) is freely programmable
with virtually any character or macro you like:

my Tipro 15-11-03.jpg (732.1 KiB) Viewed 11704 times

[Muirium]

Bugger. He beat me to my joke!

Hurrrrrrrry uuuuuuuup!!!!

[Chyros]

My man! Screw this minimalist bullshit everyone's into, just give me a bigger keyboard with more buttons! Especially programmable ones are quite useful.

I have a fairly small and cluttered desk at work, but even my fullsize ZKB-2R really doesn't cost me any space I need.

[seebart]

My man! Screw this minimalist bullshit everyone's into, just give me a bigger keyboard with more buttons!

Morituri, while I'm not quite in need of 150 to 300 keys I like your approach as you can see by my choice of keyboard:

IMG_20160615_125318.jpg (943.46 KiB) Viewed 11667 times

[Chyros]

A 3771, a fine choice ^^ . Bleached, I presume?

[seebart]

A 3771, a fine choice ^^ . Bleached, I presume?

Yes but just the top part of the case, and only after various less precious plastics passed my testing. This is what it looked like:

photos-f62/wang-model-724-725-3770-us-t ... ang%203771

[kbdfr]

I forgot to say that Tipros are not only programmable,
but programmable in 4 layers,
So one could have for example "Greek" on layer 2 and "Math" on layer 3.

And have a single modifier key to select the next higher (or lower) layer
or specific "Greek" and "Math" modifier keys each selecting the wanted layer.
Or all of these.

And if one finds the battleship is just to big and the additional rows over the alpha field are enough,
well, a Tipro without additional matrix sidepads but with a USB controller allowing programming on 64 bit systems
is available here

[Chyros]

Sometime in the future I'll show a nice keyboard with lots of buttons, but I need to review something else first. It's part of another video trilogy ^^ .

[Morituri]

@kbdfr: SO jealous. I've been using



one of these for years, (though I have the ANSI rather than ISO layout) but unfortunately it seems to be near its end-of-life unless I can figure out how to repair it. A couple of the keys (the most recent casualty being backspace, which is kind of important) no longer work.

I was looking around for a replacement, and while I can find one guy willing to sell me one for a bit north of $200, I realized as I thought about it, that if I was going to use this many keys I'd like to use them more effectively. And it's missing things like option keys (winkeys or whatever your OS calls them) because it's from days when dinosaurs walked the earth.

And there are a bunch of other things that piss me off about the standard layout it produces, too: The num lock is utterly useless for example. If you're going to have another mode for your numpad, the mode ought to be something useful like mathematics and logic symbols, not repetitions of the arrow and functional keys. Caps-lock ought to be Greek-mode instead; if I want caps-lock I'm perfectly fine with turning it on and off by hitting shift twice in a row or by hitting both shift keys at once.

A keyboard would be more useful (to me) if keys auto-combined as a default behavior. So instead of a macro for something like œ͟, or altgr-o, e, alt-down, numpad 53, alt-release, wouldn't it be nicer to do o-down, e-down, underscore-down, then release (in any order) and œ͟ gets sent? But to do that you'd have to be sending characters on key release rather than key-down. The typists would love it but the gamers would scream bloody murder. Incidentally does your OS even display that correctly? It's supposed to be ligature-oe with an underscore.

And incidentally where is my combining underscore? There's no dead-key on any layout for that, and it doesn't get into any altgr combinations. In fact there are absolutely no combining accents as such - you can only use altgr to access single-codepoint characters because the driver people are too damn lazy to support combining accents and normalization. Well fuck them, I can do combining accents and normalization in the keyboard controller if they won't pick up the ball.

Anyway, the macro pad is nice and helps get around some of these problems (like combining accents) on a day-to-day basis, but it's a pain in the ass to be reprogramming macros every time I switch from one task to another, and besides I can't use a macro key as a modifier, nor as a modal modifier that affects the rest of the keyboard.

The end result is that even with macro pads, only the very tiniest fraction of useful Unicode is available at any time.

So how would it be, if Unicode rather than ASCII had been the primary target for desired input alphabet when keyboards were designed? If one keyboard layout really *WERE* convenient for the whole world, including mathematicians, programmers, and linguists who want to use IPA?

[Chyros]

The Ortek battlecruiser! Funny, that ^^ .

[kbdfr]

@Morituri

My story is quite similar. I have been using a Cherry G80-2100 for years:

G80-2100.jpg (368.69 KiB) Viewed 11580 times

but the software (not needed for programming, but for saving and retrieving programmed configurations of the 24 programmable keys) was discontinued after Windows 95.
After briefly trying the new model replacing the G80-2100 (named G81-8308, with horrible MY switches), I found Tipro keyboards and have been using them ever since.

By the way, did I mention that with Tipro you can save and retrieve as many configurations as you want?
That the software is needed only for programming, the configuration being saved in the keyboard itself (no driver needed)?
That you can have the numpad wherever you like (mine also includes a dot and a comma and a % sign)?
That you can have redundant keys, e.g. an additional left-hand enter or arrow pad or right-hand Esc?
That you can program things like "opening and closing brackets and cursor placed between both signs",
program keys with e.g. "undo" and "redo" or "lock keyboard" or "close application"?
That I rather like my keyboard?

[Morituri]

The programmability of the Ortek is pretty nice too, but not as nice as what you're describing. As configured in the factory, you have 24 programmable macro keys (well, 36 once you discover the jumper pin on the controller board that enables macros on the "redundant" 12 function keys). But no remapping, and no reprogramming keys in the standard set. If I could configure it to use any two-keystroke sequence that *starts* with a macro key as macro triggers, rather than single macro-key keypresses, I would be much happier with it.

Well who am I kidding? I'd want one more thing: A socket for a USB stick to store the macro configuration, so I didn't have to worry about the limited memory on the controller board, and so I could, if I wanted a different configuration, plug in a different stick instead of overwriting my current configuration.

[Morituri]

Learning about Tipro keyboards has made me happy. And going to their site to read specifications has made me happier. Particularly about discovering that they ship with plate-mounted Cherry "clicky" switches, that modules can be joined together with a single controller, and that they have an attachable module with a trackball so I can commit its location to muscle memory instead of disrupting my flow of thought to actually look for the pointythingy every time some dumb software has functionality it refuses to provide via keystrokes. That is far superior to any programmable I've used.

And I'm even happier now that I've checked ebay and discovered that modules can be purchased there from people who apparently don't find them as valuable as I will.

They still don't have enough memory though, and they're still not combinatoric. IE, they're limited to some particular number of macro layers and you can't use combinations of multiple keys as macro triggers. And I dislike that it requires computer-side software to save and restore configurations, because that software is never available for Linux, nor enough "proprietary" information to write it for Linux.

Still, that's VERY nice; given on-keyboard reprogrammability and enough memory in the controller, it could be enough.

[Morituri]

Aw, CRAP!

I have now discovered that the Tipro boards, nice as they are, require on-computer software for programming.

Nope. Not viable. I almost guarantee the software isn't compatible. And if it is, it won't stay compatible. And I can't be &^% bothered to go find some Windows box, whose owner will allow me to install some program he's never heard of, whenever I discover I need to change config.

I expect to be building config for months - a new task, new needs, figure out how to make it coexist with existing stuff, reconfigure to better layout/mapping, etc - daily for months. No *WAY* am I going out somewhere to find a Windows box every time I need to do that.

[DMA]

I was about to post this one


Or a linotype

but kbdfr wins, no dispute.

[Morituri]

Nobody wins if it requires any software that's not on all OS's by default.

USB driver? Okay. Board-specific programming software that renders it useless or un-reprogrammable if you don't have the software or the OS it's for, or if it falls out of compatibility? Not okay. Board-specific driver that has to be installed to use it at all? Triple not okay.

Any reason at all why the keyboard won't do exactly the same thing on somebody's Macintosh that it just gets plugged into than it does on my programmers box that's fully configured and been using it forever? Not Okay.

Anyway, I don't want extra keys, as such. I want extra functionality and am willing to put up with extra keys to get it. A macro pad is nice, but any particular macro only does one thing.

I want a keyboard where arbitrary key *combinations* or *sequences* can trigger different characters or functionality. Because there are vastly more combinations and sequences that make actual SENSE as ways to type Unicode characters, even on an ordinary keyboard, than there are macro keys, even on kbdfr's board.

Anyway, what is this "eight layers" crap? A gigabyte of nonvolatile RAM costs about a quarter, so why are macro boards limited to so many layers, so many keystrokes per macro? That doesn't make any damn sense.

Even better, a USB host board with a socket that can let people save their config on USB sticks regardless of any software on the computer is about six bux. Why do none of the people who want their keyboards to be dependent on software and therefore useless in about six years or on the second-hand market or on any machine where it's not the same keyboard that's always attached, not want to do that? A good keyboard ought to last somebody thirty years, damnit. If they're willing to invest forty dollars per board in premium keyswitches, why the hell is six bucks for an extra twenty-four useful years of life not worth it?

[KRKS]

The bad thing about big keyboards is not the amount of keys, but how wide and lopsided where the mouse goes(unless you're a southpaw) they are. That's why I'd make a board that's about as wide as a 75%(or at least 75%+left-side numpad) but longer than a full-size, somewhat like the Datalux Space Saver.

Also, I agree with Morituri, on-board layout saving is a must.

[Hak Foo]

I suspect the reason for small and finite layout capacity is simply that they're using small, off-the-shelf controllers with only a tiny chunk of onboard flash.

Personally, I'd think the way to go is a micro-SD slot or embedded flash drive. You could then save the layout and send it to friends. However, that probably requires a lot more complexity at the controller level.

I'm right now waiting on case decisions for the GH-122 project, can be built as basically an ANSI 104/ISO 105 layout, plus an extra row and two extra columns. Personally, it's not the big layout I'd want (which is closer to a straignt-ANSI MCK-143), but it's the one that's attainable at a modest cost.

A large board with trackpoint might be interesting, to solve the mouse relocation problem.

[kbdfr]

Tipros being point of sale keyboards, the "press one key" approach (where every function is achieved by a single key press) is quite inherent to them.

Other approaches are the "minimize size" approach, the "gamer" approach, the "geek approach" and perhaps more.
Combining all approaches will prove a difficult thing.
Gamers need NKRO, geeks want UNIX or Mac, minimalists would probably accept "Ctrl+Alt+Shift+LeftArrow" for Backspace

So in the end you would have to design the ultimative keyboard allowing all of those,
but each approach would have to contribute to the cost for all other approaches.

[Muirium]

minimalists would probably accept "Ctrl+Alt+Shift+LeftArrow" for Backspace

I do, in fact, use Shift+Option+Fn+; (left arrow) very frequently indeed on my HHKB! It's for extend selection leftwards by one word. Shift+Alt+Left on any keyboard on the Mac. But Backspace is right there, straight above Return. You know, where you ISO guys keep the oh so necessary second deck of Return, oy…

[Morituri]

I'm thinking, macro pad on the left side (putting the typing area closer to the middle), left and right hand typing areas extended by one additional column each (in the center), and the whole typing area made one row deeper. So, probably about the same size as a gaming keyboard with its macro pad and the extra row of space gaming boards tend to add to the top. It's wasted on most gaming boards because they put no more keys on it.

Number of macros available (layers) could be arbitrarily extended by allowing multi-key macro triggers. They start with a macro pad keystroke but can be continued with zero or more additional, until any trigger was complete. Like having the m3 key labeled "passwords" and then the macro for every password be that button plus the name of the thing it's a password for, like "m3, bank" or "m3, deskthority" etc.

But the main extension I want would be the way the typing area itself behaves. Something like a way-extended altgr functionality built right into the board that keeps adding to composed characters for as long as there is at least one key that is still depressed and there is at least one composition target that the sequence could be leading to. And then when all keys come up, or there is no longer a possible composition you could be typing, the target unicode cluster gets sent to the computer as input. And I'd be happy for that to be built-in and not subject to user configuration except by key-swapping; it would constitute a general unicode-aware input mode rather than user-specific configuration.

But THAT functionality is where the interests of gamers and geeks diverge sharply. Gamers do not want to wait until key release for the things they type to be sent, and they do not want character compositions like G-with-underscore-and-caret ever. So, yeah, maybe a physical switch that turns that business on and off.

So, mostly it's about the way the keyboard behaves and the fact that you can't easily type most of unicode the way keyboards behave now - not about the number of buttons and/or macros available.

I mention this because I may eventually write it into a keyboard controller, and/or build a reduced version of it into a USB-to-USB adapter that people could put between their keyboard and the computer. What I hope for in this thread is for people to tell me what keyboard *BEHAVIOR* they want that's different from the way they work now.

Edit: I've hacked up a layout to show what I'm talking about. It's the same size as a couple gaming keyboards I've got, but 60 new keys are here. I've left them unlabeled except for the three above the arrow pad. (to allow mouse operations from the keyboard - though you might still want a real mouse for smooth control. )

[DMA]

I've read a fair bit of HID 1.12 specification.
Can you show me on this doll how are you going to transmit unicode chars from HID device to host in a way that OS understands your theoretical device without writing drivers for every OS?

I can guess that you probably want to use usage page 0x10 somehow.
Setting aside a question that UCS-2 can't fit all Unicode characters (which you, as a geek, _must_ care about) - this would not be a keyboard, from OS standpoint.
So - tadaaa - you'll need to write a driver for every OS you need to support.
You can use usage page 0x09 - programmable buttons. There's 65K of those, after all. You'll need a lot of 0x0As for those, of course - 8Kbyte bitmap But that's also would not be a keyboard. So again, you'll need drivers.

That's about answers the question about why there's no such thing in existence.
Also HaaTa has the answer of USB-IF about unicode in keyboards. If you have $4k plus 3 companies, you can alter the HID spec. Doesn't mean all OSes will have support for it immediately (or at all)

You can do macros. Lots of macros. Each of those will actually switch the layout and output scancodes needed (no, you can't use AltGr+code - the method is different across OSes.
You'll need lots of memory for that. Luckily, it can be flash - you don't need to modify that part too often. Don't know if you'll be able to use off-chip flash - but my gut tells me that nope you can't.

Also 1GB of NVRAM costs a quarter of what, exactly? Quarter of one hundred dollars?
Also please point me towards the device with two USB controllers and 1GB of flash for 6 USD. I'll use it right away for my controller - I don't even mind all the porting work. Because I have to do with 64KB of flash and, IIRC, 16KB of SRAM to bring the MCU cost under 5 USD for my controller - IF I plan to produce it. Prototyping kits are $10 for the whole device, that's OK for one-off stuff.

Of course you can always go and use raspberry Pi as a board controller. Put Linux on it, pretend you're USB network adapter _and_ the device behind it, install synergy and here you go. Need to check, but AFAIR synergy protocol transfers actual symbols instead of scancodes. Raspberry Pi also has HDMI output, so you can connect monitor right to it, no need for the computer

PS: Oh, also emojis. That stuff is toxic all by itself - but it also takes 4 bytes, however you slice it.

So, I'm eagerly waiting for the description of how to feed unicode to the OS using HID and no custom drivers. I even promise to implement it in a couple of months.

[kbdfr]

But the main extension I want would be the way the typing area itself behaves. Something like a way-extended altgr functionality built right into the board that keeps adding to composed characters for as long as there is at least one key that is still depressed and there is at least one composition target that the sequence could be leading to. And then when all keys come up, or there is no longer a possible composition you could be typing, the target unicode cluster gets sent to the computer as input.

Basically, this means keeping a key pressed with one hand and then having the other hand travelling all over the keyboard to type the required characters, which is a rather cumbersome procedure particularly for longer strings of characters.
Plus, this is an error-prone "blind" procedure where you press successive keys without any feedback.

It is clear that once programmed, the keyboard must be able to work with any OS, which means the configuration must be stored in the keyboard itself and the keyboard be recognized as a standard keyboard by the computer.
But no programming software on the computer, as you require, means you actually have to exactly know everything you are programming. Not a problem if you only want to reproduce usual keystrokes (for example a Unicode sequence), but how would you insert e.g. a beep, or a delay inside a macro, or program media keys?

The layout you show has 28 columns and 7 rows, the keyboard I use has 32 columns and 8 rows.
The real difference between them, though, is that mine actually exists - and works

[kbdfr]

Oh, and by the way, without even taking into account the usual alpha part of my keyboard,
it has additional 160 keys programmable in 4 layers - that's 640 different characters/macros
each directly available and that can be placed in meaningful clusters.

[eekee]

Anyway, I don't want extra keys, as such. I want extra functionality and am willing to put up with extra keys to get it. A macro pad is nice, but any particular macro only does one thing.

I want a keyboard where arbitrary key *combinations* or *sequences* can trigger different characters or functionality. Because there are vastly more combinations and sequences that make actual SENSE as ways to type Unicode characters, even on an ordinary keyboard, than there are macro keys, even on kbdfr's board.

Too many keys make things uncomfortable for me, and I rarely remember what's not printed on the keycaps, so I'm planning on taking some tips from colorForth: relatively few keys (but more than colorForth's 24); switch modes, and display the current layout at all times.

Without software on the computer, I'm planning on having a display attached to the keyboard. I want two separate keyboards basically; one for each hand, with a trackball or trackpoint attached to the left side of the right board (dominant hand). The mode switch keys will go on the right side of the left board and/or under my left thumb, with one key per mode and no automatic switching; no funny business. I mean when you press a mode switch key, the keyboard switches to the mode assigned to that key regardless of what mode it was in before, and doesn't switch back until you press another mode switch key.

I'm also considering a matrix layout because I find the normal stepped arrangement makes it difficult to put my fingers on any alternate use of the keys (such as laptop num pad and even WASD), and I don't find it very comfortable even for normal character typing. I'm going to get some matrix TiPros to try it out if life doesn't kill me first.

For a controller, I guess I'll probably use something from Texas Instruments' Launchpad range. I love TI, they make eval boards cheap. I think all the Launchpad boards have these BoosterPack interfaces; there are lots of display options to connect to that. On the other hand, I expect I'll have a hard time programming it because USB is a huge pain; far more complicated than it needs to be.

I suspect the reason for small and finite layout capacity is simply that they're using small, off-the-shelf controllers with only a tiny chunk of onboard flash.

Personally, I'd think the way to go is a micro-SD slot or embedded flash drive. You could then save the layout and send it to friends. However, that probably requires a lot more complexity at the controller level.

Small amounts of Flash are still common, small amounts of RAM even more so, but the situation is slowly changing. You probably won't ever find gigabytes in economical controller boards; those chips require a lot of work in pcb layout, boot-time initialization, and generally integrating into the system, but kilobytes are getting plentiful and i think you only need a two or three kilobytes per mode for a 256-key keyboard.

SD, like USB, like gigabyte-size onboard Flash, is a pain. Basically, there are no sane standards any more. They all require far more work than is necessary, and have sections which are hard to understand or downright vague. Still, it's likely there is reasonable example SD-card interfacing code available for Launchpads and/or similar boards.

Speaking of example code, Mortiuri: Are you planning on programming your controller yourself? If so, would you share the USB interfacing code which can send any character? Or links to existing examples.
Edit: and then I read DMA's post. Never mind. There's another thing wrong with todays standards: They invariably make it almost but not quite possible to do nice things.

Emulating a USB network device and the computer behind it is ok with some hardware. My Zaurus worked fine in this configuration, but Raspbery Pi version 1 in particular has nasty problems with this. I think it's an interrupt problem. A network keyboard sending its messages by the VNC protocol is fairly reasonable. Every major OS supports VNC, and I think almost every minor one does too, it's not hard to support. I've used it with Linux, OS X, and Plan 9, and had no problems except when I used IP over Firewire between Linux and OS X, and that was right when Linux was transitioning from an old buggy IP/Fw driver to a new experimental one. Notably, VNC served from Linux over USB-emulated ethernet to my Zaurus worked fine.

Mouse support over VNC might be strange, I think the keyboard would have to know the size of the screen, but that might be an advantage for some; it might be nice to control mouse acceleration in a standalone device, rather than by Linux's various methods. Linux gives you a choice of inadequate or over-complicated and ridiculously changesome controls for mouse acceleration.

[DMA]

On the other hand, I expect I'll have a hard time programming it because USB is a huge pain; far more complicated than it needs to be.

LUFA makes it much less pain, actually. You will still need to write descriptors, but that's not that hard - enough keyboard ones circulate around.

SD, like USB, like gigabyte-size onboard Flash, is a pain. Basically, there are no sane standards any more. They all require far more work than is necessary, and have sections which are hard to understand or downright vague. Still, it's likely there is reasonable example SD-card interfacing code available for Launchpads and/or similar boards.

Don't forget you need to drag in the filesystem support if you're going SD/USB host way! Forgot to write about that. Doable, probably has some frameworks that make it less painful even - but expect it to eat a lot of flash and a fair chunk of RAM.

Emulating a USB network device and the computer behind it is ok with some hardware. My Zaurus worked fine in this configuration, but Raspbery Pi version 1 in particular has nasty problems with this. I think it's an interrupt problem.

That was sarcasm! Though now I think that having the configurator as an app on the keyboard itself, so you can configure it by connecting external monitor or using SSH and running the app, would be a nice thing contributing to longevity of the device while saving development effort (you don't have to worry about portability, you have your own OS
..until HDMI connector goes the way of the Dodo, that is

[kbdfr]

I confess I understand next to nothing of what you all are writing,
but well, I’m just a keyboard user, and a satisfied one at that

So go on designing your ideal solution, in the meantime I’ll enjoy typing on my real Tipro