juj

The display does look like it could be supported within current driver design. I don't unfortunately have the display (or even if I did, unfortunately not able to spend time...

Oh right - indeed, the spec sheet documents the protocol. In general the porting process is as follows: 1) Write the initialization sequence for the display. E.g. ILI9341 has it...

fbcp-ili9341 indeed does not, unfortunately, allow sharing the SPI bus with other drivers, but any sharing of the bus will need to be tightly coordinated inside the main fbcp-ili9341 driver...

Theoretically it could be developed to support that, but currently such multi display functionality is not possible. It would need quite a bit of refactoring though.

I have not used either Banana Pi or Armbian, but I presume it would not work on either. Fbcp-ili9341 depends on the Broadcom SoC and raspbian DispmanX stack. Not sure...

CC @mootikins for visibility.

This is a great suggestion, something that I had mentioned in the TODOs in https://github.com/juj/fbcp-ili9341#i-want-to-contribute--future-work--todos . Unfortunately I can not at the moment take time to tackle this, so feel...

Sounds great - if you have access to a 120fps camera or similar, would be great to observe how input-to-display latency is affected. Likewise for CPU usage with `top`/`htop`. Such...

hmmhmm, very odd indeed. This kind of thing seems to be about the compiler version, rather than he hardware or OS itself (though OS distros certainly dictate which compiler is...

My expectation with the code in that function was that it would get inlined and avoid any memory load/stores in the first place. I.e. the `mov`s from those variables should...