SK6812 mini-e RGB support #90
Conversation
tiadobatima
commented
Jun 16, 2021
tiadobatima
commented
- Rerouting all switches RGBs.
- Changed all the underglow and layer indicator RBGs to mini-e as well
…et in order to avoid doing a schematic revision. and removed local traces
|
[x] Footprint reviewed to datasheet There are a few traces that I would clean up aesthetically, but they're not an issue. Overall, I'd happily get a prototypes set made (it's been through a lot more review than my 1.0 set), but understand that there's always a chance that we missed something. Todo : |
Other changes:
Thanks!!! |
|
Looks good, that's all the necessary changes from me
|
|
Fixed the extra vcc silk on the LED header |
|
It looks cool to me. Thanks for the contribution! I haven't reviewed the board in detail though, I thinks 2 pairs of eyes are enough. From my side I am ok with merging this into master. But I would leave the final word with @DaneEvans since it's the RGB version.
This is indeed the better approach. People are impatient and tend to start building or even selling the designI too soon. But as I said above, I am leaving this decision to you. |
|
My concern is the LED footprints, as far as I know I was the only one to look at them (even if it was 4 months apart). If it was just the routing I'd say merge it. Maybe there's a compromise where we merge in the PCB files, but not the generated Gerber's. That way it should only be people that know what they are doing that get one built. |
|
@tiadobatima are you planning on getting boards made in the near future? |
|
I wasn't planning to print them for myself yet, since I got the original mini working, but I could. So far, I just assumed the dimensions are correct (didn't you take component from Corne, or something, Dane?). Tonight I can give an extra pair of eyes on the footprints too before we merge with or without the Gerbers. |
|
Hello @DaneEvans @josefadamcik... I looked into the footprints in the last couple of days and I placed a real mini-e that I have around on a current mini PCB to have an idea of the tolerances, and I think we have room to make the edge cut hole for the It's not a big deal to keep the current mini-e footprint as is. It looks like it'll work just fine, but I think making the hole smaller would give less wiggle room for the LED to move when soldering it, which was one of the main sources of expletives uttered in this house in the last while. I think it would just make people's lives a bit easier. The downside is that making the hole smaller would probably make the board a bit less flexible and there will be less room for errors. These are the measurements: Mini
Mini-e
What do you think? |
To be honest, I am not experienced enough with PCB manufacturing to be able to know how the tolerances are and what is safe and what is not (0.1mm might be still huge gap or already too small). I would personally check mini-e footprints for other boards or in KiCad library and size of the opening there to have some other input. My gut feeling is it should be ok but it would require a test build. |
|
That one was stolen from the new crkbd I think.
I wouldn't trust 0.1 mm, you know that people are going to go with the
cheapest PCB house they can, and more room in the cuts means that the LED
can be centred on the pads.
The mini E tabs should stop them falling through anyway.
The cuts are also unlikely to have square corners.
Some room probably exists to bring it down, but I wouldn't go to far.
…On Thu, 24 Jun 2021, 5:37 pm Josef Adamčík, ***@***.***> wrote:
@tiadobatima <https://github.com/tiadobatima>
-
Size: 3.20mm x 2.80mm
-
Current edge cut: 3.60mm x 3.10mm
-
Proposed edge cut: *3.30mm x 2.90mm*. Or maybe a bit bigger.
To be honest, I am not experienced enough with PCB manufacturing to be
able to know how the tolerances are and what is safe and what is not (0.1mm
might be still huge gap or already too small). I would personally check
mini-e footprints for other boards or in KiCad library and size of the
opening there to have some other input.
My gut feeling is it should be ok but it would require a test build.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#90 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFIRN4JYJI4QWYEKD5JWFVTTULOBZANCNFSM46YQX5ZQ>
.
|
|
Ooops... I missed your replies. I was thinking of ordering the boards to test them, but I'm gonna be moving next month, so I won't have time to work on them anytime soon. I'm very sorry. I'll be happy to make any small touchups/fixes to the traces if needed be, though. |
|
There're some low cost manufacturers which CNC at 0.2mm tolerance. |
|
So, a safe dimension should be 3.60mm x 3.20mm. |
|
We should design to the majority of manufactures, not just the ones that
can handle low tolerances.
There is no value in making them smaller, and a lot more risk. In
mechanical fit, and the added stress that will shift to the pads if the
case hits the edge when the board flexes.
In the end it's always your call, but I don't see any reason to move from
a verified design, when we can't even find someone to guinea pig it in it's
current form.
…On Thu, 1 Jul 2021, 8:46 pm fi0, ***@***.***> wrote:
So, a safe dimension should be 3.60mm x 3.20mm.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#90 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFIRN4OX77UQMNGUEZNLS7DTVRBRPANCNFSM46YQX5ZQ>
.
|
|
I suggest we should make the cutout slightly larger than the current one, so a majority of manufacturers can be used. Apart from that, the Kailh sockets NPTH doesn't have enough tolerance. The recommended PCB layout is 3mm in diameter (for +/-0.05mm tolerance). It's common to see +/-0.075mm or +/-0.08mm. And one manufacturer even states +/-0.2mm. So the size of NPTH holes should be increased as well. |
|
In case it helps, I've assembled a board with SK6812 MINI-E here: #40. I didn't have any trouble soldering with the cutout size used. |
|
@tiadobatima Are the underglows mounted on the front side or the back side? If they are on the front side, they could interfere with the key switches. |
|
Underglow is the most ambiguous term we could possibly use here, I'm
assuming you mean the drop lighting?
A cursory glance at his pcb design suggests that it follows exactly the
same layout as the regular RGB, and this is no issue.
…On Sat, Aug 28, 2021 at 10:02 AM Leo Lou ***@***.***> wrote:
@tiadobatima <https://github.com/tiadobatima> Are the underglows mounted
on the front side or the back side? If they are on the front side, they
could interfere with the key switches.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#90 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFIRN4PSFZXCQ4VHEUWJQ73T7ARQLANCNFSM46YQX5ZQ>
.
|
|
@DaneEvans yes, specifically the droplight D36. When the key switches is inserted from the Front side, both the droplight and per key lighting for RGB 2.1 are mounted on the Back side. |
|
Hi @l4u ... |
|
Apologies, you're right. I looked at the wrong pcb file! Given that the mini-e's have 0.8 mm behind the LED, you're right and the downward pointing LED's will not work if they are close to a switch, A few of them do look to be too close, and should be redone to point out from the board, or moved to be away from the switches. |
|
I think they are meant to be facing down.. Is it currently in a state to merge? Or is the LED orientation still outstanding? |
yea, you are right, I noticed after re-reading the build guide 😶🌫️
It is outstanding. I did flip the LEDs (with the Hotkey 'F'), but not until later I noticed that this does not actually flip/mirror the pads successfully. Maybe something to do with the footprint being itself double-sided? After having soldered both types, I am really glad this fork exists 😄 |
|
I might have a look. I'm currently unemployed, so I should have the time to
close it out.
We know the per key ones work, so I can just match the footprints to those,
and then check the routing.
…On Tue, 7 Dec 2021, 7:29 am Pascal, ***@***.***> wrote:
I think they are meant to be facing down..
yea, you are right, I noticed after re-reading the build guide 😶🌫️
Is it currently in a state to merge? Or is the LED orientation still
outstanding?
It is outstanding. I did flip the LEDs (with the Hotkey 'F'), but not
until later I noticed that this does not actually flip/mirror the pads
successfully. Maybe something to do with the footprint being itself
double-sided?
If it is easy for you, I suggest you do it. If it isn't, maybe I can find
some time in a few weeks.
After having soldered both types, I am really glad this fork exists 😄
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#90 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFIRN4OO2CABRRZG2USNRI3UPUMKXANCNFSM46YQX5ZQ>
.
|
|
I just got my PCBs :-) Almost ready to assemble, hopefully today, but I don't quite understand how I should solder the SK6812 mini-e LEDs since the pads may be flipped (?). Moreover the first LED doesn't have the same orientation as in the doc so I don't know what each pad is regardless of whether they have changed. LED1 in the doc vs actual board: Can I assume that the labels on SofleKeyboard_mini-E.kicad_pcb are correct and go with the position of VCC and GND there vs the actual LEDs? Thus LED1 as follow: LED2 and 14 as follow: I guess every LED is an underglow LED then. Or maybe some of the LEDs are supposed to be mounted on the back now. The discussion seems to suggest that may be the case but I don't know what has actually been implemented in https://github.com/tiadobatima/SofleKeyboard/tree/bee9c79297ce17ca828e070779d2bf0416e14e16 and I can't read that from the PCB file. I will wait on someone's feedback before I start soldering. edit: I soldered the MCU and flashed with edit2: I got RGB1 and RGB2 to light up on the right side after connecting all 3 jumpers (but I couldn't get the first per key underlight to light up). However I couldn't get RGB1 to light up on the left half.
|
|
I got it working. It seems fine as it is but needs to be documented before merging imo.
Right side: Left side: edit: I finished soldering the LEDs. LED36 doesn't work on either side (even after replacing it on the 1st). Maybe/hopefully it's a software issue.
|
This is indeed a software issue. When using all LEDs, the map is not correct anymore. Attached patch works for me. diff --git a/keyboards/sofle/keymaps/rgb_default/config.h b/keyboards/sofle/keymaps/rgb_default/config.h
index c34da8382b..edecca70e0 100644
--- a/keyboards/sofle/keymaps/rgb_default/config.h
+++ b/keyboards/sofle/keymaps/rgb_default/config.h
@@ -49,8 +49,7 @@
#ifdef RGB_MATRIX_ENABLE
-#define RGBLED_NUM 35 // Number of LEDs
-#define RGBLED_NUM 35 // Number of LEDs
+#define RGBLED_NUM 37 // Number of LEDs, see keymap.c for matching value
#define DRIVER_LED_TOTAL RGBLED_NUM
#endif
@@ -71,7 +70,7 @@
#define RGBLED_NUM 70
//#define RGBLED_SPLIT
- #define RGBLED_SPLIT { 35, 35 } // haven't figured out how to use this yet
+ #define RGBLED_SPLIT { 37, 37 } // haven't figured out how to use this yet
//#define RGBLED_NUM 30
#define RGBLIGHT_LIMIT_VAL 120
diff --git a/keyboards/sofle/keymaps/rgb_default/keymap.c b/keyboards/sofle/keymaps/rgb_default/keymap.c
index 30f374f296..d1964d3305 100644
--- a/keyboards/sofle/keymaps/rgb_default/keymap.c
+++ b/keyboards/sofle/keymaps/rgb_default/keymap.c
@@ -24,43 +24,57 @@
#define HSV_OVERRIDE_HELP(h, s, v, Override) h, s , Override
#define HSV_OVERRIDE(hsv, Override) HSV_OVERRIDE_HELP(hsv,Override)
+#define NUM_INDICATORS 1
+#define NUM_UNDERGLOW 6
+#define START_BACKLIGHT (NUM_INDICATORS + NUM_UNDERGLOW)
+#define START_OUTER_FN_KEYS (START_BACKLIGHT + 1) // +1!
+#define NUM_OUTER_FN_KEYS 4
+#define START_INNER_KEYS (START_BACKLIGHT)
+#define START_THUMB (START_BACKLIGHT + 19) // why 19? Tja
+#define NUM_BACKLIGHT 29
+#define LEFTRIGHT_SPLIT (NUM_INDICATORS + NUM_UNDERGLOW + NUM_BACKLIGHT)
// Light combinations
#define SET_INDICATORS(hsv) \
- {0, 1, HSV_OVERRIDE_HELP(hsv, INDICATOR_BRIGHTNESS)}, \
- {35+0, 1, hsv}
+ {0, NUM_INDICATORS, HSV_OVERRIDE_HELP(hsv, INDICATOR_BRIGHTNESS)}, \
+ {LEFTRIGHT_SPLIT+0, NUM_INDICATORS, hsv}
#define SET_UNDERGLOW(hsv) \
- {1, 6, hsv}, \
- {35+1, 6,hsv}
+ {NUM_INDICATORS, NUM_UNDERGLOW, hsv}, \
+ {LEFTRIGHT_SPLIT+NUM_INDICATORS, NUM_UNDERGLOW, hsv}
#define SET_NUMPAD(hsv) \
- {35+15, 5, hsv},\
- {35+22, 3, hsv},\
- {35+27, 3, hsv}
+ {LEFTRIGHT_SPLIT+15, 5, hsv},\
+ {LEFTRIGHT_SPLIT+22, 3, hsv},\
+ {LEFTRIGHT_SPLIT+27, 3, hsv}
#define SET_NUMROW(hsv) \
{10, 2, hsv}, \
{20, 2, hsv}, \
{30, 2, hsv}, \
- {35+ 10, 2, hsv}, \
- {35+ 20, 2, hsv}, \
- {35+ 30, 2, hsv}
+ {LEFTRIGHT_SPLIT+ 10, 2, hsv}, \
+ {LEFTRIGHT_SPLIT+ 20, 2, hsv}, \
+ {LEFTRIGHT_SPLIT+ 30, 2, hsv}
#define SET_INNER_COL(hsv) \
{33, 4, hsv}, \
- {35+ 33, 4, hsv}
+ {LEFTRIGHT_SPLIT+ 33, NUM_OUTER_FN_KEYS, hsv}
#define SET_OUTER_COL(hsv) \
- {7, 4, hsv}, \
- {35+ 7, 4, hsv}
+ {START_OUTER_FN_KEYS, NUM_OUTER_FN_KEYS, hsv}, \
+ {LEFTRIGHT_SPLIT + START_OUTER_FN_KEYS, NUM_OUTER_FN_KEYS, hsv}
+
#define SET_THUMB_CLUSTER(hsv) \
- {25, 2, hsv}, \
- {35+ 25, 2, hsv}
+ {START_THUMB, 2, hsv}, \
+ {LEFTRIGHT_SPLIT+ START_THUMB, 2, hsv}
+
#define SET_LAYER_ID(hsv) \
- {0, 1, HSV_OVERRIDE_HELP(hsv, INDICATOR_BRIGHTNESS)}, \
- {35+0, 1, HSV_OVERRIDE_HELP(hsv, INDICATOR_BRIGHTNESS)}, \
- {1, 6, hsv}, \
- {35+1, 6, hsv}, \
- {7, 4, hsv}, \
- {35+ 7, 4, hsv}, \
- {25, 2, hsv}, \
- {35+ 25, 2, hsv}
+ {0, NUM_INDICATORS, HSV_OVERRIDE_HELP(hsv, INDICATOR_BRIGHTNESS)}, \
+ {LEFTRIGHT_SPLIT+0, NUM_INDICATORS, HSV_OVERRIDE_HELP(hsv, INDICATOR_BRIGHTNESS)}, \
+ {NUM_INDICATORS, NUM_UNDERGLOW, hsv}, \
+ {LEFTRIGHT_SPLIT+NUM_INDICATORS, NUM_UNDERGLOW, hsv}, \
+ {START_OUTER_FN_KEYS, NUM_OUTER_FN_KEYS, hsv}, \
+ {LEFTRIGHT_SPLIT + START_OUTER_FN_KEYS, NUM_OUTER_FN_KEYS, hsv}, \
+ {START_THUMB, 2, hsv}, \
+ {LEFTRIGHT_SPLIT+ START_THUMB, 2, hsv}
enum sofle_layers {
@@ -350,10 +364,7 @@ const rgblight_segment_t PROGMEM layer_numpad_lights[] = RGBLIGHT_LAYER_SEGMENTS
SET_INDICATORS(HSV_ORANGE),
SET_UNDERGLOW(HSV_ORANGE),
SET_NUMPAD(HSV_BLUE),
- {7, 4, HSV_ORANGE},
- {25, 2, HSV_ORANGE},
- {35+6, 4, HSV_ORANGE},
- {35+25, 2, HSV_ORANGE}
+ SET_THUMB_CLUSTER(HSV_ORANGE)
);
// _SWITCHER // light up top row
const rgblight_segment_t PROGMEM layer_switcher_lights[] = RGBLIGHT_LAYER_SEGMENTS(
@@ -408,8 +419,6 @@ static void render_logo(void) {
static void print_status_narrow(void) {
// Print current mode
oled_write_P(PSTR("\n\n"), false);
- oled_write_ln_P(PSTR("Dane\nEvans"), false);
-
oled_write_ln_P(PSTR(""), false);
//snprintf(layer_state_str, sizeof(layer_state_str), "Layer: Undef-%ld", layer_state)
diff --git a/keyboards/sofle/rev1/rev1.c b/keyboards/sofle/rev1/rev1.c
index 88a28e6a40..f24e02c179 100644
--- a/keyboards/sofle/rev1/rev1.c
+++ b/keyboards/sofle/rev1/rev1.c
@@ -18,6 +18,7 @@
#ifdef RGB_MATRIX_ENABLE
// Physical Layout
+ // Note, that if STATUS_LED is enabled, all of this is +1!
// Columns
// 0 1 2 3 4 5 6 7 8 9 10 11 12 13
// ROWS |
|
Thank you @Cirromulus ! Sadly I destroyed (at least) one of the halves when I soldered the rotary encoders on the wrong side and tried to flip them around, it was the very last part to solder and I'm waiting for some new bits in the mail, looking forward to trying that out! I like that you added a comment for the STATUS_LED also :) |
|
All done :) But I don't quite understand what needs to be increased in rev1.c/g_led_config for the LEDs position to work correctly when the STATUS_LED is present, can you clarify @Cirromulus ? |
|
The |
|
I used the rgb_default keymap. Do you know of a keymap (or settings) that would behave properly? Right now some of the underglow seems mixed up with the regular lights. (I tried to increase the first part of g_led_config by 1 but per your comment that didn't fix it.)
edit: It seems to work with the following, and setting the number of LEDs in config.h: // Light combinations
#define SET_INDICATORS(hsv) \
{0, 1, HSV_OVERRIDE_HELP(hsv, INDICATOR_BRIGHTNESS)}, \
{36+0, 1, hsv}
#define SET_UNDERGLOW(hsv) \
{1, 6, hsv}, \
{36+1, 6,hsv}
#define SET_NUMPAD(hsv) \
{36+15, 5, hsv},\
{36+22, 3, hsv},\
{36+27, 3, hsv}
#define SET_NUMROW(hsv) \
{10, 2, hsv}, \
{20, 2, hsv}, \
{30, 2, hsv}, \
{36+ 10, 2, hsv}, \
{36+ 20, 2, hsv}, \
{36+ 30, 2, hsv}
#define SET_INNER_COL(hsv) \
{33, 4, hsv}, \
{36+ 33, 4, hsv}
#define SET_OUTER_COL(hsv) \
{8, 4, hsv}, \
{36+ 8, 4, hsv}
#define SET_THUMB_CLUSTER(hsv) \
{26, 2, hsv}, \
{36+ 26, 2, hsv}
#define SET_LAYER_ID(hsv) \
{0, 1, HSV_OVERRIDE_HELP(hsv, INDICATOR_BRIGHTNESS)}, \
{36+0, 1, HSV_OVERRIDE_HELP(hsv, INDICATOR_BRIGHTNESS)}, \
{1, 6, hsv}, \
{36+1, 6, hsv}, \
{8, 4, hsv}, \
{36+ 8, 4, hsv}, \
{26, 2, hsv}, \
{36+ 26, 2, hsv}
|
|
The +1 is only for keymaps using |
|
I was toying with KiCad today and ended up doing a complete cleanup of the RGB, before I noticed this PR. One thing I realized (and I implemented) is that the "jumper switches" for the different segments of LEDs can be replaced for 2 simple bypass tabs (same as the ones used for OLEDs). Let me explain: In that setup, if the Indicator LED is connected, the 1st bypass should be open. If the LED is missing, then should be closed. This way all configurations are possible and the setup and the build process are much more simple and easier to explain and solder. I have the code branched from a copy of the upstream git repo, and I am trying to figure out how I can rejoin it into my git fork so that I can create a PR for you to play with and see how i implemented the schematic. Thoughts? |
I managed to create a PR #130 with the code. I do not expect it to be merged, just added it for visibility. |
|
@Cirromulus Does the PCB in this PR have full SK6812 mini-e support with just your code changes, or is something else needed? |
If you do that, it should fit. Perhaps Dane did this already, as he wanted to flip the outline: #90 (comment) |
There is no need to get the old LEDs for backlight, just solder them the way I described in #90 (comment) because the documentation does not match. |
|
Hi all. Thank you for your work in getting mini-e support for the Sofle working. I am interested in getting this PCB printed; however, following the thread in this PR, I am confused whether the Drop-Through LED (D31-D37) pads are still flipped or whether the issue has been solved. To provide a summary of what I understand has been done with regards to the drop through lighting: It sounded like in the original PR, @tiadobatima made an incorrect assumption that the drop through lighting was facing up, when they should be facing down. To fix this issue, @DaneEvans suggested to flip the footprint for the drop through lighting:
But it sounds like this has not been implemented to my knowledge. @Cirromulus flipped the LEDs, but that did not flip the pads for the board he printed, but was able to get his to work with some clever soldering and by using some of the standard SK6812 LEDs for the drop through.
On the other hand, it sounds like @trougnouf was able to print the board from this PR without modifications and get the lighting to work without flipping the pads by soldering the LEDs in a specific way:
Please let me know if I have misunderstood any of these comments. My question is: Do the pads still need flipping, or can I get away with just printing the board from this PR and following @trougnouf's instructions? If we still need to flip the pads, let me know and I give it a shot; however I am still very new at KiCAD and PCB design in general, so I may need some guidance and mentorship to make sure I don't accidentally break anything while making the modifications. Thanks for your help! |
|
Well, I think it depends on the rgb-leds that you have. |
|
Thanks for the quick response! I was planning on using these SK6812 Mini-Es from Aliexpress, which I had assumed to be the newer kind with fins. I am still putting together the BOM, so I have flexibility in terms of what parts to purchase. I would like to avoid bodge wires if possible, so I was curious as to how @trougnouf was able to get their board to work, since it sounded like they didn't swap the pads, but was still able to use the newer LEDs without much bodging. Were the LEDs meant to be soldered the way trougnouf described, or was it a workaround? If the proper way to implement the drop through LEDs without workarounds/hacks is to flip the pads, I wouldn't mind giving it a shot in my spare time. :) |
Those are the same LEDs I got ( https://www.aliexpress.com/item/4000475685852.html ), and as far as I'm concerned it works well with the orientation described on #90 (comment) , this should be merged as the main Sofle RGB (until someone proposes something better), and it's just a documentation issue. |
|
Hi @trougnouf, Thanks for the response! Just to make sure I really understood your explanation about where to solder each LED correctly, I created a series of figures below, where the GND pad is circled in red. Did I correctly interpret your instructions?
If these figures are correct, does that means the pads were placed correctly all along? One thing that may have caused some confusion is that in KiCAD, the labeling of the pads on the back side of the board look reversed in the default view. Default View of the Back Copper Traces in Green: Note the By using the Flipped View of the Back Copper Traces in Green: Note the |
|
Yes, that looks correct. :) |
|
If someone wanted to build this, would they be using the files found in this PR or those found in PR#130? Edit: disregard, I see now that #130 is a cleanup of existing RGB v2.1 while this PR is a proposed v3. |
- Started from rgb_default - Incorporated information from: josefadamcik/SofleKeyboard#90 Regarding updated LEDs for experimental version of Sofle RGB v3.0 with SK6812 mini-e RGB
|
Just wanted to give an update. I was able to build a Sofle using the files from this PR (with SK6812 mini-E). I followed the led placement instructions from @trougnouf (summarized by my diagrams above) and all keys/LEDs/OLEDs seem to work. I am running into an issue where if I enable RGB with RGBLight, when the keyboard wakes from sleep after a while, it freezes on the first key pressed, but that is probably more of a firmware/QMK issue. Thanks for everyone's help and guidance on my first split keyboard build! Happy New Year!
|
|
I was also able to complete a build from this PR, outside of docu updates everything seems good. This is stock wireless ZMK right now, with only a special config to get LEDs running. Also running on 750mah batteries.
|
|
I've successfully built this too. |
|
Hello all, I'm so sorry I've been AWOL for so long. Turns out moving to a farm is not that easy 🤷 Second, I saw @climent 's improvement on the LED jumpers and implemented it in a different branch, because I didn't want to make more changes on a branch people are already using, so I'll likely create a separate PR for it. @climent would you mind taking at this branch to make sure I didn't butcher your idea please? https://github.com/tiadobatima/SofleKeyboard/tree/mini-e%2Bbypass |
|
I built one as well https://www.youtube.com/watch?v=klI25hiqJlc |
