Subject:
RE: Running document -- RTEMS framebuffer interface specificatio
n
From:
Greg Haerr ####@####.####
Date:
4 Feb 2000 22:58:50 -0000
Message-Id: <C1962B36D9BBD311B0F80060083DFEFB054C05@SYS.CenSoft.COM>
: Now the text/graphics mode problem. First of all i am thinking about
: small LCD for embeeded applications that don't even have a real
: framebuffer
: and need to be programmed "serial" via a IO port. For those devices one
: could use some virtual framebuffer in RAM and have a periodic update
: task
: update it to the real display. Or one could use put/get/draw functions
: where the set/draw functions use the memory as write trough cache. So
: the get
: functions will be very fast (real get functions might even be
: unsupported
: by the actual LCD)
I think a virtual framebuffer for your device is the answer. Then,
the graphics programs don't have to have yet another API. A
special kernel driver can then update the display. If this
is not desired, then you can specially program a Microwindows
screen driver that malloc's() a virtual framebuffer, and you don't
need any mods to RTEMS at all.
: : Second thing the Linux frame buffer is designed to support
: highresolution
: graphics controlers with CRT monitors on it. And have the virtual
: console
: backend to do the multiple text consoles and graphics framebuffers on
: one
: actual graphicscard, i think this is a bit of a over kill for a embedded
: system.
I agree that Linux framebuffer is overkill. Frank's PK system
implements a graphics console with very little code. All that's
needed really is that the kernel exports the address of the
video ram, and we call that framebuffer. Microwindows
still has ALL the draw routines. So a framebuffer doesn't
have to be complicated.
The key is a simple API, so that, rather than having Microwindows
be recompiled for every RTEMS system, the RTEMS kernel
inits/deinits the graphics mode and provides an address
and i/o permissions for Microwindows to take over. That's it.
:
: I think even the liniear framebuffers are probably not that usefull
: while
: as mentioned lots of smaller displays don't support them.
: Maybe a interface in the form of microwindows put, get , draw etc.
: would
: be the best, maybe a put get for text displays, and than optional access
: to the frame buffer if the device has one.
Actually, there are quite a few newer LCD devices that can
run in memory mapped modes. So I respectfully disagree.
For non-framebuffer devices, it would be better to build a
custom Microwindows screen driver. Otherwise, we build
one Microwindows framebuffer screen driver once for RTEMS,
and leave it at that. (Programmers should check the
microwin/src/drivers/fb.c file, since that's the only one that
actually needs to be modified, and then RTEMS could support
1, 2, 4, 8, 16, 32bpp and VGA 4 planes using existing
Microwindows screen driver scr_fb.c. All that is required
is the chipset-specific setup for each Xbpp, and a single
system call to get the video memory address mapped into
the user process space)
:
:
:
: Some ideas (RTEMS related, maybe PK too) for input devices, wouldn't it
: be a idea to define one (or more) message queue's and a defined messgage
: format with for example device ID ( mouse 1, keyboard 2) , message type
: (keyup, keydown , move x, y) and let drivers puch those message in the
: queue and let some task
: read them from that queue. The good thing about this is that in RTEMS
: one could
: have a very simple IO-pin keyboard in a ISR that can push key event in
: the queue
: too. Second thing is one can have multiple devices push to the same
: queue, like mouse
: and keyboard, so no need to collect them from different locations. And
: the interface
: would be very simple for the aplication programmer , wait on the queue
: and thats it.
I like this idea. This is almost the way it is now, with
rtems_receive_event(),
but it would be nice to have RTEMS std messages, as Erwin notes.
Regards,
Greg
:
