[Feature Request] Bluetooth support

[atomgomba]

I'm wondering what is the greatest barrier to implement bluetooth support for Sonix boards. Is it a limitation of current software design, lack of knowledge on hardware at hand or something other. Also I'm curious how can we help to implement bluetooth support for a wider range of keyboards. I created this issue with the intent to start a discussion about this. The best would be if someone could please explain what's missing to make this happen.

[dexter93]

It's mostly that chibios lacks a SPI slave driver. There are attempts at it, albeit hacky. It's WIP

[dexter93]

SPI drivers are almost done. BT driver is also WIP in final state #292

[davecarrijo]

SPI drivers are almost done. BT driver is also WIP in final state #292

News on this?

[HealsCodes]

#292 is only failing it's review because of a missing reformat in two files - if it would go through and be merged into main, what exactly would that imply on terms of BT support?

That PR "only" adds support for ITONBT modules but is there any list out there of BT-modules that the officially supported and community boards (like KeyChron) use?

(missing BT support is the only reason to not get SonixQMK flashed onto my K12 as I use it wired and wireless depending on the machine I work on)

[atomgomba]

This is ridiculous that an important feature is kept back due to some whitespace juggling out of which users would notice nada. If it's that important the maintainer could run autoformat after merge and get done with it. Although now anyone could merge locally and try, I will give it a shot even though not sure what BT hardware does the K7 have.

[davecarrijo]

This is ridiculous that an important feature is kept back due to some whitespace juggling out of which users would notice nada. If it's that important the maintainer could run autoformat after merge and get done with it. Although now anyone could merge locally and try, I will give it a shot even though not sure what BT hardware does the K7 has.

Same as k8 took a look at it, a user just did the work already,
Just import it.

[HealsCodes]

This is ridiculous that an important feature is kept back due to some whitespace juggling out of which users would notice nada. If it's that important the maintainer could run autoformat after merge and get done with it. Although now anyone could merge locally and try, I will give it a shot even though not sure what BT hardware does the K7 have.

Please keep us posted!

[dexter93]

Due to too many people asking, here's a small status update

1. BT driver is verified working in internal testing and public dev beta. Looks good so far. Current preview can be found here, on a bring your own keyboard basis
2. Linting is not the reason for no merge. Waiting on upstream chibios-contrib PR's to get reviewed by maintainers and approved in order to go forward and it adopting it's final form before merging
3. ITON modules have different firmware revisions, with newer keyboards having more features/possibilities for bugs. Still checking those out for any stray bugs/odd behavior.

Overall, release progress is a bit slow because of limited people working on it, but it's coming in the near future

[HealsCodes]

Due to too many people asking, here's a small status update

This might come over as rude but "too many people asking [for the status of the project]"... Really??
I'm sorry we're interested in this and would possibly offer to help.

What do you expect with 20+ branches in various states of abandon and no clear communication.

That the active develop / integration branch for sn32 is apparently not the sn32_develop here but it's twin in your own working fork only adds to the confusion because no-one here - neither us asking about a status, nor people seeing their pull-requests go stale - are able to figure what's going on or what's been worked on.

I completely understand slow progress because of limited people, time or energy to work on things. Running an open-source project in your spare time can be extremely stressful at times. But it feels like you're actively doing everything possible to deter people from helping by giving the impression that while pull-requests are readily available, tested by those that create them and pushed through a CI pipeline, they then lay dormant for so lang that they fail to apply at the point in time they are considered.

Best example is issue #261 - people want to help but get either no reply or one that is so vague that it could as well be "just don't bother".

If there is a process how things are handled - consider writing it down so people can see that PRs aren't dead or code needs to wait for upstream changes etc.

[dexter93]

Due to too many people asking, here's a small status update

This might come over as rude but "too many people asking [for the status of the project]"... Really?? I'm sorry we're interested in this and would possibly offer to help.

What do you expect with 20+ branches in various states of abandon and no clear communication.

That the active develop / integration branch for sn32 is apparently not the sn32_develop here but it's twin in your own working fork only adds to the confusion because no-one here - neither us asking about a status, nor people seeing their pull-requests go stale - are able to figure what's going on or what's been worked on.

I completely understand slow progress because of limited people, time or energy to work on things. Running an open-source project in your spare time can be extremely stressful at times. But it feels like you're actively doing everything possible to deter people from helping by giving the impression that while pull-requests are readily available, tested by those that create them and pushed through a CI pipeline, they then lay dormant for so lang that they fail to apply at the point in time they are considered.

Best example is issue #261 - people want to help but get either no reply or one that is so vague that it could as well be "just don't bother".

If there is a process how things are handled - consider writing it down so people can see that PRs aren't dead or code needs to wait for upstream changes etc.

Apologies for bad communication. The project is alive and well, but has too many fronts open to keep a clear track in github. Status tracking, development and testing is done through the discord server, where anyone is free to join and welcome to do so.

Parts of the project are offloaded to different developers, working on a fluid codebase since we're constantly back and forth with upstream dependencies, such as QMK and Chibios(-Contrib too). Major functionality PR's like the bluetooth support has dependencies in pretty much all of them and is changing rapidly, hence why it's not possible to merge in the main tree, until things have been stabilized ( we tried force pushing and multiple trees in the past, as you said it only results in more confusion). Major parts of the project are constantly being rewritten to comply with upstream requirements and since we're also lacking on maintainers, issues and PR's here might have to stay on the back burner until those are done.

Bluetooth support in particular, is waiting on these before last cleanup and merge

We're a handful of people working on our free time for this. If you feel like helping out, please hop on the SonixQMK discord server. We'd like to see you there

[HealsCodes]

Due to too many people asking, here's a small status update

[long reply above]
We're a handful of people working on our free time for this. If you feel like helping out, please hop on the SonixQMK discord server. We'd like to see you there

Thank you for taking the time to reply and offer some clarity.
I think all of that message (sans the Bluetooth part maybe) would make a great addition to the README for the SonixQMK repo :)

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.
For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know.
// [stale-action-closed]