Design suggestions for split keyboard - Page 1
Forum section: electronics / general

author: eigenvektor
author_rank: Contributor
timestamp: February 03, 2023, 08:23:53 pm
content: Hi,I'm designing a split keyboard (each hand has it's own half keyboard) and was wondering how to approach this.I want each half to have 2 usb c ports, one at the top to connect to the computer and one on the side to connect the other keyboard half. The goal would be that each half can be used independent,or slaved to a half connected to the computer.My original plan was using a pic18f24k50 8bit microcontroller supporting 1 USB connection. The top usb c port would get the usb connection, while the side-usb port would be connected to UART on the mc. (UART would be stepped down from 5v to 3v3 using a logic level converter to conform to USB specifications).With the recent hype for the wch RISC V mcus I've thought about using a CH32V203 instead. It's cheaper, supports 2 USB connections (1 device and 1 host/device), is 32 bit, much faster and more memory. However the packaging options aren't great: a QSOP28 package is too large, QFN48 would fit but it seems ridiculous to use such a package for half a keyboard.Are there any other low cost MCU's I should consider or should I approach this in a different way? This is my first microcontroller project and figuring out what should happen when 2 keyboard halves are connected over USB sounds a bit complicated. I've attached a schematic to hopefully make this easier to understand.Thanks!

author: ejeffrey
author_rank: Super Contributor
timestamp: February 03, 2023, 09:15:14 pm
content: Quote from: eigenvektor on February 03, 2023, 08:23:53 pmDo you mean you would run the UART over a USB-C connection, or that you would use a USB->UART adapter chip like the FT232 family?If the former, please don't. USB type C is confusing enough as is, don't put a non-USB USB port on devices.If the latter, that won't work. USB does not support "peer to peer" connectivity. All communication is from 1 host to 1 device. The FT232 USB chips are devices, not hosts.QuoteI would avoid implementing a USB host if possible. The easiest solution is to use a UART for side-to-side communicaiton, just over a different connector than USB-C. This could be anything: M8, RJ11, RJ45 all have common pinouts for serial connections. Alternately, you could use a USB hub chip and add a downstream hub port to each half. This would provide extra utility since you could use the extra port for anything (like a USB flash drive or security key), but would mean that the correct way to chain them is to connect the top port of one to the side port of the other, not side-to-side.Finally, keep in mind that (at least traditionally) BIOS had quite limited device compatibility for boot time input devices like mice and keyboards. I think modern EFI systems have greater compatibility, but you may have trouble using your non-conventional keyboard for BIOS/EFI.

author: thm_w
author_rank: Super Contributor
timestamp: February 03, 2023, 10:21:27 pm
content: You are making this far too complicated. Just have the one main USB port on either the left or right side.Also, using any micro thats not supported by QMK will make your life about 10x harder:https://github.com/qmk/qmk_firmware/blob/master/docs/compatible_microcontrollers.mdAssuming you are interested in that featureset.If you are dead set on using a USBC connector for serial connection between the two sides, just go for it. Don't really care if its non-compliant, its not like you are selling it as a product.

author: ejeffrey
author_rank: Super Contributor
timestamp: February 03, 2023, 10:32:45 pm
content: One more thing:QuoteI wouldn't worry about the package at all. That chip may or may not be a good fit, but don't worry about the package, as long as you are able to assemble it.

author: eigenvektor
author_rank: Contributor
timestamp: February 03, 2023, 11:57:15 pm
content: Sorry for the late reply, didn't have WiFi on my bus.Classically, these types of keyboards are connected with UART over TRRS aux cable. This isn't hot swappable however, as pulling it out causes a short. I wanted to go with usb c as it just seems elegant having everything connected with usb c to usb c cables.So yes I meant running the UART over USB-C and telling the user to pretty please not plug it into anything else. Hence stepping down the voltage, never trust em :PQuoteI need a slim connector, the attached render of an older version shows what it's gonna look like. There's not much space for anything other than usb micro / c.Depending on how it turns out selling it is an option.As for assembly: board will be entirely single sided smd components, though I have soldered larger pitch QFN packages with an iron already.

author: thm_w
author_rank: Super Contributor
timestamp: February 04, 2023, 12:19:51 am
content: QuoteTRS can be hot-swappable, if you handle the short in hardware.

author: eigenvektor
author_rank: Contributor
timestamp: February 04, 2023, 12:29:54 am
content: True, but is it really better to have UART out of an aux port than UART through USB? Call it a matter of taste but I'd prefer to have USB.

