nanogui: Thread: RTEMS graphics

I've been looking a little further into existing graphics code
that we could use for Microwindows and RTEMS or another
operating system.

Actually, I'm changing my opinion in using the Linux fb code.
This is because, it's pretty messy, and overkill for embedded 
systems.  I recommend the following:

The GRX package already has the chipset-specific code
and the drawing code separated.  We could use the tested
GRX package to support various chipsets for RTEMS.
Yes, they would need rewriting, but we start with a chipset
that someone has.

Next, we use the barely modified Microwindows framebuffer
drivers that already exist, and start with a first-version RTEMS
mod that just inits/deinits the graphics mode and has
a mechanism that returns a usermode address for the video
memory (this is called framebuffer).  We could or could not
use the Linux APIs for this, it doesn't really matter.  

In this way, we start by porting specific chipset init/deinit
code from GRX into the RTEMS kernel.  We add a very
simple address-mapping capability to map a physical
address and length into usermode.  We have a simple
mechanism to set the video mode requested, in the
case that the chipset supports multiple modes.  We
have a simple facility to communicate this (start by
using the Linux ioctl() to get that info and use the
same struct, if desired.

Later, we can add a graphics console, and/or integrate
text mode and graphics with RTEMS.  In this way
we start with a simple solution that doesn't add any
more code than is required.  Basically, it's just
like the Microwindows code that's running now, 
except the init/deinit code is moved from Microwindows
to the kernel, and we get the framebuffer address from 
the kernel as well.

Comments?

Greg

> The GRX package already has the chipset-specific code
> and the drawing code separated.  We could use the tested
> GRX package to support various chipsets for RTEMS.
> Yes, they would need rewriting, but we start with a chipset
> that someone has.
> 

I'm not familiar with this package, can you pass me a pointer?


I thought I would spend a bit here discussing the current setup in
Roadrunner/pk and see if it adds anything to this discussion.  With
the VGA based console driver, the kernel init code immediately puts the
system into 640x480x16 mode.  The console driver then essentially
simulates a 80 column by 30 line display that appears like the normal
console, except its graphics instead of the regular 80x25 VGA text mode.
The main system call exported by the kernel that is used to accomplish
this is:

int dev_put(int devno, char c)

<stdio.h> routines like printf() make use of it so you can replace the
graphics and text consoles very easily.


In Roadrunner/pk the basic device structure maintained in the kernel
looks like this:

typedef struct dev {
    char            name[DEV_NAME_LEN];
    int             type;
    struct dev_ops  ops;
    int             opencnt;
}              *dev_t;

where the ops field points at an operations vector that is defined by
type.  Right now there are two types:

#define DEV_TYPE_UNUSED         0
#define DEV_TYPE_CHAR           1
#define DEV_TYPE_BLK            2

I would add a third called:

#define DEV_TYPE_FB             3

Which would be a frame buffer device type.  Here is struct dev_ops

typedef struct dev_ops {
    dev_init_func_t init;
    dev_shut_func_t shut;
    dev_ioctl_func_t ioctl;
    union {
        struct char_ops char_ops;
        struct blk_ops  blk_ops;
    }               specific;
}              *dev_ops_t;

where struct char_ops is:

struct char_ops {
    dev_get_func_t  get;
    dev_put_func_t  put;
};

and struct blk_ops is:

struct blk_ops {
    dev_read_func_t read;
    dev_write_func_t write;
};

The interface routines are typedef'd as:

typedef int     (*dev_init_func_t) ();
typedef int     (*dev_shut_func_t) ();
typedef int     (*dev_ioctl_func_t) (int cmd, void *args);
typedef int     (*dev_get_func_t) (char *c);
typedef int     (*dev_put_func_t) (char c);
typedef int     (*dev_read_func_t) (buf_t * b);
typedef int     (*dev_write_func_t) (buf_t * b);

The idea would be to add a struct fb_ops something like:

struct fb_ops {
    /* Frame buffer operations */
    dev_fb_func_1_t fb_func_1;
    dev_fb_func_2_t fb_func_2;
    ...
};

with:

typedef int (*dev_fb_func_1_t)();
typedef int (*dev_fb_func_2_t)();
...

as framebuffer type operations.  This is where someone with Linux
framebuffer experience could help out.  It'd probably be easiest for
me to just reimplement whatever operations are decided on using the
low level hardware drivers that are available.

Don't know if this helps out with the RTEMS stuff, but its the way
things are done in Roadrunner/pk.  Maybe it will spark some seeds.

For those that might be interested, I'm putting the latest code snapshot
and a bootable floppy image up that use the graphics mode console with
the bleeding edge Roadrunner/pk system at www.cornfed.com/roadrunner.
The file system is in now and its booting using its own native boot
sequence out of its own file system.

Later,
FM


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

"Frank W. Miller" wrote:
> 
> > The GRX package already has the chipset-specific code
> > and the drawing code separated.  We could use the tested
> > GRX package to support various chipsets for RTEMS.
> > Yes, they would need rewriting, but we start with a chipset
> > that someone has.
> >
> 
> I'm not familiar with this package, can you pass me a pointer?
> 
> I thought I would spend a bit here discussing the current setup in
> Roadrunner/pk and see if it adds anything to this discussion.

It does. It fits with Rosimildo's doco.

>  With
> the VGA based console driver, the kernel init code immediately puts the
> system into 640x480x16 mode.  The console driver then essentially
> simulates a 80 column by 30 line display that appears like the normal
> console, except its graphics instead of the regular 80x25 VGA text mode.
> The main system call exported by the kernel that is used to accomplish
> this is:
> 
> int dev_put(int devno, char c)
> 
> <stdio.h> routines like printf() make use of it so you can replace the
> graphics and text consoles very easily.
> 

This can be handled in RTEMS through the /dev/console device.

> In Roadrunner/pk the basic device structure maintained in the kernel
> looks like this:
> 
> typedef struct dev {
>     char            name[DEV_NAME_LEN];
>     int             type;
>     struct dev_ops  ops;
>     int             opencnt;
> }              *dev_t;
> 
> where the ops field points at an operations vector that is defined by
> type.  Right now there are two types:
> 
> #define DEV_TYPE_UNUSED         0
> #define DEV_TYPE_CHAR           1
> #define DEV_TYPE_BLK            2
> 
> I would add a third called:
> 
> #define DEV_TYPE_FB             3
> 
> Which would be a frame buffer device type.  Here is struct dev_ops
> 
> typedef struct dev_ops {
>     dev_init_func_t init;
>     dev_shut_func_t shut;
>     dev_ioctl_func_t ioctl;
>     union {
>         struct char_ops char_ops;
>         struct blk_ops  blk_ops;
>     }               specific;
> }              *dev_ops_t;
> 
> where struct char_ops is:
> 
> struct char_ops {
>     dev_get_func_t  get;
>     dev_put_func_t  put;
> };
> 
> and struct blk_ops is:
> 
> struct blk_ops {
>     dev_read_func_t read;
>     dev_write_func_t write;
> };
> 
> The interface routines are typedef'd as:
> 
> typedef int     (*dev_init_func_t) ();
> typedef int     (*dev_shut_func_t) ();
> typedef int     (*dev_ioctl_func_t) (int cmd, void *args);
> typedef int     (*dev_get_func_t) (char *c);
> typedef int     (*dev_put_func_t) (char c);
> typedef int     (*dev_read_func_t) (buf_t * b);
> typedef int     (*dev_write_func_t) (buf_t * b);
> 

I would also like a `flush'. This could be used by MicroWindows to have
a virtual buffer pushed to a display if it is remote from the address
space of the processor.

> The idea would be to add a struct fb_ops something like:
> 
> struct fb_ops {
>     /* Frame buffer operations */
>     dev_fb_func_1_t fb_func_1;
>     dev_fb_func_2_t fb_func_2;
>     ...
> };
> 
> with:
> 
> typedef int (*dev_fb_func_1_t)();
> typedef int (*dev_fb_func_2_t)();
> ...
> 
> as framebuffer type operations.  This is where someone with Linux
> framebuffer experience could help out.  It'd probably be easiest for
> me to just reimplement whatever operations are decided on using the
> low level hardware drivers that are available.
> 

Agreed.

> Don't know if this helps out with the RTEMS stuff, but its the way
> things are done in Roadrunner/pk.  Maybe it will spark some seeds.
> 

It most certainly does help. This is basically what I saw was needed.

I see from your other mail Roadrunner is GPL. RTEMS is not a full GPL.

Maybe the interface to your OS and RTEMS which resided in MicroWindows
can be standard and shared. This would help protect MicroWindows and
stop endless code being added.

-- 
 Chris Johns, ####@####.####

: I would also like a `flush'. This could be used by MicroWindows to have
: a virtual buffer pushed to a display if it is remote from the address
: space of the processor.

This specialized function is probably better implemented with an ioctl
function, rather than a new entry point.

Greg Haerr wrote:
 > I've been looking a little further into existing graphics code
 > that we could use for Microwindows and RTEMS or another
 > operating system.
 > 
 > Actually, I'm changing my opinion in using the Linux fb code.
 > This is because, it's pretty messy, and overkill for embedded 
 > systems.  I recommend the following:
 > 
 > The GRX package already has the chipset-specific code
 > and the drawing code separated.  We could use the tested
 > GRX package to support various chipsets for RTEMS.
 > Yes, they would need rewriting, but we start with a chipset
 > that someone has.
 > 
 > Next, we use the barely modified Microwindows framebuffer
 > drivers that already exist, and start with a first-version RTEMS
 > mod that just inits/deinits the graphics mode and has
 > a mechanism that returns a usermode address for the video
 > memory (this is called framebuffer).  We could or could not
 > use the Linux APIs for this, it doesn't really matter.  
 > 
 > In this way, we start by porting specific chipset init/deinit
 > code from GRX into the RTEMS kernel.  We add a very
 > simple address-mapping capability to map a physical
 > address and length into usermode.  We have a simple
 > mechanism to set the video mode requested, in the
 > case that the chipset supports multiple modes.  We
 > have a simple facility to communicate this (start by
 > using the Linux ioctl() to get that info and use the
 > same struct, if desired.
 > 
 > Later, we can add a graphics console, and/or integrate
 > text mode and graphics with RTEMS.  In this way
 > we start with a simple solution that doesn't add any
 > more code than is required.  Basically, it's just
 > like the Microwindows code that's running now, 
 > except the init/deinit code is moved from Microwindows
 > to the kernel, and we get the framebuffer address from 
 > the kernel as well.
 > 

After read all the messages posted in the last couple of days,
I guess everybody is coming to the same conclusion that, 
FB as it is on Linux, it too complicated and overkill for an
embedded environment. 

Let's keep this very simple. We need to define an interface
for the graphics driver to match MicroWindows requirements. 
My first cut for that is:


I am going to write this as something similar to IDL:


interface fb_for_microwindows
{
    /* this function returns all information regarding the
     *  display. Something similar to the struct fb_var_screeninfo 
     *  of linux FB implementation 
     */
    fb_get_screen_info()

    /* Selects the mode of the graphics subsystem */
    fb_set_mode()

    /* returns the mode of the graphics subsystem */
    fb_get_mode()

    /* Get the UserMode address of the framebuffer device */
    fb_get_fbaddr()

    /* color scheme */
     fb_get_pallete();
     fb_set_palette();

    /* initialization of the graphics mode */
     fb_init()
     fb_exit()

    /* Basic operational services of the graphics subsystem */
     fb_drawpixel()
     fb_readpixel()
     fb_drawhorzline()
     fb_drawvertline()

    /* Tell the driver that the "buffer" is dirty, and an update to the
     * real device, maybe a serial/parallel LCD, whatever is required 
     */
     fb_dirty()

};

All we have to do is define the signature and data-structures 
required by this functions.


On the driver side, it needs to provide a ioctl() that returns
the interface that MicroWindows would use. It is basically a
table with the pointers to the functions implemnted at the kernel level.

  open( "/dev/fb_svga", .. );
  ioctls( fd_no, FB_GET_INTERFACE, &driver_table );

To make a comparation to C++, the driver table returned would be like a
pointer to C++ instance with a public interface as define above.

Am I in the right track here ?

People with more "graphics expertise", please give some advise on
how to define the signature for these functions.

Rosimildo.




Thanks,
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

: Let's keep this very simple. We need to define an interface
: for the graphics driver to match MicroWindows requirements. 
: 
: interface fb_for_microwindows
: {

Great.  Almost perfect.

:     /* Selects the mode of the graphics subsystem */
:     fb_set_mode()

This may not be needed, it could possibly be merged
with fb_init().

: 
:     /* Get the UserMode address of the framebuffer device */
:     fb_get_fbaddr()

This doesn't need another entry point, it can be returned by
the fb_get_screeninfo() above.  But that means that
you'll make a kernel->user memory mapping just by opening
the device.  You might want to have another entry point,
like this one, do that.

:     /* Basic operational services of the graphics subsystem */
:      fb_drawpixel()
:      fb_readpixel()
:      fb_drawhorzline()
:      fb_drawvertline()

Drop these.  They definitely don't belong in the kernel, or you'll
have to include drivers for every framebuffer type.  That's
what Microwindows is for.

: };
: 
: All we have to do is define the signature and data-structures 
: required by this functions.

Yep.  Take a look at /usr/include/linux/fb.h for the main
ones to do with fb_get_screeninfo.


: 
:   open( "/dev/fb_svga", .. );

This should probably just be generic, i.e. /dev/fb0.



:   ioctls( fd_no, FB_GET_INTERFACE, &driver_table );

No, here just use
    ioctl(fd, FB_GETSCREENINFO, &table);
or
    ioctl(fd, FB_GETPALETTE, &table)
etc for each function above.  The kernel driver in RTEMS
cases on the FB_XXX value under the ioctl switch.


: 
: To make a comparation to C++, the driver table returned would be like a
: pointer to C++ instance with a public interface as define above.
: 
Don't bring pointers to kernel driver functions into user mode, just
case on ioctl values as explained above.

Regards,

Greg

> No, here just use
>     ioctl(fd, FB_GETSCREENINFO, &table);
> or
>     ioctl(fd, FB_GETPALETTE, &table)
> etc for each function above.  The kernel driver in RTEMS
> cases on the FB_XXX value under the ioctl switch.
> 


I think this using the ioctl approach is the easiest from my point of
view.  If I'm lucky, I might even be able to get away with no additional
ops for a then unnecessary struct fd_ops vector!  =)


Later,
FM


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

This is probably more a question for the RTEMS list, but
still of interest of the microwindows list too.

What are the costs of the ioctl/open/close lib io functions
compared to the "native" RTEMS device driver interface ?
What does it do to the memory footprint ?

Wouldn't it be more apropriate to implement the FB interface ontop
of the RTEMS device driver interface ?

- Erwin


Greg Haerr wrote:
> 
> : Let's keep this very simple. We need to define an interface
> : for the graphics driver to match MicroWindows requirements.
> :
> : interface fb_for_microwindows
> : {
> 
> Great.  Almost perfect.
> 
> :     /* Selects the mode of the graphics subsystem */
> :     fb_set_mode()
> 
> This may not be needed, it could possibly be merged
> with fb_init().
> 
> :
> :     /* Get the UserMode address of the framebuffer device */
> :     fb_get_fbaddr()
> 
> This doesn't need another entry point, it can be returned by
> the fb_get_screeninfo() above.  But that means that
> you'll make a kernel->user memory mapping just by opening
> the device.  You might want to have another entry point,
> like this one, do that.
> 
> :     /* Basic operational services of the graphics subsystem */
> :      fb_drawpixel()
> :      fb_readpixel()
> :      fb_drawhorzline()
> :      fb_drawvertline()
> 
> Drop these.  They definitely don't belong in the kernel, or you'll
> have to include drivers for every framebuffer type.  That's
> what Microwindows is for.
> 
> : };
> :
> : All we have to do is define the signature and data-structures
> : required by this functions.
> 
> Yep.  Take a look at /usr/include/linux/fb.h for the main
> ones to do with fb_get_screeninfo.
> 
> :
> :   open( "/dev/fb_svga", .. );
> 
> This should probably just be generic, i.e. /dev/fb0.
> 
> :   ioctls( fd_no, FB_GET_INTERFACE, &driver_table );
> 
> No, here just use
>     ioctl(fd, FB_GETSCREENINFO, &table);
> or
>     ioctl(fd, FB_GETPALETTE, &table)
> etc for each function above.  The kernel driver in RTEMS
> cases on the FB_XXX value under the ioctl switch.
> 
> :
> : To make a comparation to C++, the driver table returned would be like a
> : pointer to C++ instance with a public interface as define above.
> :
> Don't bring pointers to kernel driver functions into user mode, just
> case on ioctl values as explained above.
> 
> Regards,
> 
> Greg
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

: I think this using the ioctl approach is the easiest from my point of
: view.  If I'm lucky, I might even be able to get away with no additional
: ops for a then unnecessary struct fd_ops vector!  =)

yep

"Greg Haerr" wrote:
 > : I think this using the ioctl approach is the easiest from my point of
 > : view.  If I'm lucky, I might even be able to get away with no additional
 > : ops for a then unnecessary struct fd_ops vector!  =)
 > 

Ok, I have attached a "draft" of the interface beased on
ioctls(). Check if this fit our needs.

Do we need the data-structures matching the Linux ones ?

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