Author Topic: Research feedback for a n00b please  (Read 21535 times)

0 Members and 1 Guest are viewing this topic.

Offline vvp

  • Posts: 886
Re: Research feedback for a n00b please
« Reply #50 on: Mon, 04 June 2018, 03:44:07 »
This acceleration model sounds interesting. Gonna have to experiment with it once I have a board to experiment with :)
You can grab the code from here if GPL license is OK for you.
Let us know how you (dis)like it when you try it.

Offline vvp

  • Posts: 886
Re: Research feedback for a n00b please
« Reply #51 on: Mon, 04 June 2018, 04:09:17 »
Could you please give an example of this hardware specificity? I (naively) thought that there's a well-defined standard for communicating via USB (is this the "HID" I saw mentioned?).
If you stay with basic 6KRO (bios compatible protocol) then you probably will not have any issues. If you want something more (NKRO) then you will need a non-common USB report descriptor. In such a case, the support from different OSs may differ ... and of course the pure NKRO will not work in BIOS. Therefore you end with complicated hacks like e.g. multiple keyboards in one composite device etc.

My opinion about this is that 6KRO is good enough. I never needed more than that.
« Last Edit: Mon, 04 June 2018, 04:14:16 by vvp »

Offline mrzealot

  • Thread Starter
  • Posts: 23
  • Location: Szeged, Hungary
  • PhD in Googling stuff...
Re: Research feedback for a n00b please
« Reply #52 on: Mon, 04 June 2018, 14:20:00 »
That's what I did, but it took me a LONG time to understand how QMK works, and understanding how scancodes are sent. Transforming the complete firmware to one that only send scancode is not an easy task.

Also, you probably want to understand most of QMK (or alternatives) before creating your own, because there's plenty of tricks you'll have to implement... For example, debouncing: you can't trust 100% keys, or you'll get duplicates of each key you press. How other have solved the issue, while quite simple, is informative.

Sure, I'm not trying to reinvent the wheel here, just a clean solution where 100% of the firmware is relevant to my usage patterns.
Maybe I haven't phrased my earlier post clear enough (which was already my second attempt, so shame on me :D ), but when I said "a level in QMK where I already have an abstraction for sending keycodes, but where concepts like tap/hold and layer don't yet exist" I also included the input side, not just the output. So optimally, no hardware specific hacking whatsoever, I get virtual (debounced) key up and down events, and I have a clear way of communicating scancodes with the computer. So all I'd change (this is what I mean as "rewrite") is the logic of how keyups and keydowns are interpreted. But that part would be from scratch probably, adding back in only what I really need.


You can grab the code from here if GPL license is OK for you.
Let us know how you (dis)like it when you try it.

Thanks, I'll take a look (which is futile until I have something to use it with, but I'll probably take a look anyway...)


If you stay with basic 6KRO (bios compatible protocol) then you probably will not have any issues. If you want something more (NKRO) then you will need a non-common USB report descriptor. In such a case, the support from different OSs may differ ... and of course the pure NKRO will not work in BIOS. Therefore you end with complicated hacks like e.g. multiple keyboards in one composite device etc.

My opinion about this is that 6KRO is good enough. I never needed more than that.

