nanogui: Thread: Technical Framebuffer proposal for RTEMS graphics

In looking at microwin/src/drivers/fb.c, I have identified the following few
entry points as the minimal set of functionality for Microwindows
to run on ANY framebuffer kernel.  I suggest that these functions, with
a suitable API, be implemented in RTEMS, as a very simple first round.

1. open() of framebuffer device
2. ioctl() to get framebuffer info:
    xres, yres, bpp, linelen, type, visual, size
    type is packed pixels or planes
    visual is truecolor or pseudo color
    type/visual is used to identify which fblinXX.c should be used for drawing
        by Microwindows. not a big deal.
    size - size of framebuffer

3.  mmap() call to map the framebuffer fd and size into this process' address
space.  This
could be replaced with the open framebuffer automatically being mapped into
the process space, and just returning its virtual linear address in 2) above, if
mmap()
isn't around.  Alternatively, the ioctl above could return the physical address
of video, and a separate new physical address -> virtual linear address system
call could be added to the kernel.  This is slightly simpler than mmap().
This item is the hardest part for RTEMS, and requires the most thought.

4. ioctl to switch to graphics mode.
5.  ioctl to get the current palette, which is saved. (not required for
truecolor)
6. ioctl to set the Microwindows palette at init. (not required for truecolor)
7. VT switching code, which is complicated, and should be left out in this first
version.

<thats it, Microwindows programs can now run with this little information>

8. On Microwindows exit, an ioctl() to reset the palette and an ioctl() to
switch back to text mode, followed by a munmap() and close(fb).


It doesn't have to be complicated.

Regards,

Greg

RTEMS has the following device entry points;

1. initialization()
2. open
3. close
4. read
5. write
6. control

The initialization function is called by RTEMS io manager to initialize
the
driver and device. (this could set the framebuffer in some standard
mode, like
80x25 text)

the open function could be used to open a framebuffer in a certail
resolution
and colordepth (depending on the parameters passed.

The close can be used to switch back to standard mode again.

the control function could be comparable to the ioctl function. 

the read/write functions could be used as pixel set/get functions.


- Erwin



Greg Haerr wrote:
> 
> In looking at microwin/src/drivers/fb.c, I have identified the following few
> entry points as the minimal set of functionality for Microwindows
> to run on ANY framebuffer kernel.  I suggest that these functions, with
> a suitable API, be implemented in RTEMS, as a very simple first round.
> 
> 1. open() of framebuffer device
> 2. ioctl() to get framebuffer info:
>     xres, yres, bpp, linelen, type, visual, size
>     type is packed pixels or planes
>     visual is truecolor or pseudo color
>     type/visual is used to identify which fblinXX.c should be used for drawing
>         by Microwindows. not a big deal.
>     size - size of framebuffer
> 
> 3.  mmap() call to map the framebuffer fd and size into this process' address
> space.  This
> could be replaced with the open framebuffer automatically being mapped into
> the process space, and just returning its virtual linear address in 2) above, if
> mmap()
> isn't around.  Alternatively, the ioctl above could return the physical address
> of video, and a separate new physical address -> virtual linear address system
> call could be added to the kernel.  This is slightly simpler than mmap().
> This item is the hardest part for RTEMS, and requires the most thought.
> 
> 4. ioctl to switch to graphics mode.
> 5.  ioctl to get the current palette, which is saved. (not required for
> truecolor)
> 6. ioctl to set the Microwindows palette at init. (not required for truecolor)
> 7. VT switching code, which is complicated, and should be left out in this first
> version.
> 
> <thats it, Microwindows programs can now run with this little information>
> 
> 8. On Microwindows exit, an ioctl() to reset the palette and an ioctl() to
> switch back to text mode, followed by a munmap() and close(fb).
> 
> It doesn't have to be complicated.
> 
> Regards,
> 
> Greg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

