PATCH: Framebuffer for C123 and C155

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Christian Vogel vogelchr at vogel.cx
Mon Oct 11 21:01:02 UTC 2010


{Resent, it didn't appear on the list after 20 minutes.}

Hi,

I had some spare time the last days and put together a first attempt
at a framebuffer for the OSMOCOM mobiles.

It currently supports the C123 and the C155, the only two
phones I own.

> On Sat, 10 Apr 2010 10:26:05 +0300, Harald Welte
> >1) we need a way to select between individual fonts
...
> >   Something like display_select_font(FONT_5x8) to be called
> >   before a display_puts() sounds like a reasonable API for this.

the current API looks like this:

         fb_clear();

         fb_setfg(FB_COLOR_GREEN);
         fb_setbg(FB_COLOR_WHITE);
         fb_setfont(FB_FONT_HELVB14);

         fb_gotoxy(2,20);
         fb_putstr("Hello World!",framebuffer->width-4);

         fb_setfg(FB_COLOR_RED);
         fb_setbg(FB_COLOR_BLUE);

         fb_gotoxy(2,25);
         fb_boxto(framebuffer->width-3,38);

         fb_setfg(FB_COLOR_WHITE);
         fb_setfont(FB_FONT_5X8);
         fb_gotoxy(8,33);
         fb_putstr("osmocom-bb",framebuffer->width-4);

         fb_flush();

Which results in an output such as:

	http://vogel.cx/git/20101011_hello_world_c123.jpg
	http://vogel.cx/git/20101011_hello_world_c155.jpg


>  - If we want to support arbitrary sized fonts, we either should buffer
>    the display in RAM (might be wasteful on high res color displays?)
...

This patch keeps a image of the LCD in a RAM and only copies
"dirty" parts upon changes.

> >2) Removing all the special characters might not be the best idea to do.
> >   If at all, it should be a compile time option whether or not to drop
> >   the special characters.
> >   Also, the check for replacing a character with '?' needs to be
> >   a font-specific and not a global decision.

This patch currently encodes only #32..#127 to conserve space, but
it supports leaving out arbitrary characters. When the data is actually
put into ROM we can spare additional space on more glyphs and/or fonts.

I currently don't have commit access to the git-repo, so I couldn't
upload my vogelchr/framebuffer branch. Please have a look at the patch
you can download from http://vogel.cx/git/20101011_framebuffer.diff

It removes the old display code completely and replaces it with
the framebuffer, but currently only "hello world" makes use of it
by creating the image in the photographs linked above.

It should apply cleanly to today's master (11.Oct.2010) as it doesn't
touch anything where currently work is being done.

Please send me your comments on that patch.

Greetings from the Dillberg,

	Chris




More information about the baseband-devel mailing list