deskthority

Hi all,
with keyboard firmwares now running on increasingly complex microcontrollers, and with keyboards having stuff like displays, integrated memory, etc, I was wondering - why not put a full 8-bit micro in the keyboard?

This whole thing came after watching this really cool video of using the C64 as a serial terminal. I started asking myself what would be necessary to really make this practical. What if you could use the C64 as a full keyboard for any computer? Granted the switches aren't great and a bunch of keys are missing, but still, even the C64 would be pretty good at least for something like editing files with Vim. Then I remembered a video I watched earlier today, this review of the Reuters G80-9009 by Thomas, and this essentially has a large multiline screen integrated. The screen is definitely larger and more readable and holds more information than my Sharp 850V's integrated screen. So then it clicked: why not go all the way and make every keyboard hold something like an 8-bit microcomputer?

There could be so many benefits to this as far as using it as a keyboard:

1. Macro functionality. Being able to define simple macros is cool, but being able to use basic to program advanced macros is even cooler. Now imagine you're on eg Windows, and you can call out to Autohotkey functions directly (which wouldn't be that difficult using raw hid functionality). Or if autohotkey was even able to communicate variables back to the keyboard, eg what window is open currently, and based on that your macro could do one thing or another. For example, let's say you had a "next tab" button (as in next tab in the browser, editor, or terminal emulator window). In one program it might be ctrl+pgdn, and in another it would be ctrl+tab. It goes beyond that for me, though. Your keyboard is the way you communicate with your computer. Imagine if the way you communicate with your computer changed from a simple, shallow layer of key press -> key appears on screen to something that allows all sorts of complex, intricate interaction between human, machine, and the smart interface itself (the keyboard).

2. KVM functionality - it goes without saying that it would be simpler, especially if the keyboard had a dedicated serial output, which could be used to control kvm switches and the like

3. Terminal functionality - if the keyboard has an integrated display, say a 4x160 display, then you could easily use it as a full fledged terminal, given an rs-232 port on the back, or emulation of it via usb and an external ftdi232 dongle. Super useful for vintage computers, setting up home automation, and the like. Maybe if the SoC is smart enough, you could use ssh directly from your keyboard.

4. Sounds - solenoids and clickers are cool, but imagine what you could do given something like a sid chip or an atari pokey chip and a proper pc speaker type transducer inside

5. rgb - you could program your own really cool rgb effects in basic

6. automation - your keyboard could automate other stuff that can be controlled via serial, IR, bluetooth, ethernet, zigbee, or wifi. So as you are using your keyboard, you could use it to turn on the lights or make coffee.

7. Do computing without using or even turning on your main computer - if your keyboard has a display on it, then you could easily do some basic stuff (calculations, taking notes, writing small programs) without turning off your main pc

8. Compute on the go - most modern microcontrollers, even the more powerful ones, easily run off battery. If your keyboard has a display, take it out of your messenger bag while commuting or at the coffee shop and use it as a small 8-bit laptop.

9. Better calculator - it goes without saying that if you want your keyboard to have a calculator, then having a full programming language prompt available is even better

10. Add features easily - qmk requires knowledge of C++ and/or asm to add features. Many of those features are fairly simple and don't necessarily require the critical timing that's available via asm. Stuff like a calculator or an rgb animation is better done in a higher level language anyways. If you're committed and want to make your feature more cpu efficient, you can then re-write it in C++ or assembly.

11. The back of modern keyboards is sad - as someone who grew up with 8-bit computers, looking at the back of my keyboard... just kind of makes me sad. Compare to the back ports of a C-64, C-128, or an Amiga 500. All the cool stuff you could do with those ports! There was so much you could do here. If you've ever looked at the wild peripherals that vintage computers came with, you know what you're missing. Hook up a 5.25" floppy drive? A datasette, a vhs drive or LD as data medium? Composite output directly to tv? RGB output? Thermal printer, make some calculations on the internal calculator and print them out? Dot matrix printer?

