nanogui: Frame buffer Interface
Subject:
Frame buffer Interface
From:
Erwin Rol ####@####.####
Date:
8 Feb 2000 20:24:21 -0000
Message-Id: <38A088BE.3D1DFCD1@muffin.org>
Hello All,
Went without mail from like a few hours so here one to keep
yer inbozx busy :-)
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.
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 ?
secondly how is our interface going ? :-)
from the previouse mails i understand we want to go for the minimal
framebuffer
idea.
We want a function (entry point) to initialize the frame buffer.
One to open it with a certain mode, and return the frame buffer address
(and for
LCD maybe start the update thread or something simulair)
one to close (and free resources like the update thread)
And a entry point for ioctl (control) functions. I would say something
like this.
struct fb_data {
int w,h; // width and height of "screen"
int line_len; // length of a line in the buffer in byte
void* buffer; // pointer to the frame buffer
int buffer_len; // lenght of the frame buffer in byte
int type; // type of screen buffer, text , graphics , bit encoding
// etc.
};
struct fb_ops {
void init(...);
void open(...);
void close(...);
void ctrl(...);
};
struct fb_info {
struct fb_ops* ops;
struct fb_data* data;
};
for the ctrl functions i at the moment can only come up with flush()
because mode switching seems hard to me cause this might or might not
cnages the address of the framebuffer, if it is a virtual framebuffer in
RAM.
i Sugests a close / open sequence to change resolution or color depth or
from text mode
to graphics mode.
coments welcome :-) (but of course will be ignored if they are negative
:-)
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.
};
annything to add. please remeber i am not thinking of the "huge" X11
event structure
it should be small cause it is copied in the queue and shoudl only hold
needed info
for input devices.
ok thats it for today.
MfG,
Erwin
