nanogui: Frame buffer Interface
Subject:
Re: Frame buffer Interface
From:
Erwin Rol ####@####.####
Date:
9 Feb 2000 21:15:55 -0000
Message-Id: <38A1E666.89FED872@muffin.org>
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
