[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |