Lily58-Acrylic-Case VS qmk_firmware

Now go print up a BoardSodie case for it or buy one of these. The worst thing about Lily is that dumb sandwich case :D

Thank you! Used Ponoko to cut a slightly modified version of BoardSodie's case https://github.com/BoardSodie/Lily58-Acrylic-Case

I used files from GitHub and had a friend cut the acrylic with their Glowforge. Here is the link to the files: https://github.com/BoardSodie/Lily58-Acrylic-Case

Printed up a Boardsodie case?

Lily58 Pro Acrylic Case https://github.com/BoardSodie/Lily58-Acrylic-Case

I use https://github.com/BoardSodie/Lily58-Acrylic-Case which definitely beefed mine up a little bit (I'm on Drop Holy Pandas and tactile feel but not THOC sound is my priority).

Followed /u/blessedsodiepop's excellent https://github.com/BoardSodie/Lily58-Acrylic-Case to print out an acrylic enclosure that's light-years better than the default Lily58 "case" that it came with. This case holds the switches in place so they no longer pop out when struck the wrong way, which is a huge QOL advantage. Feels nice and solid too.

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.