Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Bayleaf – Building a low-profile wireless split keyboard

graz.io

Post reply on HN
Print view View original

251–259 of 259 posts

Re: Show HN: Bayleaf – Building a low-profile wireless split keyboard

#251

Post by mystified5016 »

jazzabeanie wrote: post #164
w10-1 wrote: post #74

For next iteration, consider integrating trackpads? Moving to the mouse and back is pain enough that people go all-in on keyboard-only interfaces. I velcroed a trackpad to the middle of a Kinesis Advantage. Now I use either hand for the mouse, and even stretch a finger or thumb to the pad without leaving the keys. The movement is little different from using the keyboard. But for split keyboard, you'd need one trackpa…

I want a trackpads integrated into the keys. Under the J key a trackpad with low sensitifity, and under the K key a trackpad with high sensitivity.

Have you ever used a J-key trackpoint? I found an absolutley ancient Compaq laptop from the W3.1 era and I found the J-key mouse shockingly pleasant! Well, as pleasant as trackpoint mice get anyway.

We should bring that back, I think I like it more than the thinkpad style

Re: Show HN: Bayleaf – Building a low-profile wireless split keyboard

#252

Post by ddejohn »

nacs wrote: post #170
ddejohn wrote: post #123

The link when you mention Mikefive's post only goes to the subreddit, not a specific post. Searching for "Mikefive" on reddit yielded a lot of results. I'd love to see the specific post you were referring to. Beautiful keyboard. Sent from my Allium58 Low Profile :D

It's this one https://www.reddit.com/r/ErgoMechKeyboards/comments/1cfg3vr/...

Thank you!

Re: Show HN: Bayleaf – Building a low-profile wireless split keyboard

#253

Post by arcastroe »

robenkleene wrote: post #220
jacobevelyn wrote: post #60

This is the keyboard I’ve been hoping Apple would make for years! I’ve currently got a UHK 60 but would probably switch to this if I could buy it. Especially if it had the standard Apple keyboard layout so my fingers don’t need to relearn things like arrow keys and cmd like when I switch between the UHK and MacBook keyboard.

For folks looking for something similar that you can buy https://hellonuio.com/

woah, ty! I've been using the Dygma Defy [1], but I might switch to this!

[1] https://dygma.com/products/dygma-defy

Re: Show HN: Bayleaf – Building a low-profile wireless split keyboard

#254

Post by zxter »

varispeed wrote: post #250
zxter wrote: post #242

Earlier quoted context omitted.

When you have two halves of a keyboard recognized as separate keyboards by the computer, then just like you said. For example, if you press shift on the left half and u on the right, the computer first sees the shift and then the u. It then types a capital U. But in my case, let's say I don't have any numbers on the keyboard. Instead, I use modifier keys to create a layer for numeric values. So, when I press a modifi…

What I am trying to say is that operating system should collate events from all keyboards, so that wouldn't matter which one had modifier pressed on.

First, for an operating system to process input, it must continuously scan the keyboard matrix to detect keypresses. This adds extra load to both the OS and the CPU. Additionally, every OS must implement the same logic with the same parameters. Since there are many types of keyboards, each OS would need to know every keyboard's matrix layout.

However, before addressing that, like keyboards other HID peripherals are not directly part of the hardware. They connect to computers via USB or Bluetooth, and to do so, keyboards must have an internal chip, "a brain" even just for communication, let alone scanning keyboard matrix. This is similar to how a mouse processes sensor data internally rather than relying on the computer to interpret it. As a result, they can be used on almost any smart device with USB or Bluetooth.

Since we already have this extra chip, "brain", we can add personalized custom logic to simplify our lives and give our hands and wrists a break. This is similar to how gaming mice reduce DPI when the aim button is pressed or how old joysticks had an auto-fire button.

Shh! The computer doesn’t need to know ;)

Re: Show HN: Bayleaf – Building a low-profile wireless split keyboard