author: NorthGuy
author_rank: Super Contributor
timestamp: February 04, 2023, 02:27:47 am
content: I don't understand why you need two USBs on the chip.PIC32MM0064GPM048-I/M4 is QFN and is cheaper than your PIC18. It is 32-bit, and has more memory (although you don't need any of these). More importantly, it doesn't require a crystal which will save you some space and money.Make sure it is safe connect USB cables from the host, phone, or charger to your USB-C connector because many people will do this.

author: ejeffrey
author_rank: Super Contributor
timestamp: February 04, 2023, 04:33:45 am
content: Quote from: eigenvektor on February 04, 2023, 12:29:54 amYes in my opinion it is absolutely better to use TRRS than USB connectors for a non standard UART.

author: fchk
author_rank: Frequent Contributor
timestamp: February 04, 2023, 08:42:58 am
content: Most environments support multi-mouse and multi-keyboard operation. There is no need for a connection between the two parts - just plug them both into the PC.Note: HID Keyboard and HID Mouse can have a simplified "boot protocol" for BIOS support. Windows and Linux don't use this, so it's optional. I don't know, however, if BIOS environments support multi-keyboard operation. For these rare events you would need a standard keyboard.fchk

author: mariush
author_rank: Super Contributor
timestamp: February 04, 2023, 09:25:16 am
content: If you want to keep it simple, a 4 wire cable and a couple RJ11 connectors would be enough... power, ground, data, clock ... SPI or I2C between the two parts.Whichever parts gets to be connected to usb becomes master and receives keys from the other and forwards them to the computer.I was thinking of using barrel jack connectors with a thread lock, and modulate the data over the voltage wire (ex 2.5v constant, 3.3v or higher are 1s and send bits at a constant frequency like addressable rgb leds works, with some prefix pattern so that the other can sync on the frequency) but that becomes complicated fast.. unnecessarily complicated.Another option could be to just have a battery in each one and use a bluetooth module to pass keys between the segments but then only the part connected to usb would charge over time. You could add some solar cells on top of the keyboard somewhere to slowly charge the batteries, or maybe a QI charger on the bottom of the keyboard so that user could charge the keyboard by placing it over night over a charger disc.

author: exe
author_rank: Unknown
timestamp: February 04, 2023, 10:32:21 am
content: As an idea.I usedhttps://nicekeyboards.com/nice-nano/and ZMK firmware for "true wireless keyboard". It is convenient, but a bit expensive and range is not great, but I also have installed facedown, where antenna is relatively close to the pcb, may be that shields the signal. There might be other (cheaper) boards supported by ZMK.

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 04, 2023, 12:59:16 pm
content: My own first microcontroller project was a honking big gamepad (on a 50×20cm or 20"×8" birch plank) with an arcade joystic and buttons using Teensy 2.0++ (AT90USB1286) with native USB interface. It had a small absolute hexadecimal encoder on it, for me to select which keypresses the joystick and buttons generate, so I could play Flash games (platform puzzles) more comfortably.I would suggest you use any microcontroller with native USB interface, and use the USB HID protocol, so no OS drivers are needed. As thm_w mentioned,Quantum Mechanical Keyboard Firmwareis a pretty good option here. Personally, I'd use a Teensy LC, and program it in the Arduino environment using the keyboard support library that comes built-in with Teensyduino, though.However, I would also put an USB hub in each, and wire the microcontroller in each keyboard half directly to one downstream port, exposing the other downstream port(s).This way, the user can plug in the (hub upstream port in each keyboard half) to a host, or to the other keyboard half as long as that half is connected to a host or to a hub that is connected to a host. If you limit to keyboard/mouse/human interface use, USB 2.0 full/high-speed hubs will suffice, and are very easy to use. Mouser, for example, has Microchip/Atmel USB2412 with two downstream ports in stock, for 2.45€ apiece, that only requires a 24 MHz crystal and some bypass capacitors; just use the schematic and suggestions from the related application note orhardware design checklist.One of my pet peeves is the limited rollover and/or ghosting in custom keyboards. I personally always use Schottky diode pairs in SOT-23 or SOT-323/SC-70 in the matrix, just to get rid of that ghosting (letting me detect each key independently of any other key state in the matrix). Sure, it's an additional 50 or so components on a 100-key keyboard, but BAT54C costs ~ 7€ per 100, and I find it easily worth it; others do not.

