[En-Nut-Discussion] New displays, chained devices, best way or how to

[Ole Reinhardt]

Hi,

sorry for jumping into this discussion late so I'll probably answer
older questions in this mail too.

> Regarding best way of...
> The term functions are pretty fine and I don't see a reason for throwing them away. But the term is calculating in characters.
> I implemented a character driver and can now stack it upon term. But this disables the option to use graphical functions. 
> It even fails if I'd like to use fonts of different size or height. So my idea is to copy term into gterm and modify gterm:
> - Calculating in pixels instead of characters. 
> - Append _ioctl options to switch between binary mode and character mode.
> - Second step would be to implement variable width fonts.
> - Expand ESC sequences for font selection
> - Expand the ESC sequences for adding special graphical functions. 

Ok, let's discuss this terminal emulation thing.

Terminal emulation is just done on the character level. It shall emulate
some subset of the VT42 I think. So that's not the right way to talk
with a graphical display on the low-level view.

What you would better need is some kind of a frame buffer driver.

So: First implement a framebuffer, that gives you a memory reagion to
write your graphics data into. The framebuffer driver at least shall
initialize the graphics display and perhaps implement some more
sophisticated functions like copying an image reagion or drawing of some
very primitives like lines / circles. But even those drawing functions
should better be located in a low level graphics library, so that you
framebuffer should simply provide the memory and should update the
display in a regular manner. Perhaps, if your display supports some
graphics acceleration, provide an interface for the graphics API to use
these accelerations.

On top of this very low framebuffer implementation. You would the
implement a low level graphics api, providing pixel drawing, line
drawing and so on. You should also provide some kind of text api, that
will be used to draw single characters as well as strings.

Now you have everything to provide a text buffer. Ans that's the point
where you get in contact with the terminal emulation again. As you now
can implement a text layer upon your graphics layer. Eventutaly it would
be nice to implement virtual terminals as well, where you can
instantiate a terminal in just a small window of you graphics region and
another one in another window.

> Fonts is a special theme here. I know about 3 or 4 different ways displays like to have their data oriented. 
> So it might be necessary to hav a tool compiling the fonts from a raw format to the displays specific format. 
> Yes, one could fit the data in the target software and throw it to the display, but it will waste lots of 
> CPU power and code space. It would be more efficient to have the fonts selectable and optimized for a 
> simple access. 

Yes for shure. There are even some displays out there which support
native font drawing as acceleration function too.

So my Idea would be to implement a general framebuffer driver api where
you can register the different acceleration options you display provide.
If the display driver does not register this acceleration function it
will be emulated on a software basis by the graphics api and so will be
done with the font rendering too.

> And at least I'd like to use the display more automated. I didn't
>  analyze the SPI code and don't know if it uses DMA and things like
>  that to keep code and hassle with threads small. But I'll find out.

Just one hint if you use SPI: If you will only send small data packets
(just a single or very few bytes) over SPI, use the polling mode. It's
much faster than the dma mode, as the overhead is larger than the speed
gain for such short transfers. If you have large transfers (sending a
whole image for example) DMA transfer gets way faster though.

> >> I had issues too, with the autotools. I couldn't generate the Makefile
> >> under Gentoo. It just can't find lua files, don't know about others.
> >> Is that the same problem you are having?
> >>
> > Some externals from us ported the 4.6.4 code to work on linux and they
> > promised to push any open source code modifications back to the
> > community. So under suse 10 and ubuntu >7.x it's compiling fine in the
> > shell. But the GUI configurator has it's problems. It starts but doesn't
> > get very far. You might see duplicate scrollbars and only one is working
> > mostly. The other one sends the gui to hell.
> >
> 
> Hmm I never got it to compile so I haven't seen that behavior. It
> works ok under Windows.

So for what I can say I use the configurator now since quite some time
on Debian/sid and Ubuntu Intrepid. Both are able to compile the
configurator without problems provided that you have installed all
needed depenencies (like liblua and wxWidgets >= 2.8) for example.

There are some known issues, but you will run fine, if you use the
lastest CVS version (or unstable release) of the NutOS code.

> I cannot mix up version now, but will do that may be on a private basis after the new drivers work smart.

There is no problem with compiling / installing just the configurator
from the most recent NutOS version and using it with older NutOS trees.

Hope I could give you some ideas for your api. It might be a good idea
to bring this discussion to the wiki and to get some more views, as this
is not a simple design decision and might result in doning some work
more than once if everybody designs it's onw graphics api. Graphic
displays are becoming that cheap that sooner or later NutOS needs some
well designed graphics api.

And if we just started thinking about it we are in need of well designed
widget set for this api too.

Bye,

Ole

-- 
 _____________________________________________________________
|                                                             |
| Embedded-IT          Hard- und Softwarelösungen             |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        +49 (0)271  7420433 |
| Luisenstraße 29      Mobil:             +49 (0)177  7420433 |
| 57076 Siegen         eMail:    ole.reinhardt at embedded-it.de |
| Germany              Web:         http://www.embedded-it.de |
|                      UstID / VAT:       DE198944716         |
|_____________________________________________________________|