nanogui: Thread: Running document -- RTEMS framebuffer interface specification

Hi,

I have put something together as a starting point  for the design of 
"framebuffer" interface
for RTEMS. 

I would appreciate any inputs on how the documented should be outlined, 
and any addition/removal
of content.

It is intended as a "minimal feature list" that the interface should 
provide, so we can get some
understanding of what we intend to implement. :-).

http://members.xoom.com/rosimildo/mw_rtems_drv.html

Everybody is welcomed to add to it. I guarantee to add your name to the 
list of
contributors. :-).

Rosimildo.





______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

: I have put something together as a starting point  for the design of
: "framebuffer" interface
: for RTEMS.

Rosimildo -
    It's a good start, I like the diagram ;-).  Using the source from Linux
framebuffer code could be a great idea since that's a heck of alot of code
that doesn't have to be rewritten.  There are considerations, though, and that's
that there's quite a bit of 16-bit boot code that's executed for the Linux
video stuff before the framebuffer code ever executes.  So it's going to
be complicated.

Perhaps a better idea would be to start with a ripped version of the
sfb.c (simple framebuffer), kind of a skeleton, and make it work with
the RTEMS console, using the VGA code that we're currently using
in Microwindows, and is known to work.

After that, adding chipsets by inspecting some of the Linux fb code could
work...  It could be a big project, depending on which cards we want to
support.

Regards,

Greg

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

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: ####@####.####

: 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



: 

Ron wrote:
> 
> Erwin Rol wrote:
> 
> > ...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. ...
> 
> We disagree-
> Actually for our needs here at GIPCO on the fly mode switching is a must.
> It comes down to the amount of on board video ram, the need to display
> hi res-low color depth user screens and true color jeg/bmp image files
> on the same device. Adding more video ram is unfortunately not an option.

Ok i was actualy only thinking about TEXT <-> GRAPHICS mode switching
but you have a very good point there. So on the fly changing should be
posible.

- Erwin

Rosimildo daSilva wrote:
 > Hi,
 > 
 > I have put something together as a starting point  for the design of 
 > "framebuffer" interface for RTEMS. 
 > 

Hi guys, 

I have updated the documentation of the "micro framebuffer" interface.
I have added links to some header file and API wrapper around ioctls
as we discussed last week. I have not tried to compile this stuff yet.
If this does not fit "yours" needs, please speak up. :-).

Anyone, with more time than me, is allowed to modify this stuff and
send me the files that I'll update them, as soon as time allows me to
do it.

Same place:
http://members.xoom.com/rosimildo/mw_rtems_drv.html

Rosimildo.




______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

Rosimildo daSilva wrote:
> 
> Rosimildo daSilva wrote:
>  > Hi,
>  >
>  > I have put something together as a starting point  for the design of
>  > "framebuffer" interface for RTEMS.
>  >
> 
> Hi guys,
> 
> I have updated the documentation of the "micro framebuffer" interface.
> I have added links to some header file and API wrapper around ioctls
> as we discussed last week. I have not tried to compile this stuff yet.
> If this does not fit "yours" needs, please speak up. :-).

Starts to look good. 

> 
> Anyone, with more time than me, is allowed to modify this stuff and
> send me the files that I'll update them, as soon as time allows me to
> do it.

Time hmmm yeah what is that :-)

> 
> Same place:
> http://members.xoom.com/rosimildo/mw_rtems_drv.html
> 
> Rosimildo.
> 
> ______________________________________________________
> Get your free web-based email at http://www.xoom.com
> Birthday? Anniversary? Send FREE animated greeting
> cards for any occasion at http://greetings.xoom.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

Rosimildo daSilva wrote:
 > Hi guys, 
 > 
 > I have updated the documentation of the "micro framebuffer" interface.
 > I have added links to some header file and API wrapper around ioctls
 > as we discussed last week. I have not tried to compile this stuff yet.
 > If this does not fit "yours" needs, please speak up. :-).
 > 
 > Anyone, with more time than me, is allowed to modify this stuff and
 > send me the files that I'll update them, as soon as time allows me to
 > do it.
 > 

Hi,

I have compiled the code of our interface, and wrote a "skeleton"
driver for RTEMS ( it actually compiles ) along with the MicroWindows
glue ( Micro FrameBuffer ) discussed in the past few weeks.
Before I finalize the tests, and package it as a "patch", I would 
appreacite any feedback. I have added the sources as links in the 
document on the link below.

Same place:
http://members.xoom.com/rosimildo/mw_rtems_drv.html

Rosimildo.


______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

: I have compiled the code of our interface, and wrote a "skeleton"
: driver for RTEMS ( it actually compiles ) along with the MicroWindows
: glue ( Micro FrameBuffer ) discussed in the past few weeks.
: Before I finalize the tests, and package it as a "patch", I would
: appreacite any feedback. I have added the sources as links in the
: document on the link below.

I have looked over all your source and it looks great.  You will
of course have to link in ega_hwinit and ega_hwterm into the kernel...

Your code also assumes that there is the same address space between
kernel and user modes for the framebuffer.  I don't know if that's the best
idea or not.  But I guess you will always pass this address in
fbinfo.smem_start?

Greg