RTEMS GUI

[Erwin Rol]

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