Subject:
RE: FW: Microwindows 0.87pre2 released for RTEMS
From:
Greg Haerr ####@####.####
Date:
15 Dec 1999 01:51:01 -0000
Message-Id: <796896539E6CD311B0E70060083DFEFB0777CE@NBA-SLAM.CenSoft.COM>
: I understand your concern. I guess we have to abstract the
: devices: Kbd, Mouse and Video in such a way that they look the
: same for Microwindows independently of which RTEMS BSP/ CPU is
: involved.
:
: For Kbd and Mouse, they "char" oriented devices and they match
: perfectly with RTEMS devices:
:
: Let's say:
:
: handle_kbd = open( "/dev/rtems_kbd" ),
: handle_mouse = open( "/dev/rtems_ps2_mouse" ),
I agree for the kbd and mouse, as suggested. Basically, the mouse
driver is primarily a serial port driver, not a mouse driver, and we
wrap a "mouse sequence" driver around the serial driver.
The keyboard driver is about the same. If this stuff isn't in
the kernel, then Microwindows carries around RTEMS serial
drivers, or better yet, raw hardware drivers for chipsets, with
low level RTEMS interfacing separately.
: handle_screen = open( "/dev/rtems_lcd_display" ),
:
: ioctls( handle_screen, GET_SCREEN_CAPABILITIES, &screen_cap );
I don't think we want to build display support into the kernel.
Instead, we should have "chipset" or "bios" drivers for particular
displays (VGA, SA1100 LCD, etc) written in C, with the business
of getting the protected mode memory pointers separate from the
actual line drawing routines.
Check out mwin/src/vgaplan4.c: this driver is a VGA 4 planes driver
that runs on Linux framebuffer, ELKS 16 bit realmode, and should
be fairly easily hacked to run on RTEMS. In fact, I think Rosimildo
used this for the scr_rtems.c. The point is, that vgaplan4.c is concerned
with the drawing routines, and is passed FARADDR pointers to video
memory, that the compiler/implementer determines the type of, and
initial contents of. In that way, you can guarantee that once the driver
runs on a chipset, it will run on the same chipset again, although
under a different operating environment, providing that the initial pointers
and memory allocations are setup right.
: For the video, I need some help from Greg on how we should
: abstract it, because the overhead of a driver could be un-acceptable.
: Peharps the driver should returns its features via ioctls() including
: a pointer to the "video buffer". We might want to follow the frame
: buffer approach.
:
We don't want a driver in the RTEMS kernel at this point. Following
the Microwindow's driver convention:
scr_fb.c or scr_bios.c - Microwindows "wrapper" layer for
mid-level devdraw.c engine.
vgaplan4.c or fblinX.c - actual "chip" level driver that writes
to memory or i/o locations without regard to operating system. Setup
by scr_XXX.c.
Get it?
Let me know if we need more documentation in this area. It's a concern
to me that people can use Microwindows to learn how modern graphical
operating environments can be built without requiring megabytes of source
and object code... ;-)
: With this method, Microwindows would be opening standard devices
: and reading/writing to/from them. This would be the same for each
: CPU/BSP.
Again, I think only for mouse and kbd. The video should probably
stay oriented around the chipset and stay in applications (microwindows)
code. This is the approach we took with ELKS, since not everyone
wants graphics.
Regards,
Greg
