nanogui: Running document -- RTEMS framebuffer interface specification
Subject:
Re: Running document -- RTEMS framebuffer interface specification
From:
Erwin Rol ####@####.####
Date:
4 Feb 2000 21:27:28 -0000
Message-Id: <389B51C9.C4D7FC9A@muffin.org>
Hello All,
first Frank do you want that new version of to bootloader for lilo
to, it is from the new kernel and uses GAS and not AS86 , just drop
me a mail.
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)
Because my interest goes out to those smaller displays, the mode
switching
is no problem, simply because it isn't posible.
I also think that embeded system won't need mode switching in the first
place.
So in my opinion the "mode" of the display is part of the BSP, a design
time
decision.
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 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.
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.
- Erwin
Greg Haerr wrote:
>
> Rosimildo,
> As I think about this a little more, one important factor is
> whether or not RTEMS wants to support graphics mode for
> console operation. This adds complexity. If merely a framebuffer
> is desired, it is quite a bit simpler, because all RTEMS has to manage
> is the switch between text and graphics, video init, and the actual
> framebuffer mapping.
>
> To support a graphics console, there have to be quite a few more entry points,
> and the framebuffer code has to support being accessible inside
> the kernel, rather than just address-mapped video memory access to
> applications.
>
> Frank's PK supports a graphics console, and he has kept the
> system quite simple. Perhaps his code is a good place to start.
>
> Greg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