12. Use cartridges with your keyboard - it's just cool. What do you put on the cartridge? New firmware? New software? A game? who knows. The sky is the limit. You can do anything with cartridges. Anything at all. The only limit is yourself. The infinite is possible with cartridges. The unattainable is unknown with cartridges. Cartridges are back baby

13. Use your keyboard to automate your mouse - if your keyboard was a bit smarter than it is now, your mouse could connect to and through it. This means that you could automate mouse movements using macros on your keyboard, as well as set it up based on that.

14. Games - play combat, pitfall, zork, adventure, oregon trail, or anything else on your keyboard. Want to port doom 2 or crysis? Sure, why not.

15. Experiment with non-standard keyboard layouts and keys - with the pc, we're pretty limited as to what keys we can really have on our keyboard. With this, you can have all sorts of cool keyboard functions that the computer will actually understand it, because you're who defines what keys it has and understands and what functions it can accept from the keyboard

16. Dial up - hook up your keyboard directly to a modem and call into your computer to do remote computing. It's even cooler if you consider that your Nokia 6210 contains an IrDA interface and a modem

17. Good excuse to start using your Nokia 6210 again - not like you need one of course

18. Connect all your keyboards in a token ring network - why aren't all your keyboards networked together already?

19. Fun - it's just cool

20. GOTO 1

So I think there could be several levels of this.

21. Full keyboard with extra keys, display, and a multitude of ports on the back. Essentially imagine something like a Cherry / Reuters G80-9009, but it's running a C64 style prompt inside it, anything it displays on the LCD is actually a program, and it has a bunch of ports on the back like an Amiga 1200. Not those exact ports, the port names are just examples. Probably has Ethernet and the likes too. And obviously, much better keyboard switches, and almost certainly not MX clones. I imagine if this were to become a project, and it were to become popular, producing a relatively simple lo-fi key switch like a beam spring switch wouldn't be out of the question (those switches specifically are actually not that complex, so I'm surprised no one has made a 1:1 copy of them yet).
22. Keyboard missing display. When using it with a PC, you could use desktop software that'll display what you would be seeing on the LCD screen. It could work as "OSD" overlay over your desktop. Or you could just hook up a second monitor, like a cute little 14" monochrome CRT.

23. Keyboard missing some ports. Just less expandability.

24. Keyboard missing all ports, only USB output. In this case, it would be a great feature to be able to hook up an external break-out board that has serial, parallel, video, and whatever else you'd like. Basically a docking station.

25. Cheap keyboard that doesn't do anything except USB output. In this case, if the keyboard still uses the standard firmware, it would make it possible to still do all the cool things via a break-out / docking station like in 4 above. If you're using the keyboard with a desktop computer, maybe you could proxy its ports to the keyboard to use like that.

26. Dumb USB keyboard with no custom firmware. In this case, you could connect it to the break out / docking station as above and that would function as the smarts of the keyboard.

Comparison sheet:
Beautiful, amazing, limitless: Sad, constraining, no future: Anyways, these are just the ramblings of a mad man.

Response to your first post.

add 1)
This firmware already supports some very simple grograms running in the keyboard. Although you propose much more powerful version, you should also realize security implications of it. If you allow easy reprogramming of the keyboard from the host then you could not trust what keyboard is actually sending to the host. That means that it provides a way to defeat keyboard redirection blocking of the operating system when user enters some security critical programs (e.g. a task manger entered from Ctrl-Alt-Del). Any functionality to reprogram keyboard should first authenticate user from within the keyboard itself.

add 6)
Just make sure it does not evolve into internet of things security nightmare

add 7-11)
I can imagine some usefulness of exposing some GPIO and peripherals from a keyboard and allowing keyboard use from a battery without a host. But this is a lot of work to do with an MCU. It may be a better option to take something like Rasbery PI with an LCD shiled. Let it run as a keyboard controller (USB HID device) and put a full linux on it ... with all the cool stuff like maxima or octave as a right calculator (instead of the poor substitutes like Windows Calc).

add 12)
SD card support is probably a better idea (more modern).