author: eigenvektor
author_rank: Contributor
timestamp: February 04, 2023, 01:08:22 pm
content: Thanks for suggesting the PIC32MM0064GPM048-I/M4, I'll have a look :)The PIC18 does have an internal oscillator as well.Classically yes one would connect the 2 halves with I2C, SPI or UART. Like I mentioned, RJ11 won't fit unfortunately, the goal is to have the board be as low profile as possible. That means stacking PCBs like the nice-nano is not an option either, I'd much rather implement that on the main board myself if at all. Going bluetooth would be an option, but would mean having to allocate extra space for a battery and designing a battery management system. I currently have neopixel LEDs on the board, would have to see how much runtime I would get with those, but going cable-free would be very elegant.Here's an idea: If I declare alternate mode through the CC pin, wouldn't that allow me to send data in whatever form on most other pins? With UART or I2C I could even limit myself to only the SBU pins (I'd have to use logic for detecting cable orientation though).If a neat solution can't be found going for just one USB port per half and connecting them both to the computer might indeed be the way to go, just seemed nice to offer the option of using only a single USB port on the host, and maybe being able to use each keyboard half as a hub to connect extra stuff if the mcu supports 2 USB connections.@Nominal Animal: 2.45EUR seems a lot for hub if the mcu costs less than 1EUR. As for ghosting: I'm using a full matrix with diodes on every key, so n-key rollover with no ghosting.

author: mariush
author_rank: Super Contributor
timestamp: February 04, 2023, 01:25:45 pm
content: The way JLCPCB is pushing down prices, you could probably afford to make a 4 layer or even a 6 layer pcb and route all the traces to some port expanders or parallel to serial register chips and have 100+ independent keys.I see 400mm x 150mm 4 layer boards (5 pieces cost around 65$ and 6 layer boards are around $110If you manage to make both sides have identical pcb you could do one order with boards half the width for even less price, and use 2 of the 5 pcb to build your keyboard.

author: eigenvektor
author_rank: Contributor
timestamp: February 04, 2023, 01:30:51 pm
content: I don't need 100 keys and it all fits on 2 layers (no need for impedance matching at these low speeds).

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 04, 2023, 01:32:18 pm
content: Quote from: eigenvektor on February 04, 2023, 01:08:22 pmHave you looked at what good-quality keyboard switches cost? The cost of the MCU and the hub chip is a tiny fraction of the overall cost, because good-quality keyboard switches will be the major cost of the project (assuming you 3D-print the enclosure, otherwise makingthatwill be the major cost here).It is a bad idea to be cheap with the MCU here. Pick one that your preferred toolchain has good support for, instead.

author: eigenvektor
author_rank: Contributor
timestamp: February 04, 2023, 01:39:16 pm
content: about 20 cents pp in single keyboard order quantity, cheaper with higher order quantity ofc. Adding 5EUR / keyboard would be quite substantial, but it's an option I'll consider, I'm sure there are cheaper hub controllers.As for the MCU: considering future projects I think gaining experience with 32bit RISC V MCUs would make much more sense than 8bit PIC 18 cores.

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 04, 2023, 02:56:58 pm
content: Quote from: eigenvektor on February 04, 2023, 01:39:16 pmMe too. I'm just a hobbyist on the electronics side, and looked at Mouser (because that, or LCSC/JLCPBC, is what I'd use); a few euros per unit would be irrelevant for me for a small batch.Edited: That said, LCSC does haveWCH CH334S and CH334Uchips in stock for about 0.60€ apiece right now. If only there was an application note in English...Just like I did with my arcade-joystick-as-keyboard project, I'm sure you'll learn a lot about exactly what you want the design to achieve –– you did say this is your first microcontroller project ––, and will probably want to do a respin/redesign afterwards, after you know more. (I myself found I prefer to have the joystick on the right and the buttons on the left, opposite to what is typical on most controllers, for example; and that starting with an even more massive chunk of birch would have been nice, because of the extra weight, allowing me to carve/shape the upper and lower surfaces, with better designed "pockets" for the electronics and arcade switches.)For a truly low-cost solution, WCH does have cheap USB-capable microcontrollers (with 8051 cores) that would be suitable for this. I designed a simpleUSB Gamepad using CH551G, intended to be used with standard 12x12mm tactile buttons, and programmed usingsdccand loaded using librech551 or ch552tool. I couldn't get the chips from LCSC/JLCPCB, but CH554G is now available, so I could respin it and see how well it works.. but Olimex has OSHWESP32-C3(WiFi & BT, RISC-V, USB) with LiPo connector and ~ 15 GPIO pins, at an affordable price with a couple of choices of LiPo batteries too, so I could just get a couple of those and make a wireless-capable one instead.Quote from: eigenvektor on February 04, 2023, 01:39:16 pm32-bit ARM cores (Cortex-M0+, Cortex-M4, and Cortex-M7), and RISC-V, are supported by both GCC and Clang, so you can use up-to-date FOSS toolchains for development. I like that, because I don't want to be stuck with a single vendor (although I do believe there are multiple C compilers for PIC18).(I do do both proprietary and FOSS development, under various licenses. Tux (my avatar) is just my mascot, not my idol.)

