On Mon, 07 May 2001, "Tasnim Ahmed" wrote:
>
> Thats very good :)
> I got down to the bug in my keyboard stuff, I just used an array of 200 keys
> rather malloc and it stoped crashing, the segfault at exit was that I forgot
> to remove free(keymap); ;)
>
> Anyways so I'll remove the debug output and will try to use cvs with
> something else than login or co :)
> modified r3912ts.c
> adding genfitalyvkm.c
> adding genqwertyvkm.c
> Please tell me about make menuconfig so I can add it as a compile option
> under r3912 -> use NotSoVirtual Keyboard?
Okay. Here's an excerpt from the relevant section of config.in:
------8<------
mainmenu_option next_comment
comment 'Input Drivers'
bool 'SDL input driver' DRIVER_SDLINPUT
bool 'SVGAlib input driver' DRIVER_SVGAINPUT
bool 'Ncurses/GPM input driver (also for framebuffer)' DRIVER_NCURSESINPUT
bool 'uClinux m68k touchscreen input driver' DRIVER_TSINPUT
bool 'R3912 (VTech Helio) touchscreen input driver' DRIVER_R3912TS
if [ "$DRIVER_R3912TS" = "y" ]; then
bool ' Convert Helio silk-screen buttons' DRIVER_R3912TS_HELIOSS
fi
endmenu
------>8------
This should give you an idea of the format. Submenus are usually indented with
2 spaces within the single quotes. The conditionals are very shell-like, and you can
test for any of the other menu items.
Just add another menu item within the conditional, and have it define something
like DRIVER_R3912TS_KEYBOARD. Then test for it with #ifdef in the code.
Are the keyboard generators something that should be compiled separately, like the
theme compiler? You mentioned some concern over byte order. PicoGUI always stores 16
and 32 bit values in network byte order using the ntohs,ntohl,htons,and htonl
functions. You might want to do the same, this will make your keyboard format portable
to any architecture. I'm also trying to phase out things like 'unsigned long' in the
server in favor of 'u32'. Just something to keep in mind. Also sounds like your not
using dynamic allocation any more, but if you do you should use g_malloc() and
g_free(). g_free() works like free(). g_malloc() takes a pointer to a pointer variable
as its first parameter, size as the second, and returns a g_error. You can use it like
this:
g_error myfunction(void) {
char *buffer;
g_error e;
e = g_malloc((void**) &buffer, 1024);
errorcheck;
/* ... */
g_free(buffer);
return sucess;
}
I should probably put something about all this in the documentation :)
>
> -debugger
>
> ----- Original Message -----
> From: Micah Dowty <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, May 07, 2001 7:44 PM
> Subject: [Pgui-devel] Pico/Linux project starts
>
>
> > Just to let everyone who might be interested know, I started a sourceforge
> project for Pico/Linux at http://picolinux.sourceforge.net
> >
> > The main reason to put this in a separate project is that I didn't want to
> clutter up PicoGUI CVS with the binary files and such that the ROM images
> require, but I still want to get a nice build system for the Helio ROMs in
> CVS so Tasnim, Me, and anyone else who's interested can work on Pico/Linux
> more constructively.
> >
> > I'm still working on PicoGUI, but I'm a little backed up so sorry if it
> takes me a little while to answer your e-mail. It will get answered!
> >
> > --
> > To the systems programmer, users and applications server only to provide a
> > test load.
> >
> >
> > _______________________________________________
> > Pgui-devel mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/pgui-devel
> >
--
To the systems programmer, users and applications server only to provide a
test load.
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
