QMK Rotary encoder support

Learning and discussion Firmware, programming, and hardware compatability
#1

LAST TIME, ON KEEB TALK Z:

Why does a firmware have an API?

Is it actually easy or overcomplicated? Should it be simple or is this just feature creep?

How much do you want to bet GPCGR forked QMK without understanding the license requires them to open source their code? Will their rotary encoder even work? It’s 2AM and I don’t want to derail my own thread that I started to stop derailing my other thread sooooo…

Okay seriously why does a firmware have an API and why is adding an API endpoint so critical to adding GUI support when the GUI is literally just compiling C code?

2 Likes
Glorious GMMK Pro
#2

Every library or framework has an API — well, technically it’s not an “application” programming interface, but library/framework programming interface, but nobody says LPI or FPI. It’s the functions you are supposed to call or variables you are supposed to set in order to use it — as opposed to the internal implementation details you are not supposed to touch in your configuration.

The GUI is not “just compiling code”. It’s generating the part of the code that calls those functions and sets those variables first. So in order for the GUI to be able to do this, there first need to be functions to call and variables to set.

5 Likes
#3

:popcorn: I’m definitely wondering about this one myself

1 Like
#4

Not a lawyer, but I have stayed in a Holiday Inn Express before…

QMK isn’t exclusively under GPLv2 - there are parts under other licenses which are more permissive, especially in binary form vs source form (MIT/BSD). Typically what I’ve seen is if you make modifications to the GPL’d code, those modifications need to be made available, however, theoretically the encoder could be classified in some other form in terms of library vs core code - thus, under another license not required to be disclosed under GPL.

1 Like
#5

You only need to publish your modifications to any GPL code if you distribute that code or binaries made from it. You are perfectly fine experimenting with GPL code for your own use.

#6

Yes - correct - but I’m saying, depending on how/if Glorious is supporting their encoder while also using QMK - they may not need to modify QMK in a way that requires they also release their own code - though, I may be mixing in LGPL - but interpretations of derived works are still lacking concrete examples (as far as I can recall from recent history)

#7

Indeed, but it would be very hard to claim any kind of “plugin” exception for part of a ROM image within a microcontroller. If they’re supplying a ROM image in a microcontroller and it contains any GPLed code at all then the end user needs to have access to enough source to rebuild the ROM image and make changes to it. LGPL allows for proprietary parts to be supplied as object code rather than source - but if there’s any GPLed code at all in a project that compiles into a single binary then the GPL would take precedence and require that complete source be made available.

Parts of the code being more permissive generally only means that there are fewer restrictions if you want to take just that code and use it in an unrelated project.

#8

I’m sure you’re right - I’m probably thinking too much on the LGPL side of things, of what they COULD do in this scenario.

It’ll be interesting to see how this plays out - given the fairly high quantity of license conscious customers in the keyboard community.

#9

indeed - to be fair the chances of such a GPL violation (if indeed, one exists) resulting in an actual court case are probably pretty slim - but as a relative newcomer to the keeb scene I realised very quickly that reputation is everything in this game.