RTEMS GUI

[Greg Haerr]

The items Erwin is proposing can be made to work
with Microwindows.  I agree that RTEMS' design
should start with just getting a framebuffer implemented.
It is very easy for Microwindows to run on top of a framebuffer,
just as it does for Linux.  In this way, the mode switching
text vs. graphics, etc is handled by the kernel, rather than
Microwindows.

In order to keep it simple, you could start with the basic
VGA driver that I've written for Microwindows and just
add it to the kernel.  Actually, all that's really required is
to add the graphics mode setup/takedown into the kernel,
and have the abililty to map the video memory address to 
user mode, and then the same VGA driver minus the
setup/takedown can be used.  Later on, a implementing
a linear buffer is definitely the way to go, for 8, 16, and 32bpp.

In regards to the input devices, whether they're mice, kbd's,
or touch panels, Microwindows Linux works by hanging on
a select().  RTEMS uses rtems_event_receive.  All that is
required is that all the input devices all be able to funnel
events and info thru a single mechanism.  Look at
microwin/src/rtems/rtems_select.c for details.  Either
the kernel or Microwindows can decode the input devices.
It's probably better that RTEMS does, and then the same
Microwindows can run on top of it.  

Having identical binaries for Microwindows and
Microwindows' applications with the kernel modified
for the hardware attached is better than having to recompile
the applications or Microwindows for different hardware 
environments.

Greg



Hello All,

AS i already wrote earlier i am looking for ppl and
information to make a base frame work for RTEMS to
make UI easier and more portable. But on an even lower level
than the video driver level from microWindows. More in the form
of a framebuffer. Of course there need to be some input devices to,
and because not (most don't) all embedded systems have a full PC
keyboard
or a mouse, there must be some option to have small (and strange) input
devices.

Here a list with some things that i think are important.

Output device (framebuffer)

1) it must support small text displays
2) it must support small dot/matrix displays
3) it must have a defined interface
4) it must be possible to use without any input device
5) it must be posible to have multiple output devices

There small LCD's don't have a memory mapped framebuffer
there must be some "update" mechanism. If there is a memory
framebuffer than there will have to be a background task that writes
it to the LCD, if there are only put/get functions it could
happen in those fuctions (or one could use memory as a write trough
cache, so put write to the display , to the memory (while waiting on the
slow
display for example) and get directly reads from the memory)
The linux framebuffer could be a base for a design. Any body 
want to at remove anything from that list ?


Input device 
1) it must support 2D relative devices (like mice, the 
		real mouse , not the cursor on the screen)
2) it must support 2D absolute devices (like touch screen, or joystick)
3) it must support 1D relative devices (like rotation knobs)
4) it must support 1D absolute devices (like faders, or potentiometer
like devices)
5) it must support keyboard with 1 to X keys
6) it must be posible to use with out any output devices
7) it must be posible to have multiple input devices

Lots of emedded systems only have like 2 or 3 keys where they control
menues with on some small text or dot/matrix display. There must
be some features to poll the device , cause not all are IRQ driven.
Small
keyboards could just be pins on a IO port of a uC/CPU. The polling
should
be hidden from the aplication, so there probably should be some task
running
to do the work and than q the results in some form. Those q'ed "input"
events
could than be read via the normal io/device-driver entry. 
Anyone else some ideas on this subject ?

And now i am going to see if i get that mircowindows working :-)

- Erwin

---------------------------------------------------------------------
To unsubscribe, e-mail: nanogui-unsubscribe at linuxhacker.org
For additional commands, e-mail: nanogui-help at linuxhacker.org