qmk_firmware VS qmk_firmware

I have only quickly tested it and it works as far as I can tell so far. I implemented it on top of achordion, because I use it anyway and it was quite simple to add on top of it. Maybe you still find the change interesting.

Yes, LTO_ENABLE is on and confirmed working. I just have a couple of features I'd like to use (Getreuer's accordion and layer lock -- love it!, tap dance, mouse keys, combo, leader...). My test config is here, but not functional yet, so you may see that I have for example mouse keys enabled but not used yet, but I probably will use it at some point, so I keep it enabled for now. I'm sure there is room for optimizations, but I guess I'm also spoiled by MCUs with more memory and would prefer to not have to worry about memory at all :)

Here's my keymap, for use with US Qwerty Intl. English virtual layout yet defaulting to a Colemak-DH physical layout. I basically don't use the numrow. I favour layer access via chording a single key, and biased several things to just use the left hand so I can mouse freely with my right (which has programmable buttons duplicating Ctrl & Shift). The left hand alone can chord the nav layer while also comfortably highlight whole words at a time (Ctrl+Shift+left or right arrows). The symbols are mostly paired for inwards rolls, as Colemak emphasises.

It'll somewhat depend what virtual layout you're used to the behaviour of, such as any deadkey/compose behaviour for diacritics. I use this on mine (defaulting to the Colemak-DH based alphas layer) in combination with Qwerty US International English virtual layout.

If you want to have the Lily logo orientated the 'right' way as per the original source artwork before anyone monochromed it, I put the bitmap in my repo.

Try another one for Colemak-DH while you're at it, or use mine. You can also have the Lily logo orientated the correct way too...

Sure, just expect you will iterate on your layers as you find what's most useful and comfortable for you. Here's where I'm at for coding on a split kb while also often using a right hand mouse with a few programmable thumb buttons set to be Ctrl and Shift as per the kb half.

My Lily fork is here, specifically my fontless branch where I slimmed the firmware by trying out directly encoding bitmap fragments rather than using the font glyph table system. Basically this lets me have doublesized, black on white characters to show Shift Ctrl Alt AltGr, as well as which side, and have custom Num/Caps/Scroll lock icons. For layer labels I have a mix of smaller-than-standard fonts and icons. You can just draw which pixels you want on/off in the code, each row being a vertical 8pixel column.

If it's QMK and you set up a local build environment, there should be a ´bool oled_task_user(void) {}´ in your keymap.c where you can then change the strings used, or replace the font c file to change the logo art, or even slim the firmware by skipping using the standard font system.

IIRC, LTO_ENABLE saved me like 30% so do ensure that's working, and you can save about 10% if you cut the font support and data portion out of the OLED driver (as the logo art is a large blob, and fonts work by using 1 array to index into another, even when it is sequential such as for the logo). Manually hunting for and removing those last few sprintf also made a difference. ATM I have a branch that is tinkering with direct custom OLED art instead of using fonts, if I also enable font support I get 10.5k free, with just my OLED usage 12k free, with OLED_ENABLE=no 14.7k free. So I halved the usage cost, 5% overall? I'm not optimised or done, but just want to point out there is potential to look at unused pieces of QMK and cut them out via the preprocessor, and I haven't looked at the backlight api/driver.

You can take a different space-saving approach, especially for the 32x128 OLEDs. I've been tinkering with custom Modifiers labels, layer names, as well as Caps/Num/Scroll lock state notifiers, as this allows far more letters per row than the stock font (and doesn't waste a load of firmware memory to have the bitmaps for those as well as another block mapping them to positions). Even if you use 5 rows for all those state displays, you have a large 32x88 area to put whatever animation you want, and with a custom direct 'font' you could do things like Matrix falling characters.

If you set up a local QMK build, you can tell it to use Right side as master, and reverse the rotation of the OLEDs to face inwards. Or work on you own contents that fits a horizontal orientation. E.g. WIP.