nanogui: Thread: Frame buffer Interface

Greg Haerr wrote:
> 
> : A small note: RTEMS doesn't not have shared libs, nor the posibility
> : to load a executable from disk to execute it. Everything is one
> : binary image. And you will need the posibility to leave out
> : devices you don't need to keep the memory footh print small.
> 
> Ooops. In that case, it doesn't matter whether the kernel
> or the application parses mice bytes, but I still think that it's
> overkill for the kernel to have to do it, especially if non-posix
> event structures are invented.

didn't know there where posix mouse-event structures ? :-)

think of it this way; 

someone makes a product, with some custom keyboard and joystick.
he writes al his hasrware drivers and the BSP for his product
including the framebuffer device. 
Now he wants to use microwindows on it, but of course microwindows
does not support his own developed joystick and keyboard device.
Sohe will have to write a driver and interface it with microwindows.
Which means he also has to learn the inner workings of microwindows and
so on.


now with the input device idea.

he writes his drivers. those drivers post the events to the input queue.
Micro windows already has a driver to handle the unified input device.
so he doesn't have to write a driver for microwindows, and microwindows
supports any device that one can make as long as it can convert its
input
to the events. everybody is happy :-)

so for microwindows it is just and other device like a ps2 mouse
PC-keyboard joystick
etc. just like the framebuffer hides the video hardware.

just an idea :-)

- Erwin



> 
> Greg

####@####.#### wrote:
> 
> Hi.
> 
> > ----------
> > Von:  Erwin ####@####.####
> > Gesendet:     Dienstag, 8. Februar 2000 22:21
> > An:   NanoGui List
> > Betreff:      Frame buffer Interface
> >
> > Hello All,
> >
> >
> > First i have been breaking my head to think of a way to update
> > slow LCD dot matrix displays. They have a 8 bit bus with some chip
> > selects,
> > you first write the address of the memory byte in "video" ram and than
> > the
> > actual byte for that place. This means updating the whole display from
> > CPU ram is to expencive when probably less than 10 % is changed after
> > some
> > dots drawwing. So a virtual RAM framebuffer (i first thought) would be
> > not possible. But now i came up with the following.
> >
> Some comments to T6963 based LCD's:
> I've found that bit/byte fiddling is much to slow.
> I'm updating the whole display ram with burst write from time to time.
> This is very fast, because you can strobe out byte after byte and the
> address
> pointer is increased automatically.

good point :-) i wonder where the treshold is. howlong does it take to
do
a full update and how long does it take to do a single random byte
update.
if i put my brain in "simple" mode i would think random byte write
takes two write , one address selection and the byte itself, and burst
only 
one write for the byte. 
so 2n = N   => N/2 = n  so when more than half the buffer needs to be
updated
one should use burst. So we might want to at a argument to the flush()
function 
to say it needs a full update or a bytewise update?

- ERwin
 

> 
> cheers
>      Erik
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

Erwin Rol wrote:
 > Greg Haerr wrote:
 > > 
 > > : A small note: RTEMS doesn't not have shared libs, nor the posibility
 > > : to load a executable from disk to execute it. Everything is one
 > > : binary image. And you will need the posibility to leave out
 > > : devices you don't need to keep the memory footh print small.
 > > 
 > > Ooops. In that case, it doesn't matter whether the kernel
 > > or the application parses mice bytes, but I still think that it's
 > > overkill for the kernel to have to do it, especially if non-posix
 > > event structures are invented.
 > 
 > didn't know there where posix mouse-event structures ? :-)
 > 
 > think of it this way; 
 > 
 > someone makes a product, with some custom keyboard and joystick.
 > he writes al his hasrware drivers and the BSP for his product
 > including the framebuffer device. 
 > Now he wants to use microwindows on it, but of course microwindows
 > does not support his own developed joystick and keyboard device.
 > Sohe will have to write a driver and interface it with microwindows.
 > Which means he also has to learn the inner workings of microwindows and
 > so on.
 > 
 > 
 > now with the input device idea.
 > 
 > he writes his drivers. those drivers post the events to the input queue.
 > Micro windows already has a driver to handle the unified input device.
 > so he doesn't have to write a driver for microwindows, and microwindows
 > supports any device that one can make as long as it can convert its
 > input
 > to the events. everybody is happy :-)
 > 
 > so for microwindows it is just and other device like a ps2 mouse
 > PC-keyboard joystick
 > etc. just like the framebuffer hides the video hardware.
 > 
 > just an idea :-)
 > 

