search

qmk / qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families
https://qmk.fm
GNU General Public License v2.0
18.23k stars 39.29k forks source link

Massdrop / arm_atsam removal discussion #14082

Closed tzarc closed 2 years ago

tzarc commented 3 years ago

Follow-on from #10904, #14081, #9327.

It's likely we're going to be removing Massdrop-related boards and board support from QMK in the near future, due to licensing concerns.

This issue is used to track discussion on future direction on what to do with their support. Options include:

Please limit discussion to constructive comments -- complaints about your favourite Massdrop board losing QMK support will be deemed off-topic as it doesn't help progress the situation.

tzarc commented 3 years ago

And for the record, I'm affected by this too -- I have my own boards that will no longer be buildable with master if/when we remove them.

acarroz commented 3 years ago

Will the code remain in develop?

drashna commented 3 years ago

Will the code remain in develop?

If it's removed at all, it wouldn't remain in develop. It would likely be removed in develop first, and then be removed as part of the breaking changes cycle.

Ideally, we push hard for RIOT-OS, as that supports the ATSAM chips, and nordic BT capable chips. And wouldn't be heavily tied to specific hardware (the current atsam stuff is tailor made for the massdrop boards, so support anything else would be ... nightmarish, at best).

xsrvmy commented 3 years ago

Which boards does this affect? Specifically does it affect plancks and preonics bought from DROP?

fauxpark commented 3 years ago

Nope, just the ALT and CTRL.

fonix232 commented 3 years ago

Pardon my ignorance, I haven't been following things recently. What is the main show-stopper currently? I want to presume that it's the usual Massdrop feet-dragging when it comes to anything that resembles post-sales support, but I feel it's better to ask.

Given the level of support Drop has provided for their products in the past, I'm not surprised that their 2018-2019 claims of working closely with QMK to provide mainline support didn't get too far. Great promises, never delivered (fully).

I'll try to rephrase my above question to be more precise:

@tzarc again I'm not trying to complain or anything. I understand that you're asking for help, and at this point I just want to clarify what kind of help it should be - are you asking for someone to step up and make the support happen, or is it more of a courtesy call to the community to see which direction things should go?

Parham-S commented 3 years ago 
* Same question goes for the RIOT-OS option. Are there any technical/legal reasons this is not considered to be the way to go, or does it just boil down to no resources (i.e. man-hours, someone picking up the topic and working on it)

@tzarc again I'm not trying to complain or anything. I understand that you're asking for help, and at this point I just want to clarify what kind of help it should be - are you asking for someone to step up and make the support happen, or is it more of a courtesy call to the community to see which direction things should go?

I mean Apple's encrypted AirPlay source code was "borrowed" and reversed engineered and you can still throw it onto any device. It's actually sitting on GitHub today lol, so I cant imagine the difficulty of a CLI keyboard configuration is behind the change. Probably just a business conflict. They've flat out ignored any issues raised on this front for a good while now.

skullydazed commented 3 years ago

What is the main show-stopper currently?

Like most things it's a matter of time. QMK maintainers have a limited amount of time, and we'd rather use that to help QMK move forward if we can. Being honest here, this is not something we want to do and pushing this issue forward takes away from other work, so we aren't eager to take the next steps.

There are also some developments that aren't mine to share that have happened this week which may help to unstick this issue. I hope you'll hear more about that soon.

What's stopping anyone from "picking up the mantle" and providing third party support for the CTRL and ALT?

A couple people have attempted to do that, but they did not understand how big the project they were taking on was. The size of the project is the main impediment. This is also true for RIOT-OS.

fonix232 commented 3 years ago

Like most things it's a matter of time. QMK maintainers have a limited amount of time, and we'd rather use that to help QMK move forward if we can. Being honest here, this is not something we want to do and pushing this issue forward takes away from other work, so we aren't eager to take the next steps.

I kind of understand the sentiment, but it also worries me - I bought my Drop CTRL on the promise that Drop would support this keyboard in upstream QMK, meaning even if they drop support (which happened way quicker than expected, and resulted in my decision to never support this PoS company in the future... Also, pun intended), there would be updates to some extent.

QMK dropping support for the CTRL and ALT is a big hit for me, especially with a bunch of features still missing (proper EEPROM storage for settings comes to mind), knowing that future improvements won't come to this board.

There are also some developments that aren't mine to share that have happened this week which may help to unstick this issue. I hope you'll hear more about that soon.

Fingers crossed! This does sound good, even without knowing the details.

A couple people have attempted to do that, but they did not understand how big the project they were taking on was. The size of the project is the main impediment. This is also true for RIOT-OS.

I am also at this point. I've had some limited experience with microcontrollers (mostly ESP8266/ESP32, though), and if I'm not mistaken, support would boil down to four layers:

I'd love to offer some help, however unfortunately my C/C++ knowledge is quite limited, and I'm nowhere near proficient enough to be even in a supporting role for such an undertaking, nor do I have the appropriate tools for debugging SAMD platforms.

Hopefully that soon-coming announcement will make this monologue above obsolete and unnecessary, though.

NittanyLion commented 2 years ago

fwiw: I asked Massdrop about future QMK support and got the message below. Not reassuring.

