nanogui: Thread: Re: Microwindows 0.87pre2 released for RTEMS

Joel Sherrill wrote:
 > 

Fisrt, thanks Greg for the hard work to get the RTEMS merged.


 > 
 > Greg Haerr wrote:
 > > 
 > > Since Mark and Joel may not be on the NanoGUI list, I am
 > > forwarding this message FYI.  - Greg
 > 
 > Thanks for cc'ing us.  This is an exciting development at least
 > from the RTEMS perspective. :)
 > 
 > This is more a question for Rosilmido:
 > 
 > What is the best way to deal with the various drivers for
 > Microwindows/RTEMS?
 > My concern is that this could explode in Greg's face.  There are about
 > 40 BSPs
 > in RTEMS for 9 CPU families.  Most of these can't support Microwindows
 > but
 > there is still the possibility for a LOT of variations.  
 > 
 > I suppose that they are dependent on Microwindows at least as much as
 > RTEMS.


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" ),
  handle_screen = open( "/dev/rtems_lcd_display" ),

  ioctls( handle_screen, GET_SCREEN_CAPABILITIES, &screen_cap );

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.

With this method, Microwindows would be opening standard devices
and reading/writing to/from them. This would be the same for each
CPU/BSP.

I need to think about this a bit more. I'll try to eleborate it
more over the weekend.

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

Greg Haerr wrote:
 > : This is more a question for Rosilmido:
 > : 
 > : What is the best way to deal with the various drivers for
 > : Microwindows/RTEMS?
 > : My concern is that this could explode in Greg's face.  There are about
 > : 40 BSPs
 > : in RTEMS for 9 CPU families.  Most of these can't support Microwindows
 > : but
 > : there is still the possibility for a LOT of variations.  
 > : 
 > : I suppose that they are dependent on Microwindows at least as much as
 > : RTEMS.
 > : 
 > 
 > I would like to include all drivers for Microwindows in the Microwindows
 > source tree.  Written properly, the drivers won't have much to do with
 > RTEMS, but alot to do with the specific display hardware.  The actual
 > way that RTEMS maps the hardware (if any, since most will probably
 > just be memory mapped at hard addresses) can be abstracted once to
 > a separate routine in a separate file.
 > 

I think this is probably a good approach. I think we should
abstract the "hardware" ( kdb, mouse, video, touch-device, pen, etc ),
in a way that Microwindows does not have to have to know what CPU/BSP
the thing is running on. I do not know at this point if this is
feasible. For "character oriented devices" such as mouse, kbd
I think is very easy to accomphish it.


 > For instance, that's how I built the Linux-based "framebuffer" routines:
 > I have 4 planes VGA and linear VGA "drivers" that take an address
 > and "draw" to it.  In another file, for Linux framebuffer users, the mmap()
 > system call is used to provide a mapping in the current process address
 > space to the physical hardware.  On real mode MSDOS and protected
 > mode RTEMS, the same lower level drivers work by passing a protected
 > mode-mapped constant address to the same routines.  Thus, the
 > drivers work on any system.


This is a very good way to "abstract the video device". I totally
agree with this idea. I'll study your code to see how we can
abstract this more.


 > 
 > Rosimildo has written a serial driver for RTEMS, and included some
 > special routines to interface our select() to RTEMS.  Currently, the VGA
 > driver and mouse driver are intertwined by Rosimildo, but he should
 > probably seperate the "mouse-sequence processing" from the original
 > mouse driver and place it in a separate file.  This will then
 > allow Microwindows to use the same source for mouse processing, with
 > just a serial driver written for RTEMS, while under Linux we use /dev/ttyS1
 > for the same purpose.

Sorry. I did a "quick and dirty" port to see if anybody
was interested on it. Now it is time for clean-up and
do it the "right way".


 > 
 > A quick look at the Architecture document on the main web site
 > http://microwindows.censoft.com shows how to write screen drivers.
 > We can enhance that document for RTEMS specifically, if required.
 > 
 > When Rosimildo finds time to check out the 0.87pre2 cut that includes
 > the RTEMS integration, I will finalize a directory structure so that RTEMS
 > ports are fairly straightforward...
 > 


I'll be looking at it over the weekend.


 > In regards to the CPU families, I'm very interested in special fast routines
 > to perform memory copies etc.  These can be placed in new special
 > directories,
 > or dragged out of the RTEMS development libraries.
 > 


Which routines are critical ?

memcpy() ?


One more time, thanks Greg for the hard working that 
you are putting on MicroWindows. You are leading this
project extremely well.

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