add 13)
Most open keyboard firmwares already support mouse emulation.

add 15)
At least the keyboard firmware mentioned in point 1 supports switchable layers with keymaps re-definable on the fly. Probably more open firmwares support it as well. Definitely some proprietary firmwares support it (e.g. Kinesis Advantage).

Hi, I'm new here! So apologies if I'm saying something stupid.

Wouldn't turning a keyboard into a full fledged computer with screens and everything defeat the purpose? We already have computers...

But certainly having some smarts in the firmware can be helpful in many ways. For this reason, I ordered a keyboard that supports the QMK firmware. Or is that too limited in some way?

What I would love is a good way for keyboards to send Unicode directly to the computers they connect to rather than just keycodes. That way you could for instance have an emoji key and that emoji is sent to whatever computer the keyboard is hooked up to at that point in time without the software on that computer having to be aware of the keyboard's configuration.

So ... you want your programmable keyboard to be ... programmable huh?

The microcontrollers in many of today's keyboards are far more powerful than what were used in 1980's 8-bit computers.

I think that the idea of having a scripting language in a keyboard firmware is a cool idea. But oh how much work it would be to implement it, and the command prompt, and the editor, etc....

You could emulate a serial port over USB, for:
- using the keyboard as a terminal (if it had a screen), or the other way around:
- logging in into the keyboard
The latter I think would be useful to get a larger window than the small LCD/OLED that you would have in the keyboard. And everyone don't even want a screen on the keyboard.

There have been several SID-chip emulators/replacements based on ARM Cortex-M microcontrollers, by the way. And lots of other synthesizers based on microcontrollers.

8. Reminds me of the Alphasmart: a word processor with a small display. Then connect it to the PC and away it types the stored text as if it was a long keyboard macro. But it would need a large battery.

11. USB has replaced most other ports. And that's a good thing.
Good mechanical keyboards with a good USB hub is lacking though.