author: NorthGuy
author_rank: Super Contributor
timestamp: February 04, 2023, 03:20:12 pm
content: Quote from: eigenvektor on February 04, 2023, 01:08:22 pmIt is not accurate enough for USB, so you would need an external clock source.

author: eigenvektor
author_rank: Contributor
timestamp: February 04, 2023, 03:56:48 pm
content: @Nominal Animal yes I'm just always thinking about how to make this as easy to mass produce as possible (2 layers, all smd components on one side and so on) hence the slight obsession with cost.It does sound like you have a lot of experience with such projects, thanks for sharing the knowledge! :)Technically this would be the third complete overhaul of the project already. I've already had boards produced for my latest version, didn't like the key placement so changed it up again and had boards produced for v2.1, I'm really liking the form factor and key placement. Haven't gotten to programming it, but I'm having doubts about how I'm approaching this (UART over USB-C, microchips proprietary compiler, wanting to use ARM/RISC-V in the future).Since the CH32V203 has native support for 2 USB ports, one of the supporting both host and device it just seemed like a perfect solution (except for the horrible packaging) if I can negotiate who's host and who's device when connecting two keyboards together.@NorthGuy no idea how I missed that, just checked the datasheet and you're right. Although curiouslyhttps://hackaday.io/project/63204-usb-c-usb-pic-bootloaderdoes provide a "no xtal" hexfile for the pic which you're supposed to use with USB...

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 04, 2023, 04:34:33 pm
content: Quote from: eigenvektor on February 04, 2023, 03:56:48 pmMakes sense.Quote from: eigenvektor on February 04, 2023, 03:56:48 pmOnly as a hobbyist, though!I do like to play with human interface devices, and am quite familiar with the Linux input subsystem.I have seen the problems others working on hobby-custom HID devices with serial-to-USB bridges (not capable of USB HID) have had; and consider myself extremely lucky having started with AVRs with native USB interfaces, as they're quite easy to program even with open-source toolchains, but are simple/straightforward compared to current 32-bitters with their numerous peripherals and details.I definitely recommend using an MCU with native USB so you can have a couple of HID endpoints + USB Serial for run-time configuration, per MCU. While Linux is very flexible with HID devices, some other OSes are pickier and don't like nonstandard report mixes of HID devices, so modeling ones own so that it is roughly similar to what is already widely used in the market gives maximum OS compatibility.So, whatever MCU you pick, make sure you can find an USB HID example implemented on it, unless you intend to use an existing open-source firmware like QMK mentioned earlier. It is much, much easier to start with an existing USB HID example, and then modify it to suit ones own needs, than start from scratch.I already mentioned I personally would probably just embed aTeensy LCfor my own one-off or prototype keyboard PCB, with a separate cable-type USB hub, because of the low cost ($12 when in stock) and theUSB HID Keyboard supportTeensyduino provides (take a look at the examples on that page for an example). Note that Teensies aren't well suited for mass-produced products, however, because the bootloader is proprietary.Because I know the keyboard PCBs would need a few design iterations to find out the best layout et cetera, I'd use an IC socket for the Teensy LC, so that I only would need to solder a socket to the (bottom at the back of the) PCB, the key switches, and the diodes. I'm pretty sure the switches can be desoldered without damage, but I'd prefer to avoid having to rework the rest. So, I could trivially just lift the Teensy LC from one board to another.I believe the only way toknowwould be to test it in practice for a few days; try to write some code, documentation, or something else actually meaningful/important, and see how it works. Heck, even measure the statistics while using, to compare the different boards quantitatively.After I'd found a working layout and matrix/schematics, I'd know exactly what features I want. For example, I like those small I²C-controlled OLED displays (128x32 and 128x64) to occasionally show information like the current mapping; even my gamepads have those for that exact reason!)Onlythenwould I look at existing microcontrollers and possibly USB hub chips, to see how best to implement it asa product. Plus, you already have a working prototype at that point. Except, of course, I only do hobby stuff, not products, and usually drop the designs into public domain (via CC0-1.0).Other members here know a lot more about how to go about commercializing a product, from small batches on Tindie, to large-scale product development with batches in the thousands.