Hi guys,

Finally got sometime to move on with the Micro FrameBuffer stuff.

I have specified an interface for input devices as suggested.
I thing it is pretty nice, and it'll make eisier the port
of MicroWindows to others RTOS.

This link has an initial document and a reference implementation
for RTEMS.

http://members.xoom.com/rosimildo/mw_uid.html

Hopefully, I would get everything merged with the "0.88pre1"
release soon. It seems to be faster.

As usual, comments are welcomed.

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 have specified an interface for input devices as suggested.
: I thing it is pretty nice, and it'll make eisier the port
: of MicroWindows to others RTOS.
: 
: This link has an initial document and a reference implementation
: for RTEMS.
: 

A comment on the kbd interface:  in addition to the keycode
member, we should also have a scancode member.  Some applications
want to see the kbd in scan code mode, others want to see the
keystroke.  There should also be a way to put the RTEMS
kbd driver to and from scancode/ascii mode, also.

With PC keyboards, some applications need to know whether
the keypad arrow key or just the arrow key was pressed.  The
scan codes are the same, just a different prefix byte from the 
kbd controller.  So there should be a bit set for that too; I guess
that can go into the modifiers member.

Regards,

Greg

"Greg Haerr" wrote:
 > 
 > A comment on the kbd interface:  in addition to the keycode
 > member, we should also have a scancode member.  Some applications
 > want to see the kbd in scan code mode, others want to see the
 > keystroke.  There should also be a way to put the RTEMS
 > kbd driver to and from scancode/ascii mode, also.

This would apply for a PC platform. I do not know if for embedded
systems we need that. It is easy to add one extra field to the 
message struct.

At this moment the Kbd driver for RTEMS does not do any special
mapping. I am working on it to add modes such as the one for
Linux: XLATE, RAW, etc.

Hopefully, changing modes on the RTEMS Kbd driver would be similar
to the Linux version, using IO controls. 

At higher level, how do you see MicroWindows handling Kbd
changes in mode ( ascii/scancode ) ?

 > 
 > With PC keyboards, some applications need to know whether
 > the keypad arrow key or just the arrow key was pressed.  The
 > scan codes are the same, just a different prefix byte from the 
 > kbd controller.  So there should be a bit set for that too; I guess
 > that can go into the modifiers member.
 > 

I know it is a pain !! :-).

I guess the interface for this would be pretty much molded, whenever
we decide how MicroWindows would handle that.

For the time being I'll add another field to the Kbd struct for the
scancodes.

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

: > A comment on the kbd interface:  in addition to the keycode
: > member, we should also have a scancode member.  Some applications
: > want to see the kbd in scan code mode, others want to see the
: > keystroke.  There should also be a way to put the RTEMS
: > kbd driver to and from scancode/ascii mode, also.
:
:This would apply for a PC platform. I do not know if for embedded
:systems we need that. It is easy to add one extra field to the 
:message struct.

If a kbd is present and it has an alt key, it would probably be
needed for embedded systems as well.  Otherwise there's probably
no need for the kbd interface at all.

Of course, we'll want the RTEMS interface the same regardless
of BSP.

:At higher level, how do you see MicroWindows handling Kbd
:changes in mode ( ascii/scancode ) ?
:

Sometime in the future, Microwindows will probably always
run in scancode mode, and convert internally.  This is required
for full Win32 compatibility.  If the OS doesn't support
scancode, then the WM_KEYDOWN/WM_KEYUP
messages will never be generated, and use the (translated)
WM_CHAR messages instead for all kbd input.

Greg
: