Re: Let's do something together in LinuxTag
Quim Gil schrieb: > Hi, > > ext Kees Jongenburger wrote: >> On Mon, May 12, 2008 at 11:05 AM, Simon Pickering >> <[EMAIL PROTECTED]> wrote: >>> > I have been thinking about what to present at linuxtag. I can not easely >>> > make a choice right now because we are lacking some form of "grand goal". >>> > Can we try to elaborate on the topics? perhaps also have an irc meeting >>> > between linuxtag contributors? >>> >>> Sounds useful, what about after the IRC meeting tomorrow evening? >> Hello Simon, >> >> Yes sounds fair. > > I will be there as well. :) Sorry, I could not attend. If there were substantial decisions made, could someone please summarize them and add them to the Linuxtag2008 wiki page? --Sebastian -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt4 hildonization.
Antonio Aloisio schrieb: > Menus doesn't seems a problem, the code seems too easy. > But i'm a bit confused on Input method. > I don't understand what i really need.. > I need to embed a Qt application in a Hildon app? You need to implement the application side of the InputMethod Framework which handles special X messages and forwards them the QT. This will be the qt equivalent to [5]. > > > > On 12/21/07, Sebastian Mancke <[EMAIL PROTECTED]> wrote: >> Hi Antonio, >> >> Antonio Aloisio schrieb: >>> I've found kkito, a kde developer that probably has got interesting >>> patches. But it's a old user, so it's unavailable. I'm trying to >>> contact him... >>> PS: Can i use Dbus to create Menus and to call/comunicate with >>> On-Screen keyboard? >>> (i don't know hildon well yet!) >> I'm working on an input method wrapper for java Swing. Since I'm using >> Swing with a gtk peer, it is somewhat simpler than your qt effort. Maybe >> you should take a look at [1] to get an idea of how it works normally/in >> my case. >> >> Text Input: >> For text input in hildon, a window has to communicate with the virtual >> keyboard using special X Messages. This protocol is not documented (or I >> can't find it). The best documentation I found is [2] (with some source >> code links [3]). Nokia has released the HildonInput Framework to go to >> the gnome upstream [4]. Since that step, the source code of the gtk-side >> X protocol implementation is available. The most interesting part for >> you should be in [5]. >> >> It would help a lot, if an ongoing implementation would start with a >> refactoring of the code in [5], to separate the protocol handling from >> the gtk logic and get one piece of code which could be used by all >> implementations. >> >> Menus: >> The hildon Menu implementation seems to be a simple pop up menu, which >> is displayed on the upper left corner. I think you have to reimplement >> this in qt in a similar way. >> >> --Sebastian >> >> [1] >> https://evolvis.org/plugins/scmsvn/viewcvs.php/trunk/maemo/hildon_swing_input/?root=jalimo >> [2] http://maemo.org/community/wiki/inputmethod/ >> [3] https://garage.maemo.org/snippet/detail.php?type=snippet&id=5 >> [4] http://live.gnome.org/Hildon/HildonInputMethod >> [5] >> https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-input-method-framework/src/hildon-im-context.c >> -- >> tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH >> >> Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin >> fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 >> fax: +49(228) / 52675-25| fax: +49(30) / 78709617 >> durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 >> >> Geschäftsführer: >> Boris Esser, Elmar Geese, Thomas Müller-Ackermann >> HRB AG Bonn 5168 >> Ust-ID: DE122264941 >> > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt4 hildonization.
Hi Antonio, Antonio Aloisio schrieb: > I've found kkito, a kde developer that probably has got interesting > patches. But it's a old user, so it's unavailable. I'm trying to > contact him... > PS: Can i use Dbus to create Menus and to call/comunicate with > On-Screen keyboard? > (i don't know hildon well yet!) I'm working on an input method wrapper for java Swing. Since I'm using Swing with a gtk peer, it is somewhat simpler than your qt effort. Maybe you should take a look at [1] to get an idea of how it works normally/in my case. Text Input: For text input in hildon, a window has to communicate with the virtual keyboard using special X Messages. This protocol is not documented (or I can't find it). The best documentation I found is [2] (with some source code links [3]). Nokia has released the HildonInput Framework to go to the gnome upstream [4]. Since that step, the source code of the gtk-side X protocol implementation is available. The most interesting part for you should be in [5]. It would help a lot, if an ongoing implementation would start with a refactoring of the code in [5], to separate the protocol handling from the gtk logic and get one piece of code which could be used by all implementations. Menus: The hildon Menu implementation seems to be a simple pop up menu, which is displayed on the upper left corner. I think you have to reimplement this in qt in a similar way. --Sebastian [1] https://evolvis.org/plugins/scmsvn/viewcvs.php/trunk/maemo/hildon_swing_input/?root=jalimo [2] http://maemo.org/community/wiki/inputmethod/ [3] https://garage.maemo.org/snippet/detail.php?type=snippet&id=5 [4] http://live.gnome.org/Hildon/HildonInputMethod [5] https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-input-method-framework/src/hildon-im-context.c -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: USB host mode on N800
Oh, I forgot to mention: The USB-Host is not enabled at startup automaticly. I have configured the following as init script. Regards, Sebastan #!/bin/sh # # This Script loads an usb file storage driver, which has the side # affect to correctly initialize the usb driver to listen for # connectoin of usb client or host devices # # by Sebastian Mancke, Tarent GmbH /usr/sbin/osso-usb-mass-storage-enable.sh if /usr/sbin/chroot /mnt/initfs cal-tool --get-rd-flags | grep -q master; then echo "host" > /sys/devices/platform/musb_hdrc/mode fi Sebastian Mancke schrieb: > Hi Dave, > > Dave Sullivan schrieb: >> On Friday 23 November 2007 4:20:00 am Sebastian Mancke wrote: >>> Hi. >>> >>> Kees Jongenburger schrieb: >>>> On Nov 22, 2007 5:58 PM, Dave Sullivan <[EMAIL PROTECTED]> wrote: >>>>> Hey All, >>>>> >>>>> I've got the modified kernel image for usb host mode, but before I go >>>>> ahead and try it, what kind of cable hacking is sufficient? I'd assume I >>>>> could just purchase a USB extension cord (A-type to A-type recepticle), >>>>> hack off the A-type and stick on a micro-USB connector.. but doesn't it >>>>> require external power? >>>> Hi >>>> >>>> I have measured the vbus voltage and it was only about 3 volt a >>>> opposed to what would be required (5 volt) (there is no active voltage >>>> pump). >>>> I guess you will often need an external power(if possible just buy >>>> yourself a usb gender changer >>>> and plug the tablet into a powerd hub). >>>> >>>> While the patches are available is have not hear of anybody getting >>>> the n800 to work in usb-host mode. >>>> can somebody confirm a working usb-host on n800 or n810 perhaps? >>> We are using the n800 usb-host mode in a productive project. >>> It works absolutely reliable. Smaller devices like an USB Keyboard or >>> the Silabs USB Serial converter (CP2102) can be used without additional >>> power supply. For bigger devices (external hard disc, USB-Network >>> adapter) you have to use a powered USB hub, of course. >>> >>> Regards, >>> Sebastian >>> >>>> greetings >>>> ___ >>>> maemo-developers mailing list >>>> maemo-developers@maemo.org >>>> https://lists.maemo.org/mailman/listinfo/maemo-developers >> I have a Nokia cell phone without bluetooth, but I also have a USB cable for >> it. When plugged into a Linux box, it can work as a modem. I was hoping to >> try and get this functionality working on the n800... I'd assume it'll take >> some hacking. So to confirm.. > Should work. > Maybe you have to enable the specific kernel modules needed for you > modem in the kernel configuration. > >> I can use the cable that comes with the n800 >> (USB-A to USB mini-A) and attach a USB-A gender changer to it? > Yes. But these USB gender changer are somewhat rare. > >> One more question... where/how would I get the stock kernel so that I can >> re-flash it if the usbhost kernel messes anything up? > The original fiasco image contains the kernel. You can unpack it and > flash the kernel. > > Regards, > Sebastian > >> Thanks! >> > > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: USB host mode on N800
Hi Dave, Dave Sullivan schrieb: > On Friday 23 November 2007 4:20:00 am Sebastian Mancke wrote: >> Hi. >> >> Kees Jongenburger schrieb: >>> On Nov 22, 2007 5:58 PM, Dave Sullivan <[EMAIL PROTECTED]> wrote: >>>> Hey All, >>>> >>>> I've got the modified kernel image for usb host mode, but before I go >>>> ahead and try it, what kind of cable hacking is sufficient? I'd assume I >>>> could just purchase a USB extension cord (A-type to A-type recepticle), >>>> hack off the A-type and stick on a micro-USB connector.. but doesn't it >>>> require external power? >>> Hi >>> >>> I have measured the vbus voltage and it was only about 3 volt a >>> opposed to what would be required (5 volt) (there is no active voltage >>> pump). >>> I guess you will often need an external power(if possible just buy >>> yourself a usb gender changer >>> and plug the tablet into a powerd hub). >>> >>> While the patches are available is have not hear of anybody getting >>> the n800 to work in usb-host mode. >>> can somebody confirm a working usb-host on n800 or n810 perhaps? >> We are using the n800 usb-host mode in a productive project. >> It works absolutely reliable. Smaller devices like an USB Keyboard or >> the Silabs USB Serial converter (CP2102) can be used without additional >> power supply. For bigger devices (external hard disc, USB-Network >> adapter) you have to use a powered USB hub, of course. >> >> Regards, >> Sebastian >> >>> greetings >>> ___ >>> maemo-developers mailing list >>> maemo-developers@maemo.org >>> https://lists.maemo.org/mailman/listinfo/maemo-developers > > I have a Nokia cell phone without bluetooth, but I also have a USB cable for > it. When plugged into a Linux box, it can work as a modem. I was hoping to > try and get this functionality working on the n800... I'd assume it'll take > some hacking. So to confirm.. Should work. Maybe you have to enable the specific kernel modules needed for you modem in the kernel configuration. > I can use the cable that comes with the n800 > (USB-A to USB mini-A) and attach a USB-A gender changer to it? Yes. But these USB gender changer are somewhat rare. > One more question... where/how would I get the stock kernel so that I can > re-flash it if the usbhost kernel messes anything up? The original fiasco image contains the kernel. You can unpack it and flash the kernel. Regards, Sebastian > > Thanks! > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: USB host mode on N800
Hi. Kees Jongenburger schrieb: > On Nov 22, 2007 5:58 PM, Dave Sullivan <[EMAIL PROTECTED]> wrote: >> Hey All, >> >> I've got the modified kernel image for usb host mode, but before I go ahead >> and try it, what kind of cable hacking is sufficient? I'd assume I could just >> purchase a USB extension cord (A-type to A-type recepticle), hack off the >> A-type and stick on a micro-USB connector.. but doesn't it require external >> power? > Hi > > I have measured the vbus voltage and it was only about 3 volt a > opposed to what would be required (5 volt) (there is no active voltage > pump). > I guess you will often need an external power(if possible just buy > yourself a usb gender changer > and plug the tablet into a powerd hub). > > While the patches are available is have not hear of anybody getting > the n800 to work in usb-host mode. > can somebody confirm a working usb-host on n800 or n810 perhaps? We are using the n800 usb-host mode in a productive project. It works absolutely reliable. Smaller devices like an USB Keyboard or the Silabs USB Serial converter (CP2102) can be used without additional power supply. For bigger devices (external hard disc, USB-Network adapter) you have to use a powered USB hub, of course. Regards, Sebastian > > greetings > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
State of Jalimo
Hi, I have just uploaded SWT 3.4 packages to the Jalimo [1] maemo3 repository, so I thought, it was time to give you a short update you about our progress. - The current stack for Os2007 is very stable. We have a well performing robust cacaojvm and and gnu classpath, which implements mostly all of Java 1.5, a normal application developer want's to see. - We have a complete toolchain (static x86 cacao, ecj, javah, javap) for usage within scratchbox. [2] - With the mvn-pkg-plugin [3] we provide a maven plugin which is able to build .deb and .ipk packages from normal java maven plugins. - We have SWT 3.4 [4] working, together with a small hildonizing mainly to get the SWT menu Bar attached as Hildon menu. SWT uses the native gtk peers and works very well!!! - We are still supporting java-gnome, which makes a good progress in the upstream [5] - For It2008 we have an OpenEmbedded configuration in our SVN, which produces binary compatible packages, so for the next Releases we can use OpenEmbedded as build system. Regards, Sebastian [1] http://www.jalimo.org [2] http://www.jalimo.org/wiki/doku.php?id=doc:howto:gettingstarted#java5_support_in_scratchbox [3] http://evolvis.org/projects/mvn-pkg-plugin/ [4] http://www.eclipse.org/swt/ [5] http://java-gnome.sourceforge.net/ -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ideas for Diablo and Elephanta: OpenEmbedded
Ok, I only saw the replacement approach in mamona and didn't know the the long term goal to align with maemo, Rodrigo told. This makes sense to me. [EMAIL PROTECTED] schrieb: > Mamona will be more useful and successful if it serves properly maemo > developers like Sebastian. I'm sure the INdT guys have this in mind. :) > > In terms of roadmapping for us > > maemo + OE = mamona > > INdT is doing pretty well with the development and I don't see a need > for us now to take part directly. Nor have we currently plans of > supporting officially mamona. > > In the meantime we have an official SDK based on Scratchbox, and we > prefer to concentrate energies in improving it. We are relatively happy > about it: it works and we use it ourselves. There are some things we > dislike and as for today we think that we can address them through > something like Scratchbox2 + System QEMU + Raemo + IDE plugins. > > "One development for many targets" is an important principle for us, not > always easy to apply. Usage of common components, versions and developer > tools across hardware vendors would help. We try to do the steps to > align as much as possible with the Linux desktop and the diverse mobile > variants based on GNOME/GTK+. > > Quim > >> No. When I understand mamona right, it is an approach to >> create a completely free distribution for the N800 (as >> replacement of maemo). >> The package selection seems to be based on Angstroem and it >> uses an upstream gcc4.1 with binutils2.17.50.0.5, at the moment [0]. >> >> While mamona is a very nice thing, it does not help to produce >> packages for maemo. For this we would need at least a binary >> compatible gnu toolchain in OE (mainly gcc, binutils, glibc). >> Of course, it would be nice to have the hildon libraries >> buildable there, too. Whereby the later one should be easy, I >> can't estimate the effort for the toolchain. > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ideas for Diablo and Elephanta: OpenEmbedded
Hi. [EMAIL PROTECTED] schrieb: > Hi Sebastian, > >> It would be >> great to have a working DISTRO configuration in OE which >> enables one to produce binary compatible packages. > > Is http://dev.openbossa.org/trac/mamona going in the direction you wish? No. When I understand mamona right, it is an approach to create a completely free distribution for the N800 (as replacement of maemo). The package selection seems to be based on Angstroem and it uses an upstream gcc4.1 with binutils2.17.50.0.5, at the moment [0]. While mamona is a very nice thing, it does not help to produce packages for maemo. For this we would need at least a binary compatible gnu toolchain in OE (mainly gcc, binutils, glibc). Of course, it would be nice to have the hildon libraries buildable there, too. Whereby the later one should be easy, I can't estimate the effort for the toolchain. --Sebastian [0] http://www.openembedded.org/repo/org.openembedded.dev/conf/distro/mamona.conf -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ideas for Diablo and Elephanta: OpenEmbedded
Marius Vollmer schrieb: > "ext Sebastian Mancke" <[EMAIL PROTECTED]> writes: > >> I would love to see support for OpenEmbedded. > > What would need to be changed on the maemo side to support > OpenEmbedded? Aren't you rather asking for maemo support in > OpenEmbedded? You are right, maybe this is the proper viewpoint. For maemo 3.2, I could not get a matching toolchain build in OpenEmbedded. I don't tried it with the new glibc, yet, but I assume, such a task would be best addressed by the people who know the toolchain, best. --Sebastian -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Ideas for Diablo and Elephanta: OpenEmbedded
Hi Quim, I would love to see support for OpenEmbedded. It would be great to have a working DISTRO configuration in OE which enables one to produce binary compatible packages. For people like us, who are maintaining software for several target platforms, OE is the best choice to do this. Furthermore, OpenEmbedded contains ~5000 packages, already, so this would be a chance to get some additional stuff for maemo. Regards, Sebastian Quim Gil schrieb: > Now that maemo Chinook approaches is a good time to define the features > to implement in the following releases of our SDK and development > platform: Diablo and Elephanta. Your suggestions are welcome. You can > file enhancement requests at bugs.maemo.org (preferred), send a proposal > to be discussed at maemo-developers or post a comment here. We are > looking specially for ideas that help improving our developer offer and > also coordinating better with Ubuntu Mobile and other projects in the > GNOME Mobile space. > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Java acceleration/Jazelle
Sebastian Mancke schrieb: > Hi Simon, > > sincerely I don't found the time to test your code yet. > >> Did you make a typo in your declaration (on p34) of int code[]? Should >> this not be unsigned char code[] as bytecodes are 1x byte not n x byte >> long (I'm assuming you're running on a machine with sizeof(int)>1)? > This is not a typo. I don't understand the reason, but it had only > worked with the integer array, not with bytes - don't know why. reasoning a minute, it sounds logical to me to have an int array, since normal arm instructions are 32bit long. So stretching the byte code to 4byte, the instructions and pc can internaly be handled as in normal arm operation mode. > > --Sebastian > > Simon Pickering schrieb: >> Hi all, >> >> Sebastian, in this link: >> >>> You can find a small example in my jalimo slides from linuxtag2007 >>> (slide 33ff). >>> >>> http://www.jalimo.org/wiki/doku.php?id=news:linuxtag2007 >> (direct link: >> http://www.jalimo.org/documents/jalimo-slides_english_linuxtag2007.pdf) >> >> Did you make a typo in your declaration (on p34) of int code[]? Should this >> not >> be unsigned char code[] as bytecodes are 1x byte not n x byte long (I'm >> assuming >> you're running on a machine with sizeof(int)>1)? Just wondering if this is a >> typo when you were writing the presentation or whether it might have affected >> your results. On the other hand it may be my misunderstanding the >> declaration. >> >>> It might be possible to test at least some aspects of my 'new improved' >>> theory. The one that comes to mind is to try a BXJ to an unhandled Java >>> instruction immediately. This should then branch back to whatever ARM >>> code is at R12 straight away (not needing to know the pointer table >>> base address). This could prove a number of things, including >>> the stack pointer, R12 & R14 contents, etc. >> I've written a piece of test code, but not tested it yet (no compiler here at >> work). I must admit that I've only learned extended inline asm this week, so >> it >> may not work correctly ;). If anyone spots any mistakes, please let me know. >> >> http://people.bath.ac.uk/enpsgp/nokia770/jazelle/test_jazelle.c >> http://people.bath.ac.uk/enpsgp/nokia770/jazelle/to_compile_do_this.txt >> >> I'll post some results tomorrow/later on, one way or the other. >> >> Cheers, >> >> >> Si >> > > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Java acceleration/Jazelle
Hi Simon, sincerely I don't found the time to test your code yet. > Did you make a typo in your declaration (on p34) of int code[]? Should > this not be unsigned char code[] as bytecodes are 1x byte not n x byte > long (I'm assuming you're running on a machine with sizeof(int)>1)? This is not a typo. I don't understand the reason, but it had only worked with the integer array, not with bytes - don't know why. --Sebastian Simon Pickering schrieb: > Hi all, > > Sebastian, in this link: > >> You can find a small example in my jalimo slides from linuxtag2007 >> (slide 33ff). >> >> http://www.jalimo.org/wiki/doku.php?id=news:linuxtag2007 > > (direct link: > http://www.jalimo.org/documents/jalimo-slides_english_linuxtag2007.pdf) > > Did you make a typo in your declaration (on p34) of int code[]? Should this > not > be unsigned char code[] as bytecodes are 1x byte not n x byte long (I'm > assuming > you're running on a machine with sizeof(int)>1)? Just wondering if this is a > typo when you were writing the presentation or whether it might have affected > your results. On the other hand it may be my misunderstanding the declaration. > >> It might be possible to test at least some aspects of my 'new improved' >> theory. The one that comes to mind is to try a BXJ to an unhandled Java >> instruction immediately. This should then branch back to whatever ARM >> code is at R12 straight away (not needing to know the pointer table >> base address). This could prove a number of things, including >> the stack pointer, R12 & R14 contents, etc. > > I've written a piece of test code, but not tested it yet (no compiler here at > work). I must admit that I've only learned extended inline asm this week, so > it > may not work correctly ;). If anyone spots any mistakes, please let me know. > > http://people.bath.ac.uk/enpsgp/nokia770/jazelle/test_jazelle.c > http://people.bath.ac.uk/enpsgp/nokia770/jazelle/to_compile_do_this.txt > > I'll post some results tomorrow/later on, one way or the other. > > Cheers, > > > Si > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Java acceleration/Jazelle
Hi Simon, nice research !!! This seams easier (and more os independent) than my thoughts with an interrupt in kernel mode. Although we can not say for sure, that Jazelle is implemented the way, the patent describes, this is a very good point to get a forthcome. Regards, Sebastian Simon Pickering schrieb: > Hi all, > > If this is all already known please let me know and I'll stop waffling, > but some Googling couldn't find anything, so I'll present what I've > found thus far. > >> I had a look around for some more information and found the patent >> for Jazelle: US patent number 7089539. > >> Google link here (with figures, which makes understanding it far >> easier): http://www.google.com/patents?id=iMt6EBAJ&dq=7089539 > > I've finally got round to reading all of the patent in question. > > I've changed my mind about exception handlers (see my previous posts > with the same subject line). I believe that the processor internally > handles any exception caused by an unrecognised Java bytecode, and (and > this is where a bit of interpretation/reading between the lines comes > in) automatically switches to ARM mode and jumps to an address > specified in a pointer table provided by the application running the > JVM (i.e. us). > > If you look at Fig.4 in the patent, for example, you can see a snippet > of code. This is one of the chunks of code that would be jumped to > (pointed to by the pointer table, which will be 256 pointers long, one > for each bytecode) and implements the iadd bytecode. > > I've repeated the code fragment below with comments above each line: > > /* increment bytecode pointer (R14) and load value pointed to by R14 into R4. > This is performed so that we have the bytecode value of the *next* > bytecode > (i.e. not the one that couldn't be handled) in R4. We move the Java > 'program counter' register, R14, along by one before we do this (in fact > it > does R4=*(R14+1) then R14=R14+1, but same in the end). */ > LDRB R4, [R14, #1]! > /* decrement Rstack by 4, then pop first operand from stack into R1 > This is part of handling the actual instruction, in this case an > iadd, so we > need to pop the values from the stack */ > LDR R1,[Rstack, #-4]! > /* decrement Rstack by 4, then pop first operand from stack into R0 > As above */ > LDR R0,[Rstack, #-4]! > /* Get address of next code fragment for next bytecode > load into R12 the value from Rexc + (R4 x 2^2). > In this step we look into the pointer table (which contains pointers to > ARM code fragments that handle each Java bytecode) and we load the address > of the code fragment for the next Java instruction (not the one we're > currently handling) which we loaded into R4 on the first line */ > LDR R12,[Rexc, R4, LSL #2] > /* R0 = R0 + R1 > Here we simply perform the add operation that this code fragment is > handling*/ > ADD R0,R0,R1 > /* Store R0 in Rstack and increment Rstack by 4 (pre or post? post probably) > Here we save the results of the add operation that we're handling in this > code snippet*/ > STR R0,[Rstack],#4 > /* Branch to Java > This command takes as its operand the address of the ARM software snippet > used to handled the bytecode. Not (it would appear) the address of the > Java > bytecode to execute. The address of the bytecode should be in R14. The > Jazelle hardware decides whether Jazelle is present and enabled and > chooses > whether to jump to the bytecode and enter Java mode, or to stay in ARM > mode > and 'emulate' the instruction */ > BXJ R12 > > Note that the actual implementation of the iadd instruction (popping > twice, adding then pushing) is mixed in with the preparations to handle > the next bytecode/re-enter Java mode. Afaiu, this is done to make the > code more efficient and avoid stalls. > > So you can see that the code has already worked out where it needs to > jump to in either Java or ARM 'emulation' mode (the latter is done to > speed up processing should Jazelle be disabled or the bytecode be > another one that's not handled by the hardware). > > One curious point about this code is that I was under the impression > that the stack was held in registers [1], rather than at some address > as is indicated by the pop instructions. It may be that the Jazelle > hardware does in fact hold the top stack elements in registers and > flushes them to memory when the unrecognised Java bytecode exception is > caused. The question then is which register actually holds this memory > address (ie. Rstack in the code above)? The same article says that R6 > holds the stack pointer, so perhaps this is used...? > > The other register that needs to be determined is Rexc, which is the > one that points to the base of the pointer table which contains the > pointers to the ARM code snippets. But it looks like accesses to this > table are only handled in the ARM snippets (which 'we' woul
Re: 770 Java HW Acceleration (and JVM support)
I have filled a Bug against the missing support of the Jazelle specifications for the hardware: https://bugs.maemo.org/show_bug.cgi?id=1599 Sebastian Frantisek Dufka schrieb: > Sebastian Mancke wrote: > >> You can find a small example in my jalimo slides from linuxtag2007 >> (slide 33ff). >> >> http://www.jalimo.org/wiki/doku.php?id=news:linuxtag2007 > > Yes, that was it, thanks. I've seen the pdf version > http://www.jalimo.org/documents/jalimo-slides_english_linuxtag2007.pdf > >> >> To use the jazelle extension, we would need *much* more knowledge >> about it. >> > > Yes, definitely. But still this shows a way and someone can start > playing with it. > > Frantisek > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 770 Java HW Acceleration (and JVM support)
Frantisek Dufka schrieb: > Jason Mills wrote: >> ...and before I forget it... these two links are very tempting: >> >> http://wiki.java.net/bin/view/Mobileandembedded/PhoneMEAdvancedPlatformsNokia >> 770 >> >> http://wiki.java.net/bin/view/Mobileandembedded/PhoneMEAdvancedPlatformsNokia >> 800 > > Can't find it now but there is some beginning of jazelle reverse > engineering effort documented somewhere (maemo wiki?). Nothing big, just > switching CPU to java mode and back but still this is one option for > future. Official jazelle support would be closed and shipped with some > proprietary JVM anyway which is not very interesting. You can find a small example in my jalimo slides from linuxtag2007 (slide 33ff). http://www.jalimo.org/wiki/doku.php?id=news:linuxtag2007 To use the jazelle extension, we would need *much* more knowledge about it. -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Sorry for bother
Hi, java applets depend on AWT, which depends on gtk2.10 for us. So it will be available with maemo4. As Antonio mentioned, we are active with JaLiMo, to bring java to maemo. And much things are already working from a developer point of view (see our updated screenshots). But it will take some months, until this will be easy usable for an ordinary Java developer, like those python stuff is today. Feel free to ask java-related questions on the jalimo mailing list. -- Sebastian Antonio Orlando schrieb: > It seems you are interested in having Java working on N800. There's no > way, by now, for you to have a Java app running on that platform. They're > working on Jalimo, so something's moving towards that direction, but it > isn't usable and probably it won't in a short time as you could hope to > boost your project. > > I can suggest better exploring Python and searching for existing Python > apps equivalent to the Java ones you are interested in. If your field of > interest is scientific or related, have a look in scipy.org > > Hope it helps > > -- > Antonio > > >> Maybe I posted not very smart questions, but in fact, >> I'm on a project on the Nokia N800, and there is no >> one who can help me, with the most evident questions, >> and it's so hard for people to understand, that I'm >> searching many issues to my problems, throught diverse >> directions, and I'm not posting that, only for fun, or >> without searching issues on google, like some people >> thought. >> Very, very sorry, that I bother so much the >> maemo-developers list. >> But, many of my questions, can be just a start point >> for a development ideas, for another purpose than >> mine. >> >> Best regards, >> Magda, > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Linuxtag2007 - JaLiMo Slides online
Hi, I've uploaded my slides and some pictures of the JaLiMo Linuxtag talk. http://www.jalimo.org/wiki/doku.php?id=news:linuxtag2007 Regards, Sebastian -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: JaLiMo
Hi, thanks, this way works fine! Regards, Sebastian Antti Ijäs schrieb: > Hi, > > No key-press (or release) events are produced by the virtual keyboard to > the main window, so no wonder you're not getting them ;) The keyboard > itself is a standalone process with it's own window (AFAIK). > > But, the text is committed to the entry through the IMContext API. My > suggestions for you would be to create an instance of a > GtkIMMultiContext and take the text from there using semi-standard > IMContext API. At least you should: > > 1) gtk_im_context_set_client_window(im_context, > this_can_probably_be_your_gtkwindow) > > 2) connect to the "commit" and "preedit-changed" signals > > 3) then do gtk_im_context_focus_in() and/or gtk_im_context_show() > > 4) on "preedit-changed" call for gtk_im_context_get_preedit_string() > > 5) also give a try on gtk_im_context_hide() and/or > gtk_im_context_focus_out() > > Hope this helps :) > > / Antti > > Sebastian Mancke wrote: >> Hi, >> >> Eero Tamminen schrieb: >>>> Additionally to this, we have played around with midpath, a J2ME >>>> implementation. Guillaume Legris from midpath wrote a gtk backend, for >>>> it. Currently this effort hangs, because I don't get the key events from >>>> the hildon/gtk libraries of the soft keyboard. >>> Have you disabled the automatic Hildon IM Gtk plugin loading somehow? >> Not that I know. To get the input in an GtkEntry works, for example. >> But on an input with the soft keyboard, no 'key-press-event' on the >> GtkWindows is raised. (The hardware 5-key button raises the instead.) >> >> For the midpath backend, I have only a GtkWindow with a GtkDrawingArea >> in it. I have to get the key events to push them back to the java code. >> >> At https://garage.maemo.org/snippet/browse.php?by=cat&cat=12 >> there is a snipped, to get the raw xlient messages >> (_HILDON_IM_INSERT_UTF8) and create X events from their payload. But >> isn't there a better solution within gtk? >> >>> All normally launched Gtk applications in the device should get it >>> automatically: >>> # pid=$(pidof maemo_af_desktop|cut -d' ' -f1) >>> # grep hildon-im /proc/$pid/maps >>> 4158-41587000 r-xp 1f:04 2473 >>> /usr/lib/gtk-2.0/2.4.0/immodules/hildon-im-module.so >> My result is: >> 41094000-4109a000 r-xp 1f:04 1989 >> /usr/lib/gtk-2.0/2.4.0/immodules/hildon-im-module.so >> 4109a000-410a1000 ---p 6000 1f:04 1989 >> /usr/lib/gtk-2.0/2.4.0/immodules/hildon-im-module.so >> 410a1000-410a2000 rw-p 5000 1f:04 1989 >> /usr/lib/gtk-2.0/2.4.0/immodules/hildon-im-module.so >> >> Regards, >> Sebastian >> > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: JaLiMo
Hi, Eero Tamminen schrieb: >> Additionally to this, we have played around with midpath, a J2ME >> implementation. Guillaume Legris from midpath wrote a gtk backend, for >> it. Currently this effort hangs, because I don't get the key events from >> the hildon/gtk libraries of the soft keyboard. > > Have you disabled the automatic Hildon IM Gtk plugin loading somehow? Not that I know. To get the input in an GtkEntry works, for example. But on an input with the soft keyboard, no 'key-press-event' on the GtkWindows is raised. (The hardware 5-key button raises the instead.) For the midpath backend, I have only a GtkWindow with a GtkDrawingArea in it. I have to get the key events to push them back to the java code. At https://garage.maemo.org/snippet/browse.php?by=cat&cat=12 there is a snipped, to get the raw xlient messages (_HILDON_IM_INSERT_UTF8) and create X events from their payload. But isn't there a better solution within gtk? > > All normally launched Gtk applications in the device should get it > automatically: > # pid=$(pidof maemo_af_desktop|cut -d' ' -f1) > # grep hildon-im /proc/$pid/maps > 4158-41587000 r-xp 1f:04 2473 > /usr/lib/gtk-2.0/2.4.0/immodules/hildon-im-module.so My result is: 41094000-4109a000 r-xp 1f:04 1989 /usr/lib/gtk-2.0/2.4.0/immodules/hildon-im-module.so 4109a000-410a1000 ---p 6000 1f:04 1989 /usr/lib/gtk-2.0/2.4.0/immodules/hildon-im-module.so 410a1000-410a2000 rw-p 5000 1f:04 1989 /usr/lib/gtk-2.0/2.4.0/immodules/hildon-im-module.so Regards, Sebastian -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
JaLiMo
Hi, some time ago, I already announced some of our ideas about Java on maemo. Now we are on a state, where the basic things work (v0.1). So I would report it here. Everything may be obtained at: http://www.jalimo.org We have debian packages of - classpath 0.93, 0.95 - latest cacao - jamvm 1.4.5 - java-gnome 4.0.2 - rxtx 2.1-7 We have a maven packaging plugin, which is able to produce .deb packages including the artefact's and native libraries. The biggest issues are: - jar loading problem in jamvm - missing swing/awt support - to few widgets in java-gnome Additionally to this, we have played around with midpath, a J2ME implementation. Guillaume Legris from midpath wrote a gtk backend, for it. Currently this effort hangs, because I don't get the key events from the hildon/gtk libraries of the soft keyboard. To improve the the gui support, we try to extend java-gnome with some more widgets. At the other hand, we are working to get swing supported. for which we see two possibilities: 1. Direct pure java X connection backend (lib escher) 2. Using the gtk 2.10 from sardine So, from now on, JaLiMo starts to be usable for you! Regards, Sebastian -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Key events on GtkWindow
Hi, what do I have to do, to get all key events of an GtkWindow in maemo? With the following code I raise up a blank window and the soft-keyboard. But neither the 'key-press-event' nor the 'commit' seems to produce any events. On my host machine, the 'key-press-event' works fine. Regards, Sebastian window = HILDON_WINDOW(hildon_window_new()); gtk_signal_connect (GTK_OBJECT (window), "key-press-event", GTK_SIGNAL_FUNC(key_event), NULL); .. im_context = gtk_im_multicontext_new(); gtk_im_context_set_client_window(im_context, (GdkWindow *)window); g_signal_connect (im_context, "commit", G_CALLBACK (commit_text), window); gtk_im_context_reset (im_context); hildon_gtk_im_context_show(im_context); -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Cross compiling under debian
Hi,
compiling my packages with Java-JNI-code (e.g. classpath) for maemo does
not work out of the box, because scratchbox does not have all the
required build tools (javac, javah, jar). My long-term goal would be to
use openembedded, but this will need much work, I think.
So, at the moment I cross compile from my x86 debian, which seems to
work fine except of the following problems with the debian packaging:
1. dh_strip -a (from x86) does not know, how to handle the arm binaries.
(I have disabled it with: DEB_BUILD_OPTIONS=nostrip)
2. dh_shlibdeps does not work, because the ldd (from the toolchain)
tries to use ld-linux.so.3 from my host instead from the rootstrap.
/home/asteban/maemo/toolchain/scratchbox/compilers/arm-linux-2006q3-27/arm-none-linux-gnueabi/libc/usr/bin/ldd:
line 166: /lib/ld-linux.so.3: No such file or directory
3. dpkg-architecture does not know 'arml'
It would be possible to hack a fix in the script, like the one in
scratchbox:
sub debian_arch_fix
{
local ($os, $cpu) = @_;
...
} elsif ("$os-$cpu" eq "gnueabi-linux-arm") {
return "armel";
...
}
The problem 2. is my biggest one. Any suggestions? Cleaner solutions?
My setup is as follows:
TOOLCHAIN=~/maemo/toolchain/scratchbox
ROOTSTRAP=~/maemo/toolchain/rootstrap
export
PATH=$TOOLCHAIN/compilers/arm-linux-2006q3-27/bin/:$TOOLCHAIN/compilers/arm-linux-2006q3-27/arm-none-linux-gnueabi/libc/usr/bin/:$PATH
export CC=`which arm-none-linux-gnueabi-gcc`
export LD=`which arm-none-linux-gnueabi-ld`
export AR=`which arm-none-linux-gnueabi-ar`
export PKG_CONFIG_PATH=$ROOTSTRAP/usr/lib/pkgconfig/
alias pkg-config='pkg-config --define-variable=prefix=$ROOTSTRAP/usr'
# no a nice soution
export DEB_BUILD_OPTIONS=nostrip
Then I simply run 'fakeroot dpkg-buildpackage -d'
Regards,
Sebastian
--
tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH
Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin
fon: +49(228) / 52675-0 | fon: +49(30) / 27594853
fax: +49(228) / 52675-25| fax: +49(30) / 78709617
durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249
Geschäftsführer:
Boris Esser, Elmar Geese, Thomas Müller-Ackermann
HRB AG Bonn 5168
Ust-ID: DE122264941
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Language bindings and priorities
Hi, my interest is also in Java language bindings. As I mentioned before, we have started JaLiMo [1] therefore and since a week, the time to work on JaLiMo grows. So maybe its time to start sharing the ideas. It seems to me, that Johannes and I have a similar understanding, of the problems with Java on small Linux devices: The basic JVM is a first step, but we have to target the problems beyond that, which is the integration with the desktop and the system environment. I like those hildon and osso ideas but I don't want to stick with a library only available in *one* linux distribution. When I do that work for maemo today, I don't want to start from scratch on openmoko or distribution xyz some time later. That's why I don't want to have JaLiMo on garage.maemo.org for example. I would like to identify the basic concepts and build an interface based API above them, as it was the idea in Java from the beginning on. The required concepts I see at the moment are: - messaging between applications - having a *gui program* with + title and icon + menu entrie + different actions (e.g. menu entries) in different container (e.g. menu, toolbar or system tray) - having something like a system tray - control of instantiation and runtime of applications - and (maybe) build the gui resting upon a gui description file I think, all of this can used without knowing the currently used GUI library and implementation peer. (If someone is interested in it, I will publish my early API drafts on [1]) Along with this API requirements I see the following: - Running all java applications in one jvm process - compiling and packaging applications from the preferred Java development/build environments (e.g. maven, eclipse, ...) - simple cross compilation of JNI projects As you know, I have started with cacao/jamvm, classpath and java-gnome, but would love to see all other alternatives (e.g. PhoneME, (e)SWT, Swing, ..) as well. Java-gnome was my choice because it seems to be near to maemo, opmenmoko and GPE and it is very lightweight. If I had to come to a production quality environment for a huge project in an short time, I maybe would consider using eSWT, like others do in a similar environment. (e.g. IBM J9 [2] and AONIX Perc [3]) Again, this is a reason for me to encapsulate the above concepts in an API beside the GUI Library. This would give us the possibility to introduce additional gui libraries and reuse the work done before. Regards, Sebastian [1] http://www.mancke-software.de/jalimo/ [2] http://www-306.ibm.com/software/wireless/weme/ [3] http://www.aonix.com/perc.html Johannes Eickhold schrieb: > On Tue, 2007-04-10 at 16:20 +0300, [EMAIL PROTECTED] wrote: > > Hi Jukka-Pekka, > >> I'm collecting developer feedback regarding language binding needs on >> maemo. Hildon and other APIs need bindings in order to have native >> support in languages other than C. > > See my comments inline. This topic partly interfers with the "Java > language bindings" proposal for Google SoC by Clemens Eisserer for which > I applied as mentor. > >> Currently there exists unofficial bindings for C++, for example, and >> bindings for Python. So the question is what bindings do you need for >> your development, > > Bindings for hildon (GUI) and d-bus (communication with system services) > + other Gnome related APIs would be needed for decent java support in > maemo. > >> for what language, > > Java. > >> and why (if not obvious)? > > A tight integration (i.e. UI is not distinguishable from the UI of a C > +hildon application while still as powerfull) of Java into maemo is > still missing. General support for the Java language is already in place > (as reported previously on this list). > > Currently Java has different APIs for UI programming. None of them > directly fits with hildon. Among the most widely used are: > > 1. Swing (Java's own UI toolkit) [1] > 2. SWT (based on GTK) [2] > 3. AWT (Java's old own UI toolkit) [3] > 4. java-gnome (bindings for GTK) [4] > > IMO one of these should serve as a starting point for any "java-hildon" > binding activity. > > Greets, > Jonek. > > [1] > http://java.sun.com/javase/6/docs/api/index.html?javax/swing/package-summary.html > [2] http://www.eclipse.org/swt/ > [3] > http://java.sun.com/javase/6/docs/api/index.html?java/awt/package-summary.html > [4] http://java-gnome.sourceforge.net/ > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___
Re: JNI on scratchbox
Hi magda, magda chelly schrieb: > Hello everybody!! > > Have someone an idea how to do an application that use > JNI in scratchbox? JNI consists of two parts: 1. The native code (e.g. with the generated header file generated by javah): This code has no java dependencies (only the jni.h has to be present). It should be compileable in scratchbox like any other c code. 2. The java code: This code has no compile-time dependencies to the native code. Simple compile it like usual pure java code. During runtime of course you need to put both together. --Sebastian > > Thanks, > Magda, > > > > > > > ___ > Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! > Profitez des connaissances, des opinions et des expériences des internautes > sur Yahoo! Questions/Réponses > http://fr.answers.yahoo.com > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [Java] Mentor wanted for Summer of Code 2007 ;)
Hi, Johannes Eickhold schrieb: > On Mon, 2007-03-05 at 20:26 +0100, Clemens Eisserer wrote: >> I wonder wether anybody would be willed to mentor me at Google's >> Summer of Code 2007. > > Hi Clemens, > > I would like to support your effort as a mentor. But currently I don't > know what is needed to be accepted as a mentor and what the process to > apply as a mentor would be. If anybody on this list is able to clarify > the situation, please feel free to do so! > > Would it make sense to ask on sun's Java phoneME forum for support and > possibly another mentor, too? > > I'm also interested in broader feedback and opinions from the list about > Java integration into maemo. Me too. Based on time, the really work on JaLiMo will start in April, so this month may be the right time for ideas and wishes. > It seems at least three possibilities are > currently considered by different people. > > 1. jamvm + classpath > 2. cacaovm + classpath + java-gnome (jalimo by Sebastian Mancke) > 3. sun's phoneME advanced well, we should try to integrate any efforts. 1. vs. 2. Between 1. an 2., IMO there is no big difference. The jamvm also runs out of the box with the JaLiMo libraries. cacao is 3 times faster than the jamvm, but has a 2.5 sec longer start up time. The classpath version in 1. is 0.91, matching the gtk libraries of maemo. I, for now, have tried to get the recent versions running, with the lack of AWT. I think java-gnome is the way to do java gui's on this small linux devices, because it is really fast and offers the opportunity to integrate with special gui extensions (e.g. hildon on maemo or libmokoui on openmoko). But this may be my special taste and will be exchangeable, if someone has a different task to solve. The difference from JaLiMo to 1. is that we try not only to build some packages once. We have the goal to let a platform evolve, beyond the runtime, which solves recurring problems every java developer hit when he/she targets an linux embedded platform. Before n770, I did java on Yopy and IPAQ/familiar with the same problems: - Get a fast GUI working - Desktop integration - Packaging - menu integration - Configuration integration - Connectivity to back-end-services So we are trying to: Integrate once, write once, run on every mobile linux device. 2. vs. 3. In 3., I see two very different conceptual approaches: - J2ME CDC (Minimal Java, no reflection, no JNI, MIDP 2.0) This one is different to JaLiMo. - J2ME CLDC (Java 1.3.1, AWT) This second one has the same objective, but a completely other solution. You should take a look at MIDPath (http://midpath.thenesis.org), which already has a running MIDP (based on phoneME) on top of GNU Classpath, Cacao, Kaffe and JamVM with different back end libraries. MIDPath would perfectly fit with JaLiMo since it uses the same runtime. -Sebastian -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Asking for information about programming in JAVA at Nokia device
Hello Magda, we have recently started a project with the aim to maintain a full featured free java stack for mobile linux devices, called JaLiMo. The goal is to package and tailor existing jvm-related projects, as well as develop APIs for easy integration with the target platforms. Since we have recently started, our mailing list and Web-Site will be available in a few weeks. Currently we have managed to get the recent cacaojvm (see www.cacaojvm.org), gnu classpath 0.93 (see www.classpath.org) and java-gnome 4.0.2 running on the n770. http://www.mancke-software.de/jalimo/screenshot_java-gnome.png Since our state is experimental at the moment, we have no official packages now, but you can grab some simple tar.gz archives from http://www.mancke-software.de/jalimo/. (unpack to /usr/local/ and get in touch, if you have problems with them.) They are only tested with n770, I don't know, if they are running with your n800. There is also a classpath 0.91, together with a jamvm available out there. (http://www.internettablettalk.com/forums/showthread.php?t=2896) This 0.91 has a working Swing/AWT which will be hard to get running for later classpath versions, because it needs a newer gtk. Both, the jamvm and the cacao seem to work fine. The cacaojvm (JIT) is approx. 2-3 times faster than the jamvm, but has a huge start up time (~3 sec, instead of 0.7 sec). What is the project, you are focussing on? Regards, Sebastian magda chelly schrieb: > Hello, > > I'm a student beginnig to program with a Nokia N800, > and I'm in search for some information. I would be > gratefull if you could help me a little. > In fact, I have a problem, it's that the Nokia > N800 does not support JAVA and I must program with > that > language. You know something about that? What must > I install to make my program runs on that? Which > virtual > machine work on that, or maybe there is somewhere > a virtual machine that work on NOKIA 770. I > I'm very sorry to disturb you with my questions. > > Yours faithfully, > Magda, > > > > > > > ___ > Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! > Profitez des connaissances, des opinions et des expériences des internautes > sur Yahoo! Questions/Réponses > http://fr.answers.yahoo.com > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://maemo.org/mailman/listinfo/maemo-developers > -- tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin fon: +49(228) / 52675-0 | fon: +49(30) / 27594853 fax: +49(228) / 52675-25| fax: +49(30) / 78709617 durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249 Geschäftsführer: Boris Esser, Elmar Geese, Thomas Müller-Ackermann HRB AG Bonn 5168 Ust-ID: DE122264941 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
