Miguel Ojeda Sandonis wrote:
Andrew, here it is the patch for converting the cfag12864b driver
to a framebuffer driver as Pavel requested and as I promised :)
Very nice :)
Just a few comments, see below.
Pavel, yep, now I can login in my tiny 128x64 LCD.
It is pretty amazing to run vi on it... ;)
Tested and working fine.
---
[...]
+static void cfag12864b_update(void *arg)
[...]
+ for (i = 0; i < CFAG12864B_CONTROLLERS; i++) {
+ cfag12864b_controller(i);
+ cfag12864b_nop();
+ for (j = 0; j < CFAG12864B_PAGES; j++) {
+ cfag12864b_page(j);
+ cfag12864b_nop();
+ for (k = 0; k < CFAG12864B_ADDRESSES; k++) {
+ cfag12864b_address(k);
+ cfag12864b_nop();
+ cfag12864b_nop();
Doesn't the LCD controller automatically advance the address when
writing data?
If it does, the address should only be needed before this loop and you
could write 64 bytes in a row without any "nop"'s. This should really
improve the time it takes to refresh the display.
Also, keeping a "low level cache" of the physical display state and only
sending bytes that have actually changed might be a good improvement too.
Remember, the host CPU is probably much much faster than your interface
to the LCD, so if it takes a few cycles to check the cache and decide
not to send a byte, it's already a big win. A simple memcmp might be
used skip full pages.
Also, what do these "nop"'s do? Isn't there a way to read the "busy"
status from the controller and just write as fast as possible?
[...]
+ The LCD framebuffer driver can be attached to a console.
+ It will work fine. However, you can't attach it to the fbdev driver
+ of the xorg server.
This is probably because your driver can't be mmapped, no?
Although the controller is only accessible through the parallel port, it
might be possible to mmap it. I vaguely remember that when I was reading
LDD3, I thought that this should be doable in a sequence like:
- accept the mmap as if you had the memory for the device available
- at "nopage" time, mark the buffer as "dirty" and map it to user space
- using a timer at the actual refresh rate, check the dirty flag. If
it is dirty, unmap the buffer and refresh the display
I'm not describing the locking details (and a lot of other details,
too), but it should work in principle.
It will probably make things easier if your buffer size is PAGE_SIZE,
and your "internal" operations (fillrect, copyarea, imageblit) also work
over the same buffer and just mark the buffer as dirty.
I don't know if X will be able to run in 128x64, but it is easier to
make applications mmap the buffer and use it directly.
--
Paulo Marques - www.grupopie.com
"The face of a child can say it all, especially the
mouth part of the face."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
