Subject:
Re: FW: Microwindows 0.87pre2 released for RTEMS
From:
Joel Sherrill ####@####.####
Date:
15 Dec 1999 14:09:24 -0000
Message-Id: <38579DDC.A5E26761@OARcorp.com>
Greg Haerr wrote:
>
> : 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.
This stuff is provided with RTEMS. RTEMS supports the POSIX termios
and most (recent) RTEMS serial device drivers provide the required
interfaces.
It sounds like the serial mouse code is portable since it is layered
around the portable POSIX serial interface.
I don't know about the ps2 mouse interface. Is it essentially the same
as the serial mouse except via a different IO interface?
What requirements do you have on a keyboard driver? Again, this is
part of the console device driver. This follows the same termios model
as the serial devices with the output side going to the VGA screen.
> : 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.
I can deal with this. Microwindows has a far greater opportunity for
getting display drivers submitted and coming up with an implementation
architecture that allows them to be shared. :)
The RTEMS libchip concept might be of use here as a starting point for
thought.
We abstract the chipset from the implementation. The chipset has
certain
properties across all target boards. It may be at different base
addresses,
access methods, etc. but it is always the same behavior at a certain
level.
For example, a 16550 UART behaves identically on a 68000 and a 386. But
on
the i386, you use IO instructions while on the 68000 you are memory
mapped.
Abstracting these differences away lets you use the same driver.
Microwindows
needs to apply these same types of principles so multiple OSes can share
display drivers.
> : 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?
Yes but be warned. Compatible hardware can surprise you. There are a
number
of PowerPC boards that have PC compatible peripherals that are accessed
in very different ways than on a PC. Make sure this can work with the
architecture. Prep or CHRP compliant hardware follows this scheme. I
believe
Motorola's VMEbus/CompactPCI group and Radstone offer boards with PC
compatible
frame buffers, keyboards, and mouse ports on PowerPC VMEbus boards.
A Motorola Coldfire eval board had an ISA bus on it and memory mapped
the
Intel IO space. The driver for the NE2000 network card in this case
could
be the same but the interface mechanism was very different.
> 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... ;-)
You can never have too much documentation. But in this case, I am
guilty
of not having read it yet so don't base everything on my ignorance. :)
I just want to make sure you avoid the pit we stepped into of trying to
make a better structure after the fact. :)
> : 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.
Or even has hardware for it. :)
>
> Regards,
>
> Greg
--
Joel Sherrill, Ph.D. Director of Research & Development
####@####.#### On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
