{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.
> 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.jpghttp://vogel.cx/git/20101011_hello_world_c155.jpg
>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