nanogui: Frame buffer Interface
Subject:
RE: Frame buffer Interface
From:
Greg Haerr ####@####.####
Date:
8 Feb 2000 21:07:05 -0000
Message-Id: <C1962B36D9BBD311B0F80060083DFEFB054E0A@SYS.CenSoft.COM>
: Create a RAM frame buffer and write to it.
: There is running a update thread (or one cals the flush() function
: manualy)
: that compares the ram buffer with a second ram buffer , the bytes that
: are different
: and written to the LCD, and copied to the second ram buffer. That way
: one knows what is changed between two flush() calls. thinking about
: display sizes
: of for example 128 * 64 dots the video memory would be 1024 bytes.
: scanning trough
: that and comparing them will in my idea be cheaper than to write all
: those
: bytes to the actual LCD. The same for text displays they are even
: smaller 20*4 (80 bytes) times 2 would be no problem and only the chars
: that changed between the flushes
: will be updated, this will probably increase the update speed of the
: display to and should not lay much below the direct update from source
: code. It can even combine (in the graphics display) writes to the same
: byte.
: Anybody something to add or say about that ?
Yes, that will work. It's basically a "double buffered" memory
framebuffer that extra code can compare between and update
the insanely slow LCD. Forget the extra thread. Microwindows
can tell the driver to compare the buffers, and at that time the
LCD can be updated. In addition, we might need to handle
the memory framebuffer address changing when the double buffering
switches, but that's minor. So basically this is just another driver.
:
:
: secondly how is our interface going ? :-)
Rosimildo created a spec that I thought solved the problem,
you might want to read that. Any new ideas can go thru
the ioctl interface.
:
: somethign else what has more to do with RTEMS and is kind of directed at
: Rosimildo,
: what about the input devices. Is the rtems_queue an acceptable idea to
: multiplex different input devices? that way a mouse and keyboard can be
: easily combined and
: no need for events. The events posted in the queue could be something
: like;
: struct event {
: char type; // mouse, keyboard, etc.
: char dev_id; // which device mouse 1 mouse 2 keyboard 1 2 etc.
: short event; // mouse move, key up / down , button click etc.
: int flags; // 32 bits for for example pressed mouse buttons
,shift keys
: etc
: int v2; // 32 bits fro dx, dy, scancode etc.
: };
At this point, I don't think it's a great idea to have RTEMS get in
the business of mouse parsing, and "specialized" events handed
off to applications. Instead, RTEMS can fire an event when
an input file descriptor or otherwise occurs, and the application
(normally Microwindows in this case) can then read the
custom data and deal with it. For instance, with this model,
if a mouse has to change, a Microwindows shared library can
implement the new mouse, rather than having the RTEMS kernel
recompiled. In addition, with this model, adding a new device
into RTEMS is as easy as hooking up the character device,
the driver writer doesn't in addition have to implement the
above event interface, because it may not be used with
Microwindows, and it's not POSIX.
Regards,
Greg
