nanogui: Thread: Frame buffer Interface

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



: 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

Greg Haerr wrote:
> 
> 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

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.


> 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

####@####.#### wrote:
> 
> Erwin Rol wrote:
> 
> > 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
> 
> One idea on the update.  Instead of having the update thread run from a timer or have to be
> called manually, one could from the kernel revoke write privilages and trap the access
> fault on the buffer as a trigger to know when the app is changing the contents.  Then after
> a delay the update thread would perform its comparison/copyforward.
> 


Yes this is the same principle Linux uses to shift the VGA window to
emulate a
linear framebuffer for cards that don't support it. But i am having
RTEMS in the back of my head amd that at the moment doesn't support
pagelevel
protection. But yes it would work, and could be implemented on CPU's
that
do support pagelevel protection. thanks for the hint :-)

 - Erwin

Erwin Rol wrote:

> 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 ?

This sounds suspicioulsy like what VNC does maybe you can use there code.

I'd love to here  about some  speed tests on this

Mike

Erwin Rol wrote:
 > Hello All,


 > secondly how is our interface going ? :-)
 > from the previouse mails i understand we want to go for the minimal
 > framebuffer
 > idea. 

Erwin,

Sorry, I have been very busy with my primary job. I'll try to post
the header file with the interface and a new copy of the document
as soon as possible. :-).

Now, let me get back to work and "tune" some SQL Server 
application, what a pain !!!.

Rosimildo.



Thanks,
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 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.

Greg

Erwin Rol 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.
> 

This could and I hope will change.

-- 
 Chris Johns, ####@####.####

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.

cheers
     Erik

Chris Johns wrote:
> 
> Erwin Rol 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.
> >
> 
> This could and I hope will change.

Don't say that to loud. What would i want with dynamic loadable 
executables when my aplication is in ROM ? and there is nuthing like a
hard/flash disk device ? Just copy the ROM to RAM and execute.
the PC386 BSP is just one of many BSP's for RTEMS and in my opinion not
very representable for RTEMS. Most other BSP's are display less and have
only a serial conole input. There is a rather large difference if you
run
on a PIII with 128Mb RAM and X Gbyte diskspace or on a microcontroler
with
2Mbflash (not flash disk) and 2Mb ram. 

I think the RTEMS ppl have dynamic execuatbles not on a very high
priority.

- Erwin

> 
> --
>  Chris Johns, ####@####.####