nanogui: Re: Frame buffer Interface] oops only replied to Gerg
Subject:
[Fwd: Frame buffer Interface] oops only replied to Gerg
From:
Erwin Rol ####@####.####
Date:
8 Feb 2000 21:37:42 -0000
Message-Id: <38A09A11.2DBBB391@muffin.org>
Erwin Rol wrote:
>
> Greg Haerr wrote:
> >
> > : 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
>
> The buffer address doesn't change. think as of as this.
>
> B1 the actual ram in the LCD controler, is wat is displayed on the
> screen.
> B2 the shadow image of B1 this is the same as B1 but in CPU ram
> B3 the framebuffer we draw in.
>
> one draw in B3 as much as you want.
>
> call flush();
>
> void flush() {
> for(int n=0; n < BUFFER_SIZE;n++){
> if(B3[n] != B2[n]){
> B2[n] = B3[n];
> write_to_lcd(B2[n]); // copy the byte to the LCD ( B1 )
> }
> }
> }
>
> now B1 == B2 == B3 and we can draw to B3 again.
>
> - Erwin