#255

Post by varispeed »

zxter wrote: post #254
varispeed wrote: post #250

Earlier quoted context omitted.

What I am trying to say is that operating system should collate events from all keyboards, so that wouldn't matter which one had modifier pressed on.

First, for an operating system to process input, it must continuously scan the keyboard matrix to detect keypresses. This adds extra load to both the OS and the CPU. Additionally, every OS must implement the same logic with the same parameters. Since there are many types of keyboards, each OS would need to know every keyboard's matrix layout. However, before addressing that, like keyboards other HID peripherals are n…

You are overcomplicating this. Keyboards shouldn't have any logic apart from scanning and sending key press and release events to the OS.

I press modifier on keyboard A, keyboard A sends key press event to the OS. I press key on keyboard B, keyboard B sends key press event to the OS. I release key on keyboard B, keyboard B sends key release event to the OS. I release modifier on keyboard A, keyboard A sends key release event to the OS.

From the sequence of events, the OS knows that a key was pressed with the modifier and can act accordingly e.g. emit an event downstream that corresponds to the key that should be generated when pressing a modifier.

Scanning the keyboard matrix is no concern for the OS.

Re: Show HN: Bayleaf – Building a low-profile wireless split keyboard

#257

Post by kirillzubovsky »

kirillzubovsky wrote: post #256

Yes. Shut up and take my money! This is exactly what I've been looking for and couldn't find. Seriously, can I just give you money and take the prototype right now?

p.s. you'll see a million opinions on how to improve it, but this is perfect. don't overcomplicate it. Apple Keyboard, split in half, is literally all there need to be and nothing more. It's perfect!

Re: Show HN: Bayleaf – Building a low-profile wireless split keyboard

#258

Post by TheNightman »

robenkleene wrote: post #220
jacobevelyn wrote: post #60

This is the keyboard I’ve been hoping Apple would make for years! I’ve currently got a UHK 60 but would probably switch to this if I could buy it. Especially if it had the standard Apple keyboard layout so my fingers don’t need to relearn things like arrow keys and cmd like when I switch between the UHK and MacBook keyboard.

For folks looking for something similar that you can buy https://hellonuio.com/

Similar but different https://www.zsa.io/voyager is my weapon of choice.

Re: Show HN: Bayleaf – Building a low-profile wireless split keyboard

#259

Post by zxter »

varispeed wrote: post #255
zxter wrote: post #254

Earlier quoted context omitted.

First, for an operating system to process input, it must continuously scan the keyboard matrix to detect keypresses. This adds extra load to both the OS and the CPU. Additionally, every OS must implement the same logic with the same parameters. Since there are many types of keyboards, each OS would need to know every keyboard's matrix layout. However, before addressing that, like keyboards other HID peripherals are n…

You are overcomplicating this. Keyboards shouldn't have any logic apart from scanning and sending key press and release events to the OS. I press modifier on keyboard A, keyboard A sends key press event to the OS. I press key on keyboard B, keyboard B sends key press event to the OS. I release key on keyboard B, keyboard B sends key release event to the OS. I release modifier on keyboard A, keyboard A sends key relea…

Actually, I’m not overcomplicating things—just overexplaining because you mentioned it might be a stupid question.

Your example is valid, and I acknowledged that it’s correct in my first reply. I also added that, in these types of keyboards, there could be special logic to compensate for missing keys or provide additional features for comfort or ergonomic reasons. This means the keys need to communicate with each other and send the final keystroke afterward.

I also noted that almost all keyboards are not entirely "dumb" and include at least a processing unit to scan the matrix—something you agreed they should have—as well as to handle USB or Bluetooth communication. This processing unit can easily be used for the reasons I mentioned above, without requiring extra hardware or additional software/drivers on the OS side. This approach offers a modular, OS-agnostic way to create a custom solution for comfort or ergonomic needs.

Post reply on HN