Vncserv must do something similar, maybe that is worth looking at. I went down a similar route but am planning to just address the display as a different type of device, rather than as a plan9 display.
Your progress is very impressive, my project stalled - I must get back to it. -Steve On 15 Aug 2015, at 03:49, Brian L. Stuart <blstu...@bellsouth.net> wrote: >> I have tried to email BLS but fear I am being spam filtered... you there? > > I did get one message from you, and replied earlier today. Hopefully > it got through. > > A little more update on recent pi playing. I've been working on a > little toy the last few days, namely one of those small SPI driven > LCD panels: > > http://www.adafruit.com/products/2441 > > As of this evening, I've gotten it sort of running alongside the > HDMI display showing the upper left corner. Here are a few > pics of it in operation: > > The Pi with the display connected to a keyboard and mouse: > > http://cs.drexel.edu/~bls96/9pitft1-s.jpg > > and a couple of pics of the display showing acme running: > > http://cs.drexel.edu/~bls96/9pitft2-s.jpg > http://cs.drexel.edu/~bls96/9pitft3-s.jpg > > It's a long way from being usable though. The fundamental issue > is that there appears to be a very deeply embedded assumption > that a screen must be memory mapped. I tried hooking into > the hwdraw() routine in screen.c, but it seems that not every > change to the screen memory space gets reflected in a call > to hwdraw(). For the pics, I've got a version that periodically > copies the whole of the appropriate area of the Memimage > to the LCD panel over the SPI port. Obviously, that's too slow > and too resource-hungry to be practical. Hopefully, I'm missing > something and there's an elegant way to graft a non-memory > mapped display into the devdraw/memdraw/screen infrastructure. > > BLS >
