Philip Howard

Thanks for this, I borrowed your patching-n_fats trick for ffsmake: https://github.com/gadgetoid/ffsmake +1 for having a bump to at least 0.14 since `n_fats == 2` is probably pretty critical to error...

> I'm making my own board definition I am intrigued. > Ideally this treatment would be done to every configurable parameter I tend to agree. For user-facing, firmware-like deployments there...

Related to https://github.com/micropython/micropython/issues/16797?

Apparently the very bottom of the README was a bad place to hide this information: https://github.com/pimoroni/inky?tab=readme-ov-file#chip-select-line-8-gpio8-currently-claimed-by-spi0-cs0 I think we might need to detect the OS version and have the installer...

> what OS versions will see this problem? @r-rayns actually the OS version check is possible redundant, since anything capable of running the new libgpiod code *should* have GPIO8 exclusively...

An out-of-SDK JPEGDEC port seems like a reasonable alternative if that's what you're hinting at?

Niiice! I should drag my brain kicking and screaming back into the world of the productive and try to port Rocks & Diamonds.

This is a fundamental issue with the GPIO Character Device ABI on Linux, and how it (arguably correctly) handles mutually exclusive ownership of pins. That said, it should be possible...

There’s a fix for this - and other issues with SDK 2.0.0 - in one of the open PRs here- just requires an include change. I’ve been quite focussed in...

Collating those fixes here - https://github.com/pimoroni/pimoroni-pico/pull/1008