"Greg Haerr" wrote:
 > In looking at microwin/src/drivers/fb.c, I have identified the following few
 > entry points as the minimal set of functionality for Microwindows
 > to run on ANY framebuffer kernel.  I suggest that these functions, with
 > a suitable API, be implemented in RTEMS, as a very simple first round.
 > 
 > 1. open() of framebuffer device
 > 2. ioctl() to get framebuffer info:
 >     xres, yres, bpp, linelen, type, visual, size
 >     type is packed pixels or planes
 >     visual is truecolor or pseudo color
 >     type/visual is used to identify which fblinXX.c should be used for drawing
 >         by Microwindows. not a big deal.
 >     size - size of framebuffer
 > 
 > 3.  mmap() call to map the framebuffer fd and size into this process' address
 > space.  This
 > could be replaced with the open framebuffer automatically being mapped into
 > the process space, and just returning its virtual linear address in 2) above, if
 > mmap()
 > isn't around.  Alternatively, the ioctl above could return the physical address
 > of video, and a separate new physical address -> virtual linear address system
 > call could be added to the kernel.  This is slightly simpler than mmap().
 > This item is the hardest part for RTEMS, and requires the most thought.
 > 
 > 4. ioctl to switch to graphics mode.
 > 5.  ioctl to get the current palette, which is saved. (not required for
 > truecolor)
 > 6. ioctl to set the Microwindows palette at init. (not required for truecolor)
 > 7. VT switching code, which is complicated, and should be left out in this first
 > version.
 > 
 > <thats it, Microwindows programs can now run with this little information>
 > 
 > 8. On Microwindows exit, an ioctl() to reset the palette and an ioctl() to
 > switch back to text mode, followed by a munmap() and close(fb).
 > 
 > 
 > It doesn't have to be complicated.
 > 

Greg,

I've just posted a message with an interface similar to yours.

A small difference is how the access to the driver is made. 
In your proposal, many ioctls() calls to do different things. 

The one that I proposed the driver would provide
a table with the entry points for the services provided
by the driver.

I have no preferences for one way or the other. 
The good thing is that we all agree that a very 
simple interface is required.

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

: A small difference is how the access to the driver is made. 
: In your proposal, many ioctls() calls to do different things. 
: 
: The one that I proposed the driver would provide
: a table with the entry points for the services provided
: by the driver.
: 
The addresses returned by the kernel aren't valid for
user mode routines to call directly in RTEMS, right?
They certainly aren't in Linux.  That's why I suggest
ioctl.


Regards,

Greg

Greg Haerr wrote:
> 
> : A small difference is how the access to the driver is made.
> : In your proposal, many ioctls() calls to do different things.
> :
> : The one that I proposed the driver would provide
> : a table with the entry points for the services provided
> : by the driver.
> :
> The addresses returned by the kernel aren't valid for
> user mode routines to call directly in RTEMS, right?
> They certainly aren't in Linux.  That's why I suggest
> ioctl.

I believe everything is flat without protection in RTEMS ?
but it isn't in Frank's PK, and we might want to make a interface
that works on both ?
 



> 
> Regards,
> 
> Greg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

: I believe everything is flat without protection in RTEMS ?
: but it isn't in Frank's PK, and we might want to make a interface
: that works on both ?

I see.  Well, we should definitely use the ioctl() method so that it
doesn't have to be redone when/if protection is added.

For some reason, I thought that RTEMS had separate address spaces
for user and kernel.

Greg

"Greg Haerr" wrote:
 > : A small difference is how the access to the driver is made. 
 > : In your proposal, many ioctls() calls to do different things. 
 > : 
 > : The one that I proposed the driver would provide
 > : a table with the entry points for the services provided
 > : by the driver.
 > : 
 > The addresses returned by the kernel aren't valid for
 > user mode routines to call directly in RTEMS, right?

It runs in protected mode as a single flat address space.
No difference user/kernel modes. Basically, you can
access anything. This might change later... :-).

ioctls seems to fit better.

 > They certainly aren't in Linux.  That's why I suggest
 > ioctl.



______________________________________________________
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

> the read/write functions could be used as pixel set/get functions.
> 

Hehe.  I was waiting for someone to propose this.  I hope you'll pardon
me now, I'm going to start down a monologue based on my dissertation
work.  If you're not into windbag academic arguments, just hit `d'
now.

Many moons ago (or about a year anyway) I was working on something called
data streaming through the kernel.  The idea was to use a single buffer
representation that was similar to mbufs in all the I/O elements, file
systems, network protocols, and yes the windowing system, so that data
could be passed between these systems easily by reference.

When I got round to thinking about how this would work with the graphics
devices, I started to think about allowing something like this:

ioctl(fb, START_BLIT)
stream(source, fb);
ioctl(fb, END_BLIT)

The idea is to give the graphics system the parameters for the destination
of the blit in the START_BLIT and then feed it zero-copied buffers from
whatever source, a file, a socket, another part of the screen.  This would
in theory boost transfer performance dramatically.  I did lots of work on
this with file systems and network protocols but never got around to 
implementing it for a graphics system.

The main trouble here is the fact that theres no atomicity between the
ioctls and the stream calls.  This could make it tricky, I didnt go far
enough down the path to figure it out.  Anyway, this is all probably not
really relavent here right now.  Some might find it mildly interesting tho
so wtf.  For fun, a link to my disseration is at
http://www.cs.umd.edu/~fwmiller/doc/dissertation/dissertation.html.

Later,
FM

--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com