Hi ther,e

This is xxxx from Drop Community Support. I understand the concern, and would be happy to help clear things up.

At this time QMK is functional and working https://docs.qmk.fm/#/newbs_getting_started. At this time, we do not have any further information as to when, or if they will be dropped by us soon. I do apologize for any inconvenience this may cause, and hope you can understand.

If you have any further questions or concerns, I would be happy to help. Have a great day!

dzchoi commented 2 years ago
  • Drivers for the peripherals on the boards (ISSI LED driver, USB controller) - these do not seem to exist, and would be the bulk of the work

I agree. IMHO, RIOT does not have drivers for IS31FL3733, USB 2422 HUB and Shift Register (SR) 595, but RIOT does support i2c, spi, adc, usbus, usbus_hid and cdc_acm (i.e serial communication over usb). Implementing the missing drivers for those devices would not be so difficult, I think. Each of them could be implemented by a single file (around several hundred lines?). But, the real problem is how we can combine (or choose one of) those background protocols between QMK and RIOT.

For example, QMK has its own is31fl3733.[ch], which uses QMK's own i2c module, i2c_master.c. RIOT has its own i2c module, periph_i2c. I think, here comes the problem. Are we going to use i2c from QMK or from RIOT? Then, how about using DMA, which is already implemented in the Massdrop code? (As far as I know, neither QMK nor RIOT supports i2c DMA yet. Of course, DMA is not a big deal and does not increase transfer speed, but when it comes to RTOS it will be able to give more CPU time to other threads.)

  • Converting the current QMK definitions of the board to the RIOT-OS based ones - this is the final touch, and should also be straightforward

IMHO again, there is something to consider here. QMK wants to build using its own make system (build_keyboard.mk) and RIOT also has its own make system (Makefile.base and Makefile.include). Both of them want to be a main build system and do not provide an (easy) way to build as a subordinate module. It will not be impossible to combine the two build systems but I am wondering if there would be an efficient and optimal way.

That being said, it's really a shame to see the end of QMK support for such a powerful(?) MCU. (Though its PCB and the firmware code are not the best definitely, there are not many keyboards that I can integrate interactive environments such as Lua, uLisp, or FORTH on top of the firmware and RTOS, I think.)

tzarc commented 2 years ago

Not sure why you expect to be accessing RIOT internals directly -- the QMK abstractions like i2c_master.c are in place for a reason; LED drivers or anything else leveraging I2C can be written without knowledge of the internals.

If/when there's a RIOT port, you should expect to still target i2c_master.

That being said, it's really a shame to see the end of QMK support for such a powerful(?) MCU. (Though its PCB and the firmware code are not the best definitely, there are not many keyboards that I can integrate interactive environments such as Lua, uLisp, or FORTH on top of the firmware and RTOS, I think.)

It never really did, in a general sense. This was the crux of the issue with arm_atsam and Massdrop.

It was not fit for purpose.

mewa commented 2 years ago

Pardon me if I'm wrong, but the libraries marked in the original issue are provided as system libraries for Atmel ARM microcontrollers, by the manufacturer. There isn't really a way to use them outside of the platforms they were intended for (which makes sense, given they are system libraries specific to them). To my best knowledge, they could be included under the "system library" exception.

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

At this point, I'm wondering whether it's a move targeted at Massdrop for abandoning their boards or an actual licensing concern.

skullydazed commented 2 years ago

At this point, I'm wondering whether it's a move targeted at Massdrop for abandoning their boards or an actual licensing concern.

This is not the first time we've removed code for having similar language- we recently removed ugfx for example. The main difference between how we handled ugfx and how we're handling massdrop is one of engagement from people willing to do the work.

To more directly answer your question about the license concern, we have long recognized that it's a grey area. From a practical standpoint there is usually little reason to use those files on other CPU's anyway. From a GPL standpoint, it clearly violates the spirit if not the letter of the GPL. And that's where our grey area starts.

If it only violates the spirit but not the letter of the law it'd be legally permissible, but the important part here is that no one can say whether it violates the law without taking it to court, and we (QMK) do not want to be that test case.

That is why we are trying to play it safe here, and if we had caught this originally would not have merged the atsam support at all.

vMarcelino commented 2 years ago

Does this removal means that I'll no longer be able to build, ever, or that I'll no longer be able to build from master only? I mean, once it is removed, we will still be able to build with an older commit, right?

tzarc commented 2 years ago

Correct.

fonix232 commented 2 years ago

@skullydazed couldn't the licensing issue be solved by contacting the license holder - in this case, I'd presume it would be Microchip.com - and verifying it with them?

To begin with, it would be them who would file a lawsuit over the licensing, however by the licenses I see here (seems to be mostly Apache?), the intent of the code owner was clearly to make it open source. Requesting an alternative licensing that is compatible with GPLv2 without legal worries would be something I think they would be willing to do.

tzarc commented 2 years ago

Given that #15464 is in the pipeline this discussion is likely going to be rendered irrelevant in due course. Closing.

fonix232 commented 2 years ago

@tzarc just to confirm, and to dismiss any possible confusion, this rebase onto RIOT-OS means continued support for the Drop boards, right?

tzarc commented 2 years ago

Yes.