Thanks Stewart!
I think I noticed your post about running Doom, when I was about half way done with my project. At first I thought "oh, someone's already doing this", but it became clear we had different goals when you said that you didn't intend to make a PS Vita with this, and I kind of did... You're projects sound really interesting though!
But I agree, that getting Doom to compile/run wasn't the challenge (that took like half a day in my environment), but getting performance out of the display was the interesting part. What kind of frame rate did you get with FBTFT?
I thought about writing a kernel interface, like a framebuffer device or something custom. Some simple tests showed it wouldn't be faster, so I saved myself the headache with poor debugging and high turnaround time... took like 30 minutes from writing code till having a flashed new kernel running. I hope there are better workflows, maybe when writing a module it's much better?
The performance test I made was moving the code to clear the whole screen with a single color directly into the kernel GPIO driver (gpio-langwell.c). As a super hack when a pin with a certain pin number would be written, it would actually kick off the test code and write repeatedly as quickly as possible to all the data pins for a full screen fill. It ended up taking exactly as long as the memory mapped IO version from user space. It must be just bound by the bus speed of that memory.
It would probably still be interesting to move the 8-bit display code into FBTFT, so that other programs could use the display easily without code modifications. Feels a bit more like productization instead of hacking though, so a little less fun