author: NorthGuy
author_rank: Super Contributor
timestamp: February 04, 2023, 04:54:51 pm
content: Quote from: eigenvektor on February 04, 2023, 03:56:48 pmUSB C provides a mechanism with resistors. If the keyboard is connected to the PC via USB, make it a host (DFP in new terminology), if not, make it a device (UFP). The host will provide power to the device. If both are plugged into PC, they both will be hosts (DFP), will not power each other or talk to each other.

author: fchk
author_rank: Frequent Contributor
timestamp: February 04, 2023, 07:29:53 pm
content: Quote from: eigenvektor on February 04, 2023, 01:08:22 pmAbsolutely not!Read the official USB Specs! For example, the "USB Type-C Cable and Connector Specification" Revision 1.1 specifies these electrical requirements for SBU1/2, SSTX, SSRX and B6/B7 pins:Common Mode Voltage: 0 to 1.5VImpedance to GND: < 4MOhm (SBU, SSTX, B6/B7), 25k-4M (SSRX).AC coupling in SSTX and SSRX.This is to protect real full-featured USB ports from damage. PCIe adheres to these limits and is a common choice. DisplayPort uses PCIe drivers and is also a common option.fchk

author: ejeffrey
author_rank: Super Contributor
timestamp: February 04, 2023, 10:07:39 pm
content: Building in a hub is a pretty nice feature *anyway* and definitely a feature I look for when buying keyboards. It's not like I refuse to buy a keyboard without it, or would buy an otherwise bad keyboard for the hub, but it definitely adds value. That's something to consider when you are looking at the cost of the chip.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 04, 2023, 10:17:04 pm
content: Sorry if I missed anything, but can't the two parts just communicate using UART, SPI or whatever and make one of them a USB HID device?This is how all split keyboards are made as far as I know.Why have a USB connection on each? Unless you want the option to use any of the two parts independently (for which i don't really see a use case), this doesn't make sense.

author: eigenvektor
author_rank: Contributor
timestamp: February 04, 2023, 10:46:58 pm
content: ok I'm gonna have 2 usb ports on each keyboard half. The top port will always be UFP.Now I have to decide between two options for the side port:side port is always DFP: you have to connect the top port of one half to the side port of the other halfIf the keyboard is connected to a host (computer), side port will be DFP. If not, side port will be UFP. Means you connect the side usb ports of the keyboard together (or the top of one into the side of the other if you wish as both ports on one half will be UFP)questions:how hard would it be to implement this USB "passthrough" in the mcu? If it's too hard I'd use a usb hub controller ic and that would automatically mean option 1switching between UFP and DFP requires pulling down or pulling up the CC pins. Can I connect them directly to a pin on the MCU (with ESD protection ofc) or should I use some sort of separation like a transistor / optocoupler?Thanks everyone for all the replies so far!

author: eigenvektor
author_rank: Contributor
timestamp: February 04, 2023, 10:55:36 pm
content: @SiliconWizard I need a slim connector between the two halves which leaves mostly usb micro / c (also theoretically lightning).As I might end up selling this product it would be good if it complies with USB standards. Besides as ejeffrey mentioned you could use a half as a hub if needed which is a nice to have.I don't want to use a fixed cable as cables break, and I want it to be user-replaceable. And also yes I do want to be able to use each half independently. Usecase would be gaming: You only have the left half and a mouse on the table. Or If you mount each half to your armrests you don't want a cable going between them, you'd want to connect each half directly to your computer. For normal use and if your computer doesn't have to many ports you want to connect one half to the other to only use 1 port. Or if you want to have something between the halves like a big drawing pad a cable going across would be in the way. Hence why I want to have the ability to choose.

