Seems easy enough to check if a device at a given I2C address is there and enable functionality. There few a few devices doing this already.
Via has been doing non-flashing keymap updates for years and is cross platform. Reach out and help contribute.
Here's hoping you can make a keyboard worth the name. Exposing interfaces to users can bodge on their own hardware would be a good start. Maybe getting a ergonomics nuts on the team as well.
I think the GP's idea is that a keyboard could report to the host how its keys are labeled so that the host could automatically select the correct keymap. This is indeed a very cool idea, but would certainly be a big effort to get implemented across all platforms.
This would be somewhat similar the more boutique input devices which are configurable in hardware.
Somebody should build a row of physical ESC+F-Keys that you could stick to your touchbar, + software fix that would make the touchbar display the appropriate keys. Kind of like those analog controllers you can stick to a smartphone.
Would love to but not planned, not yet. Focus first on iOS then we'll see... that said, Android keyboard API looks easier and there are probably even more geeks!
There is a GitHub issue for keyboard accessibility, although I don’t see this as a necessity it shouldn’t be too hard to add, so I will probably get to it at some point. Thanks for the feedback.
There was just a post about using a raspberry pi as a USB device. I wonder if that would make it a good candidate for their concept of a self-contained keyboard (no drivers)
Not defending MS, but keyboards already have controllers and have since at least the original PC (probably much earlier than that but I'm not very familiar with old mainframe terminals). Considering how many SKUs already exist for different layouts and the like, this isn't that big of a burden - at most, this requires updated firmware and pad printing layouts, and firmware already changes a decent amount as controllers and membrane layouts are modified for new SKUs and cost-reduction. And it's not like they have to update their existing stock or retool their lines right now, the phase-in will likely take some time.
Also, unless I missed something, I don't think the article says one way or another how this will be implemented. It could be a new scancode or emulate a key combo.
Looks to me like this type of device is the beginning of disrupting typing. Once you have a way to detect finger movement with something small, lightweight, unobtrusive (I'm making assumptions about AirType based on my own desires) and programmable, we can create the interfaces we want.
I want a device API for third party keyboards, and a split toolbar more for split keyboards. So that third party ergonomic keyboards can be developed building on this.
Yeah this is the easiest way to get started. You probably want a low travel keyboard and ideally a low-latency-variance one to make it easier to find the start. It can be tricky to find where the update ends too because you usually see several frames of lcd switching.
The more advanced version is putting together a microcontroller which acts as a usb keyboard pressing a key, then backspace, then the key again, and uses a light sensor aimed at the right part of the screen to detect rendering in a repeatable way (slightly different fonts/ positions might change when it triggers but that’s likely on the order of a few ms tops, much less than the variance from frame boundaries).
Via has been doing non-flashing keymap updates for years and is cross platform. Reach out and help contribute.
Here's hoping you can make a keyboard worth the name. Exposing interfaces to users can bodge on their own hardware would be a good start. Maybe getting a ergonomics nuts on the team as well.
reply