12. The modern equivalent to a cartridge would be a SD card. There are microcontroller boards with SD card readers, so that could be done.
Having a SD card reader in a keyboard (for the host's sake) is something I have missed as much as a good USB hub. But I don't really see what the point would be for the keyboard itself to get access to the SD card if you could upload/download scripts and config files through the host.

13. Can't macros that press mouse buttons not already be done in TMK? Replicating movements however can be difficult. USB mice are often relative. USB mice could provide absolute coordinates though but the protocol is limited.

15. A USB or BT keyboard can only send USB HID codes. Unless you also have your own driver on the host side.

What's the difference between this and a laptop? Or, turning it around, how is this any better than a laptop?

hellothere wrote: ↑

22 Dec 2020, 02:59

What's the difference between this and a laptop? Or, turning it around, how is this any better than a laptop?

27. no laptop keyboard
28. your own keyboard layout
29. nicer keys. why not recreate beam springs for this?
30. a laptop can't be used as a smart keyboard. a strong idea here is to create a keyboard that is super smart. I don't even know of a way to use a windows / linux computer as a keyboard that inputs into another computer. I mean I've seen some details about a raspberry pi project like that, and you can always open a serial terminal and use a converter to usb of some sort, but i don't know the details and I don't think people will be doing a lot of that.
31. a laptop might have programming languages on it, but they're not going to be ones specifically meant for automating keyboard input
32. the keyboard itself is much simpler than a laptop. if you just want to write down a short note, or do a calculation, you can press the power, do whatever you want to do, and be done by the time a laptop would boot. the immediacy cannot be understated.
33. simplicity is a great bonus. being on a simpler system which is a bit limiting in some ways can spur creativity. It's a very common theme in creative work.
34. with the same amount of battery charge, a keyboard microcomputer with a simple screen will work a bunch longer than a laptop. so if you want to go to a retreat and write a book, why take a full fledged laptop with a crappy keyboard and 4 hours of battery when you can take a keyboard with nicer mechanical key switches and the ability to go for days without a charge?
35. you made it
36. it looks cooler

a few more comments:

37. i don't really care about sd cards. a cartridge isn't only storage. it can be an expansion card, a device, add ports, or be an sd card reader. an sd card wil probably be a good idea though for doing stuff like easily moving data from the keyboard to another computer if you want to do it like that. stuff like notes, calculations, scripts, layouts, ...

38. you can press mouse keys etc from tmk and qmk. but you can't use your keyboard to /configure/ your mouse, define macros on it, etc. you can't use it to /control/ your mouse, like change the dpi, disable input (for when you want to lock it out for some time while running an automation - super useful). you can't /record/ its movements and play them back.

39. a usb keyboard can only send hid codes, but a single usb cable can carry multiple devices, one of which can be raw hid.

40. using raw hid, you should be able to talk to ahk, and have ahk directly type in emoji and other unicode characters. for example, by modifying the clipboard, pasting them in, then restoring the previous clipboard, but maybe there's a better way to do that still. the windows emoji / unicode entry on-screen keyboard (win+m) uses some method to do this, and i bet this method is available to others as well. raw hid input is key to making all this work.

41. ps i edited my messages so they don't repeat list numbers, should be easier to know what people are referring to. messages now numbered 21-26 were previously 1-6.

42. one more thing about the "how is this better than a laptop" question. this sort of keyboard doesn't /have/ to include a screen or a battery. it could do without both, and whatever you would see on the integrated display would instead show up in a configurator screen on your windows/mac/linux/bsd's desktop/terminal, or as an osd-style pop-over layer, or it could be typing its output out directly, so you'd open a text file and you would start configuring it and it would type its "screen" out into the text file. when put this way, it's easier to see that this doesn't compete with a laptop, it competes with configurable keyboards by allowing more freedom in how they can be configured.

Actually QMK can already produce Unicode output, but this is specific to the host operating system. So you need to reflash your firmware when you connect the keyboard to another OS. With the Mac, this means you must use the Unicode hex input keymap, which means you lose the regular way of inputing accented characters. So that's a very all-or-nothing deal.

Here
The keyboard is just a USB HID, remove it and build your own enclosure with cherrymx or whatever and a screen if you want. Added bonus GPIO.

That being said I agree with Findecanor that most of MCU we use today inside keyboards are more than capable of doing anything and more a 8-bit computer could.

iljitsch wrote: ↑

22 Dec 2020, 08:11

Actually QMK can already produce Unicode output, but this is specific to the host operating system. So you need to reflash your firmware when you connect the keyboard to another OS. With the Mac, this means you must use the Unicode hex input keymap, which means you lose the regular way of inputing accented characters. So that's a very all-or-nothing deal.

it's very inelegant. essentially it tries to do the alt+hex code thing on windows or similar trickery on linux and mac. it's not real input, it's a kludge imo.

cheater wrote: ↑

22 Dec 2020, 09:08

it's very inelegant. essentially it tries to do the alt+hex code thing on windows or similar trickery on linux and mac. it's not real input, it's a kludge imo.

Exactly, that's why I'd like to see a more standardized way for keyboards to bypass keycodes and send Unicode characters, but in addition to the normal operation for keys that don't have a Unicode character binding.

By the way, about SID chips and the like in keyboards: I think there are actually keyboards with a speaker that can play arbitrary audio. So I guess if you use silent switches the speaker could play your favorite clicks, so you could emulate the sound of any clicky switch.

A bit like today you can emulate any guitar amplifier on a computer.

If you want unicode input directly in the keyboard then you need significant support of operating system vendors. The problem is that the input data flow works like this currently:

• keyboard firmware scans input matrix and sends resulting scan codes to PC
• a keyboard driver in PC handles keyboard interrupts and data processing and translates scan codes do key codes (this is to abstract different physical keyboard types)
• a higher input layer in the operating system translates key codes to key symbols according to the selected input locale (this is to allow to use the same keyboards over different locales)

Therefore if you want all unicode input chain then you need a new code for keyboard firmware, keyboard driver and the operating system locale specific translation layer. This is quite a change to how keyboard input processing works and the reason why you do not see any proper unicode keyboards.

Yes, there would have to be a new or updated USB capability that would have to be implemented at both ends. But the point is to bypass the locale stuff. So the keyboard knows what's on the keycap, so if it sends that Unicode character, that's it and the computer doesn't get to interpret that in its own way, it just takes the Unicode character as-is.

In theory you could use this to completely hardcode what key produces what character in the keyboard, but in general I don't think that's a good idea because although the current system with various keymaps is complex, it does provide the very useful feature of being able to change keymaps in software.

So the new Unicode capability would just be an addition, not a replacement. That way, I get to have my emoji function keys.

But perhaps the ability for the keyboard to tell the host what its keymap is so that could be the default would be a good addition.

matt3o wrote: ↑

22 Dec 2020, 08:44

Here

shot_1608622786.jpg

The keyboard is just a USB HID, remove it and build your own enclosure with cherrymx or whatever and a screen if you want. Added bonus GPIO..

Yours is a brilliant suggestion. At the same time, It would be nice to insert the raspberry pi 400 into a mechanical keeb of our choice, maybe our most liked one, without being forced to build a new one starting from the scratch. The dimensions of the raspberry pi 400 PCB should be 286mm × 122mm × 23mm. (Ask Chryros for an imperial conversion, LOL) I have already tried to get the measurements of the void space inside an IBM m122 type II, but despite my most optimistic expectations, it seems not to fit. Should I turn my gaze toward chubbier beamsprings?

Well, obviously the Raspberry Pi 400 already has a keyboard. So it makes more sense to use a regular Raspberry Pi without an enclosure or peripherals.

I await the first Cherry Pi.

iljitsch wrote: ↑

22 Dec 2020, 16:52

Well, obviously the Raspberry Pi 400 already has a keyboard. So it makes more sense to use a regular Raspberry Pi without an enclosure or peripherals.

I await the first Cherry Pi.

rpi400 is easier to fit into a keyboard due to the form factor

vvp wrote: ↑

22 Dec 2020, 11:40

If you want unicode input directly in the keyboard then you need significant support of operating system vendors. The problem is that the input data flow works like this currently:

• keyboard firmware scans input matrix and sends resulting scan codes to PC
• a keyboard driver in PC handles keyboard interrupts and data processing and translates scan codes do key codes (this is to abstract different physical keyboard types)
• a higher input layer in the operating system translates key codes to key symbols according to the selected input locale (this is to allow to use the same keyboards over different locales)

Therefore if you want all unicode input chain then you need a new code for keyboard firmware, keyboard driver and the operating system locale specific translation layer. This is quite a change to how keyboard input processing works and the reason why you do not see any proper unicode keyboards.

iljitsch wrote: ↑

22 Dec 2020, 14:40

Yes, there would have to be a new or updated USB capability that would have to be implemented at both ends. But the point is to bypass the locale stuff. So the keyboard knows what's on the keycap, so if it sends that Unicode character, that's it and the computer doesn't get to interpret that in its own way, it just takes the Unicode character as-is.

In theory you could use this to completely hardcode what key produces what character in the keyboard, but in general I don't think that's a good idea because although the current system with various keymaps is complex, it does provide the very useful feature of being able to change keymaps in software.

So the new Unicode capability would just be an addition, not a replacement. That way, I get to have my emoji function keys.

But perhaps the ability for the keyboard to tell the host what its keymap is so that could be the default would be a good addition.

43. that's not really true. you can have best of both worlds like iljitsch would like by having the keyboard expose itself as two usb devices: one usb keyboard, and one raw usb hid device. the usb keyboard is treated normally by the OS, with layouts and whatever else you might want. the raw usb hid device is handled on the system side by your own software, whether it's your own driver for the usb hid device, or a user mode application. On windows the gist of it is that you'd either:

44. use the SendInput() function with the KEYEVENTF_UNICODE flag (link)

45. use SendKeys.Send() which is apparently unicode aware by default, but maybe you need to use the KEYEVENTF_UNICODE flag still (link)

46. make your handling program put the desired string in the clipboard and then SendKeys("^V") to paste; later restore the clipboard (link)

47. for Linux, you'd try to figure out what AutoKey does and copy that method, but I am not sure if it is unicode aware. I assume that at least in X11 you should be able to do Unicode aware things, not sure about Wayland. Not sure how it would work in raw tty. There are probably ways to do this in each of those cases.

48. for MacOS, there are some ways but I don't really use MacOS so I can't speak to it.

matt3o wrote: ↑

22 Dec 2020, 08:44

Here

shot_1608622786.jpg

The keyboard is just a USB HID, remove it and build your own enclosure with cherrymx or whatever and a screen if you want. Added bonus GPIO.

That being said I agree with Findecanor that most of MCU we use today inside keyboards are more than capable of doing anything and more a 8-bit computer could.

49. honestly I'd really like a keyboard to be wireless, which kind of precludes using the raspberry pi, as it uses between 100 and 600 mA when merely idling depending on the model used. However that's with their standard OS and not custom firmware which I would use anyways if I wanted to.

I think the best idea is to have the keyboard's core functionality in an ultra-low-power device like msp430, and have higher functions (configurability, interactivity with its UI, basic/forth/some scripting language interpreter, more involved external peripheral control) inside a more powerful microcontroller. Finally, the most powerful stuff (display control, hdmi or vga output, compiling configured code down into efficient msp430 code) could be done on an SoC. The msp430 is essentially running all the time, most of the time in ultra low power state, and the more power hungry chips get booted every time you're doing something involved. msp430 is the kind of thing used in places like bluetooth earbuds etc where every microamp matters. it's probably a good idea to not use an involved configurable code base on it, and instead recompile a binary image for it every time you want to change the behavior of the code running on it, to maximize efficiency and minimize power draw. once you're done compiling, shut down the power hungry parts.

50. on the other hand i'd love for my keyboard (as opposed to a build someone else would do for themselves) to also have a solenoid or a vfd, which may take more power than a raspberry pi... so having a hefty battery pack might be written in the stars anyways. a 128x32 vfd from Noritake Itron uses ~ 223mA typical input power, which isn't that much, and 200 of it is the filament current. So maybe it's not as much as a raspberry pi. And you can turn it off when not using it. No idea about the solenoid though. Probably a lot. But then it's more of a fun gimmick and maybe I won't be using it all the time. Maybe on AC power only.

51. with a display that's somewhat power hungry, whether LCD or VFD or even OLED, maybe with a mechanical switch you could sense when it's starting to be depressed (but before it actuates) by including extra contacts. This would let you turn on the display upon a light touch, without the user committing to the key press. This will work best with a long throw switch like a beam spring. Something like an additional optical switch mechanism in side the same switch could be used for this purpose.

52. the nice thing about splitting the keyboard cpu into:
i. ultra-low-power device
ii. medium power device
iii. SoC

is that with a wireless keyboard you can put the ultra-low-power device in the keyboard, on battery power, and meanwhile have the medium or high power devices on the other side of the wireless link, hooked up to usb or mains power. so if you have an LCD that displays an involved user interface, a spreadsheet, or advanced calculator, then you could make that actually run on the wireless base station / dongle, and have the input and output communicated via the wireless link. the question remains whether this will be more power efficient. most likely yes.

53. having the medium and high power devices off-board would preclude using the keyboard with dedicated outputs (serial, parallel, ethernet, ...) that are integrated into the keyboard. it would also preclude it from working fully autonomously - you'd have to have the base station with you, and powered off a battery pack of some sort. for this reason, you could have one of two solutions.

54. you could have the base station be a module that clips into the keyboard. if you're on the go, just grab it from the desk and put it in the keyboard.

55. you could have duplicated circuits: one copy of the medium and high power chips in the base station (for use when you're using your keyboard at home) and one copy when you're on the go. this seems to be more robust as you are less likely to spoil your time by forgetting to take your base station with you.

Grrr. Forum ate my post.

I'll grant you that this is a fun thread, but it still sounds like you want a laptop with a dock or a phablet with a dock. I'm not seeing how a keyboard with extra stuff is any better.

I do understand to some degree. I'm getting a mechanical keyboard to replace my Unicomp which replaced my Model M. One of the things I'm very much looking forward to is setting up the keyboard in ways that the Mac doesn't support, or only with relatively hacky software. For instance, something as simple as using other keys for media control than Apple's defaults.

Something programmable that sits between the keys and what the computer sees can be useful, and if you want to go all out but still make the keyboard wireless then it makes sense for that extra functionality to be something separate and not inside the keyboard because then you'd need a fat battery.

It may actually make sense to have a small terminal emulator / macro handling device that sits between a regular keyboard and a computer, taking care of the difference. I'd say the hardest thing about that would be controlling the RGB lights on the keyboard as well as a built-in controller would. But of course RGBs use a lot of power, too.

You could still use the keyboard without the extra device but with reduced functionality.

hellothere wrote: ↑

22 Dec 2020, 21:02

Grrr. Forum ate my post.

I'll grant you that this is a fun thread, but it still sounds like you want a laptop with a dock or a phablet with a dock. I'm not seeing how a keyboard with extra stuff is any better.

this might be your solution when presented with this problem, but not mine. i know what i want - i don't need to be told what i want but thanks none the less

iljitsch wrote: ↑

22 Dec 2020, 22:06

I do understand to some degree. I'm getting a mechanical keyboard to replace my Unicomp which replaced my Model M. One of the things I'm very much looking forward to is setting up the keyboard in ways that the Mac doesn't support, or only with relatively hacky software. For instance, something as simple as using other keys for media control than Apple's defaults.

Something programmable that sits between the keys and what the computer sees can be useful, and if you want to go all out but still make the keyboard wireless then it makes sense for that extra functionality to be something separate and not inside the keyboard because then you'd need a fat battery.

It may actually make sense to have a small terminal emulator / macro handling device that sits between a regular keyboard and a computer, taking care of the difference. I'd say the hardest thing about that would be controlling the RGB lights on the keyboard as well as a built-in controller would. But of course RGBs use a lot of power, too.

You could still use the keyboard without the extra device but with reduced functionality.

versatility is a great aspect.

@cheater:

add 43) When cheating with SendInput API: It probably will not work as users are used to with typical keyboards. E.g. pressing "shift" on one keyboard and key "a" on another will not produce capital A. But you can still work around it by also monitoring standard keyboard stream and adjusting what you send with SendInput API.

add 44,45) Yes you can go with SendInput() API and it will work almost nice (sans some issues with the Unicode input not interleaving with standard input). You probably can do it all from driver only with DPC on windows (workques on linux). You will need code signing certificate for windows.

add 46) Calm down. You definitely do not want to spoil clipboard with every keystroke. It would render clipboard unusable for users.

add 47) If you ever find out more about how to do it in terminal, wayland, and X11 with Unicode support then please post

you're not "spoiling" clipboard if you save it off first.

Well, there are application which monitor clipboard and those will mind. Also I'm not sure whether all controls accepting keyboard input will accept also clipboard.

But point taken. It is not that bad. You possibly can hack around the standard key processing reasonably well with clipboard as you can (probably better) with SendInput.

vvp wrote: ↑

23 Dec 2020, 13:37

Well, there are application which monitor clipboard and those will mind. Also I'm not sure whether all controls accepting keyboard input will accept also clipboard.

But point taken. It is not that bad. You possibly can hack around the standard key processing reasonably well with clipboard as you can (probably better) with SendInput.

I think you have a pretty good point with clipboard monitoring etc. It looks like SendInput etc are way better. But I guess it also bears considering whether "clipboard monitoring" is "using it the wrong way". It's a fairly special way of doing things, so I assume whoever is doing things like that is smart enough to be able to adapt to something like this. Whatever software you're using that monitors the clipboard, hopefully it's open source.