author: NorthGuy
author_rank: Super Contributor
timestamp: February 04, 2023, 11:49:32 pm
content: Quote from: eigenvektor on February 04, 2023, 10:46:58 pmYou should be able to make your USB module to look like a hub and a HID keyboard device connected to it. Then, when the other half is connected, you'll present it to the host as a second HID keyboard device connected to the same hub. Or, you can use a hub chip and connect both keyboards to it.IMHO, it is easier to receive data from the second keyboard, decode them, and send the results to PC along with the data from the main keyboard. This way you only need to implement one HID device. There are some extra benefits to it, like your creature will be compatible with KVM switches.Quote from: eigenvektor on February 04, 2023, 10:46:58 pmThe USB C specification requires resistors of certain value, so you need at least two specific resistors. UFP requires 5.1k pull-down resistors. The DFP pull-up resistors depend on the amount of power which the host can provide (don't remember the exact values). The easiest way is to use two pins. One will enable the pull-up resistor (by driving it high) and the other will enable the pull-down resistor (by driving it low). You'll need two sets of the resistors because USB C can be flipped, but you can control both sets with the same two pins.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 05, 2023, 08:27:44 pm
content: You can either use a small USB hub IC inside each half (or just inside one of them) - in this case, the two halves will appear as two different keyboards from the OS POV, not necessarily a big problem, but something to consider.Or, you can use a MCU with 2 USB OTG controllers - one configured as host and one as device. If you select a MCU supported by TinyUSB, this would be relatively straightforward to implement.

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 05, 2023, 10:59:30 pm
content: JLCPCB hasWCH CH334Uin stock as an extended part for USD $0.60 in singles, but the WCH "datasheet" has no application examples. A web search finds schematics for it, indicating one needs a 12 MHz crystal, and some 100nF and 1uF bypass caps.Using a separate USB hub chip means one could attach their mouse etc. to the USB connector as well, plus of course chain the two keyboards if one wants to.

author: eigenvektor
author_rank: Contributor
timestamp: February 06, 2023, 11:33:34 am
content: Looks interesting, would also mean I can use the smaller CH32V203 in QFN28 package which only supports 1 USB connection.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: February 07, 2023, 01:16:03 am
content: For a one-off I would probably put an USB hub in one or both halves. That way you give each side it's own uC, and they can probably run the same firmware. There is a possible limitation that if you want to combine the shift from the left keyboard with another key from the right side. I'm not sure whether that works with USB HID.Adding a hub in the Keyboard also gives you options for plugging in the mouse, card reader or occasional USB stick, etc.But why do you want to make a split keyboard at all? A popular misnomer in advertisements is that you would have to hold your wrists at "unnatural" angles for a "straight" keyboard, but that is hardly true. If you relax your hands under the table, then put them above the table and look at them, you will likely find that your pinkies are closed more then your index fingers, and that already compensates for most of the discrepancy.I think those split keyboards are mostly like Dvorak and other keyboard inventions. They look promising on paper and intention, but in practice the difference is (almost always) negligible and not worth loosing compatibility with "the rest of the world", and that is probably the reason the alternative solutions never gain much traction. I do recognize that they can be useful for some specialized cases though.

author: newbrain
author_rank: Super Contributor
timestamp: February 07, 2023, 01:51:18 pm
content: Quote from: Doctorandus_P on February 07, 2023, 01:16:03 amIt's more an OS/keyboard driver issue than an USB one.The HID reports from both keyboards will contain the status of the modifiers and (up to six) pressed keys.In Windows and Linux, there's no problem in using, say, SHIFT on a KB and press a letter on another one - I remember this from when I implemented a CEC -> HID adapter, but I just tried again to make sure - one gets the expected result.

author: thm_w
author_rank: Super Contributor
timestamp: February 08, 2023, 01:06:08 am
content: Quote from: Doctorandus_P on February 07, 2023, 01:16:03 amClearly spoken as someone whose never needed or used a split keyboard.Many good ergo style keyboards exist, but inherently they are: fixed tent, tilt/splay, and gap in the middle. The advantage of split is that you can adjust those differences if you desired.https://kinesis-ergo.com/split-keyboards/

author: eigenvektor
author_rank: Contributor
timestamp: February 08, 2023, 09:59:00 pm
content: Quote from: Doctorandus_P on February 07, 2023, 01:16:03 amIf you put your hands relaxed on the table, you will notice that your wrists will be relaxed and your hands will be approx 30cm apart with an angle of about 80 degrees between them. As standard keyboards are smaller width than your shoulders, they force your wrists into an unnatural bend. Having each half separate allows a fully relaxed wrist as well as whatever distance between the hands you feel comfortable with.