My understanding is that 6KRO is 6 "normal" keys plus any combination of modifiers (and even the layer shifters or any other hardware specific Fn keys don't count because they can be handled in the firmware). If so, then 6KRO is definitely enough. This is another point, then, where the firmware could be streamlined, e.g., stripping NKRO support for more layer configurability.

Offline algernon

  • Posts: 311
  • A tiny mouse, a hacker.
    • Diaries of a Madman
Re: Research feedback for a n00b please
« Reply #53 on: Mon, 04 June 2018, 14:26:02 »
Could you please give an example of this hardware specificity? I (naively) thought that there's a well-defined standard for communicating via USB (is this the "HID" I saw mentioned?).
If you stay with basic 6KRO (bios compatible protocol) then you probably will not have any issues.

Oh, but you probably will, if you naively follow the spec! You see, if you create a compact descriptor, that does only what you need, the keyboard will not work in many BIOSes, nor under OSX's FileVault. You need to have the *exact same* descriptor and report layout as the example in appendix... b, I think? Because many BIOSes do not parse the descriptors, and just assume they're all the same. So if you try to be clever, and save a few bytes here and there - you shoot yourself in the foot.

If you want your keyboard to be able to wake the host up, you'll have to go *against* the spec, and default to boot protocol (while section 7.2.6 says report should be the default, even for boot devices), otherwise none of the three major OSes will let the keyboard wake the host by default.

But yeah, if you only want 6KRO, the gotchas are far fewer. If you want NKRO as well, that's a whole new can of worms.

A few other things you can run into issues with, if implemented naively are layers (it is very easy to make them terribly slow and O(n); or make it too easy to get stuck; or produce weird, unexpected results), in-keymap modifiers, like QMK's LSHIFT() and similar - just to name a few things. But if you start with QMK as a base, that's reasonable, you avoided many of the pitfalls already then.

Offline vvp

  • Posts: 886
Re: Research feedback for a n00b please
« Reply #54 on: Mon, 04 June 2018, 15:08:13 »
My understanding is that 6KRO is 6 "normal" keys plus any combination of modifiers (and even the layer shifters or any other hardware specific Fn keys don't count because they can be handled in the firmware).
Yes.

Offline vvp

  • Posts: 886
Re: Research feedback for a n00b please
« Reply #55 on: Mon, 04 June 2018, 15:13:15 »
Oh, but you probably will, if you naively follow the spec! You see, if you create a compact descriptor, that does only what you need, the keyboard will not work in many BIOSes, nor under OSX's FileVault. You need to have the *exact same* descriptor and report layout as the example in appendix... b, I think? Because many BIOSes do not parse the descriptors, and just assume they're all the same.
That is what I meant by bios compatible. BIOS do not need to parse the descriptor so the layout must be the same.

If you want your keyboard to be able to wake the host up, you'll have to go *against* the spec, and default to boot protocol (while section 7.2.6 says report should be the default, even for boot devices), otherwise none of the three major OSes will let the keyboard wake the host by default.
Interesting. I never even tried to wake up my computer from my keyboard. It probably does not work :)

Offline mrzealot

  • Thread Starter
  • Posts: 23
  • Location: Szeged, Hungary
  • PhD in Googling stuff...
Re: Research feedback for a n00b please
« Reply #56 on: Mon, 04 June 2018, 16:21:31 »
Ok, so we seem to have tacled the issues raised so far, even including a few sharp-ish turns regarding the topic (thanks again for all the great input). But this being a general "research" thread, I don't think I'm out of line if I twist it even further.
So with that: what do you guys think about variable force / variable weight boards? Trying to search for this mostly yields the Realforce Topre boards but I'd like to stay in MX-compatible territory. Is this practoce common? If not, why not? (seems like a perfectly good idea)

What I'm thinking off the top is MX Browns for the pinkies and the ring fingers, MX Clears for the middle and index fingers, and Tactile Greys for the thumb cluster. How does this sound? Should the middle/index fingers (or the rings/pinkies) also be separated? Are the weights approximately correct? Should I dig even deeper with custom weight springs / lubing / etc, or are factory switches good? Oh, and for "factory", is Cherry the factory, or is looking into other manufacturers worth it?

That seems a complex enough question to keep the conversation juices flowing  ;D

Offline Koren

  • Posts: 133
  • Location: France
Re: Research feedback for a n00b please
« Reply #57 on: Tue, 05 June 2018, 04:10:17 »
So with that: what do you guys think about variable force / variable weight boards?
For main keys, I thought about it, and threw the idea away.

Basically because there's two possibilities:

- stock switches, and thus strong difference (Brown vs Clears for example), which will be annoying when typing: I don't think strictly enforcing the "1 key = 1 finger" is wrong. If I have to type "TRE" on a QWERTY board, since forefinger will press T, I'll use middle finger for R and ring finger for E. Having a strong difference between keys pressed by the same finger doesn't sound appealing to me.

- custom springs in switches with more "linear" variation: now that's a more appealing solution, but honestly, I'm not sure it worth the hassle of opening the switches and sourcing different kind of springs. Besides, it's a mod you can do afterwards if you're not satisfied with homogeneous weight.


On the other hand, I can understand different switches for thumbs (even possibly different switches depending on key type, I wonder if I won't place linear switches on modifiers when the other switches are tactile/clicky... still not decided on this).


At the end of the day, it's a personnal choice...

Oh, and for "factory", is Cherry the factory, or is looking into other manufacturers worth it?
Other manufacturers definitively worth it (my next board will not be Cherry, currently leaning towards Kailh switches, I'm sourcing them to make my choice). But you'll find plently of threads discussing options around here.