nanogui: RTEMS graphics
Subject:
Re: RTEMS graphics
From:
Chris Johns ####@####.####
Date:
5 Feb 2000 07:33:12 -0000
Message-Id: <389BCFD1.D91B8F16@acm.org>
"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, ####@####.####
