Thanks for the answer... Was this resolved? > The crash... As I was explaining in my second email, it was due to the fact that sdl could not set the 640x480 resolution (openmoko expects the opposite 480x540). This was screwing up some locking, that you maybe better should check.... After setting the correct resolution, the app is taking the "normal" path and is not crashing..
> > > > 2. it is not straightforward to crosscompile... The build system is > also a > > > bit strange.. Why don't you use standard autotools... > > You should be able to cross-compile using the standard method of setting > the environment variables $CC, etc. to use your toolchain. What problems > are you having specifically? > Well... > > The build system we are using is called BSDBuild; it is documented at: > http://bsdbuild.hypertriton.com/. It is based on the 4.4BSD build system > so it will certainly seem strange to people used to working on a GNU-style > environment, but it has many advantages over autotools. > Ok, I see... did not realize. > > > > 3. make -j does not work properly... it seams that you launch a make > > > process for each file, that makes make from root quite slow if only one > file > > > need to be rebuild > > This only occurs if you build in the source directory itself. For best > performance, try building from an external directory (see "Concurrent > building" in INSTALL). > ah, will try that.. However as I have seen the Makefile there is o for loop inside that "blocks" the automanagement powers of the makefile... If that is the default for BSD, it is bit disappointing. > > > > the rest is the best.. I mean framework is quite promissing, intending > to > > > use it for at least for proof of concept for the unfamous openmoko > > > freerunner device > > Cool. I'm glad to hear that these are still around. If somebody wants to > donate a device, I'd be glad to work on a supported port. > well.... if you want to do it for yourself, you can find now the device very cheap openmoko.com , do not think anybody would donate it, unfortunatelly. > > > i found the reason in agare < 1.4, one could pass the size of the video > to > > AG_InitGraphics, but with redesign that opportunity is gone.. > > AG_InitGraphics (spec=0x0) at gui.c:364 tries to set it to a > > not-by-all-cards-supported-640x480 value and that makes the init fail.... > > You can still use AG_InitVideo() instead of AG_InitGraphics() and pass an > explicit geometry. AG_InitVideo() will only select among sdlfb and sdlgl. > The solution I was proposing would make the examples warking out of box. So at the moment cannot make too much progress, as the openmoko kernel has a bug, and blocks when sdl does ioctl wait for keyboard etc. I would have another question: what is the best way to do "zoom" on the fly, that is to increase font of the full interface "on demand". on such a small screen sometimes makes sense to work with stylus, but often would make sense to increase font as much, as could be controled with finger. etc. -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com
_______________________________________________ Agar mailing list [email protected] http://libagar.org/lists.html
