nanogui: RTEMS graphics
Subject:
Re: RTEMS graphics
From:
"Frank W. Miller" ####@####.####
Date:
5 Feb 2000 04:07:48 -0000
Message-Id: <200002050255.VAA03544@macalpine.cornfed.com>
> 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