: 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

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

: This stuff is provided with RTEMS.  RTEMS supports the POSIX termios
: and most (recent) RTEMS serial device drivers provide the required
: interfaces.  
: 
That's all that's required for kbd.  For serial mice, the same termios stuff 
can work.  (Although it's still kinda fun to see a hardware serial port
driver like Rosimildo stuck in)



: It sounds like the serial mouse code is portable since it is layered
: around the portable POSIX serial interface.

yep

: 
: I don't know about the ps2 mouse interface.  Is it essentially the same
: as the serial mouse except via a different IO interface?

Linux reads /dev/psaux and rewrites mouse sequences to be ms-mouse
compatible.  All we need to do is provide a /dev/psaux and then
we can decode them directly in Microwindows.

: 
: 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.


The kbd driver reads /dev/ttyXX in raw mode, and never writes to it, 
except for debugging.



: 
: 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.

No problem here.  As long as Microwindows stays simple and easy
to understand (I like to think of that as no #ifdefs if possible, etc) and
there are some initial video drivers available for a chipset, then people
will take them and make them work for other systems.  The drivers
are simple enough that it won't be that hard to abstract them, even
after the fact, although I know this is what you're trying to avoid.

Regards,

Greg

Joel Sherrill wrote:
 > 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?


Yes. The PS2 mouse interface works pretty much as a serial device, 
except that it has its own I/O interface and an ISR.
I'll be working to get the Linux version working with RTEMS.


 > 
 > 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.


I actually used the "console" driver for that. 
One problem that I noticed is that Microwidows requires a 
non-blocking call to receive keystrokes. I had to add such 
functionality.

My 2 cents:
I believe that "console" on RTEMS ( and embedded systems ) is more 
like a "debug port", and it should be when possible, a different device from the 
regular input device. In some cases, such as PC386, the console KDB 
and the input KBD are actually the same device. Another point that
make me think that they should be different is the case where we
want to "play" some kestrokes for demos. I see the need for you to
write to the KBD device to simulate keystrokes. Windows does
that with its "System Hooks".
This is just my view and comments are welcomed.


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

Rosimildo daSilva wrote:
> 
> Joel Sherrill wrote:
>  > 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?
> 
> Yes. The PS2 mouse interface works pretty much as a serial device,
> except that it has its own I/O interface and an ISR.
> I'll be working to get the Linux version working with RTEMS.

Great. :)

>  > 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.
> 
> I actually used the "console" driver for that.
> One problem that I noticed is that Microwidows requires a
> non-blocking call to receive keystrokes. I had to add such
> functionality.

I thought this was supported via termios just like POSIX.  It 
is possible that some driver did not get its side right.  There
is a termios test in libtests.  You best check that out.

> My 2 cents:
> I believe that "console" on RTEMS ( and embedded systems ) is more
> like a "debug port", and it should be when possible, a different device from the
> regular input device. In some cases, such as PC386, the console KDB
> and the input KBD are actually the same device. Another point that
> make me think that they should be different is the case where we
> want to "play" some kestrokes for demos. I see the need for you to
> write to the KBD device to simulate keystrokes. Windows does
> that with its "System Hooks".
> This is just my view and comments are welcomed.

A couple of alternatives:

+ Flip the flag and move the console to a com port.

+ You can close/reattach stdin, out, and error in anyway you need to.
  This sounds like what you need to do .. output to com1, input from
  console.
 
> 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

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

Joel Sherrill wrote:
 > 
 > I thought this was supported via termios just like POSIX.  It 
 > is possible that some driver did not get its side right.  There
 > is a termios test in libtests.  You best check that out.


Joel, 

Thanks for the tip. I'll check it out. RTEMS has all these
wonderful things, but thay're not easy to find.

more questions:

1. Can I use select() with the "console" ( stdin ) handle ?

2. If I write a driver for the PS2 mouse, does the select()
call works transparently with it ?. I could study the I/O
manager, but asking you might save me sometime. :-).

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

: One problem that I noticed is that Microwidows requires a 
: non-blocking call to receive keystrokes. I had to add such 
: functionality.

No, Microwindows doesn't require a polling entry point for keystrokes.
Ideally, keyboard, mouse, and client connections are waited
for using a single operating system waitforevent call, like
select(), for example on Linux.

Because certain OS's can't provide this single wait functionality,
the mouse and keyboard driver interfaces also provide a polling
entry point, but it's only supposed to be used if devices must be
polled...

Regards,

Greg