Different display modes

[jamwaffles]

Spinoff from #2 (comment):

So thinking a bit more about this. I think we can introduce display modes by separating the current buffer initialisation from the interface initialisation. Then we could use different types for the different modes and into_...() functions to turn the initialised display interface into a specific output interface.

I'd have called @jamwaffles egfx, mine char and @scowcron pixbuf.

Comments?

[jamwaffles]

Hmm, interesting problem. I quite like the idea of into_...() methods. I guess they'd be called before the connect_...() calls in the builder chain? I'd quite like whichever solution we choose to work well with Cargo's features so people don't have to include dependencies they don't want.

As for the three interfaces, what should the behaviour of each be? Right now my understanding is this:

@jamwaffles: Buffered display capable of drawing pixels, primitives, bitmap fonts and images with embedded_graphics
@therealprof: Immediate mode, text-only interface that utilises the scrolling behaviour of the SSD1306 chip. How are fonts rendered/sent? Is there a buffer at all?
@scowcron: Not sure I'm afraid. What behaviour are you aiming for? I haven't seen any code but I probably missed something.

Correcy me if I'm wrong! It would be great for this driver to support everything people want to do with it.

[therealprof]

Currently my character mode initialises the display to do 8x8 tiles with automatic increment. It comes with a built-in 7x7 font which renders each character at once so it doesn't use a buffer at all and works stateless. I also have a core::fmt::Write::write_str() adapter (somewhere, can't find it right now) that allows to use it as a simple terminal output.

[therealprof]

@scowcron driver is here: https://github.com/EdgewaterDevelopment/rust-ssd1306 . It's basically a framebuffer that allows turning individual pixels on and off and then update the display with the current content of the framebuffer.

[jamwaffles]

That sounds awesome, particularly the term output. Would be nice to see debug output without having to step through with GDB. Thinking about how it would work with this driver, I think you'd have an SSD1306Immediate struct that does its own init and has impl Char for SSD1306Immediate {} for it, both behind a feature guard. Would work well with the into_char() builder method.

Ah, I did see @scowcron's repo, just didn't put two and two together. It's already possible to set a pixel with this driver, although nicer stuff like pixel_on(), pixel_off() and invert() would be useful to integrate into the core driver. I'm not sure I can see merit in implementing them in a separate type seeing as they already need a screenbuffer.

[therealprof]

Thinking about how it would work with this driver, I think you'd have an SSD1306Immediate struct that does its own init and has impl Char for SSD1306Immediate {} for it, both behind a feature guard. Would work well with the into_char() builder method.

I was thinking along the lines of a SSD1306Output<Mode> type where each mode lives in their own module and except for the init() function pretty much defines its own interface.

I wouldn't even feature guard it. It doesn't have any dependencies so it's completely nonintrusive and free when not used.

Ah, I did see @scowcron's repo, just didn't put two and two together. It's already possible to set a pixel with this driver, although nicer stuff like pixel_on(), pixel_off() and invert() would be useful to integrate into the core driver. I'm not sure I can see merit in implementing them in a separate type seeing as they already need a screenbuffer.

Well, pretty much any implementation will need that since the screen cannot be read back (at least not in I2C mode, I think there're some versions that would actually allow that). I'm not so keen on having a driver where most of the interface is behind a feature gate. I'd rather have one which is completely gated and a simplistic one (probably sharing the same framebuffer code)... but of course I'll leave that decision up to you. ;)

[jamwaffles]

I think we can close this now. It's not perfect, but I think we've got a pretty good way of doing multiple modes exemplified by #27 :)