Re: MeeGo
Jan Knutar a écrit : On Thursday 18 February 2010, Jean-Christian de Rivaz wrote: basically 3 messages: 1) Maemo is no more. Even if it may survive for a last release. 2) The Maemo resulting work is now controlled officially by the Linux Fundation, but the real power are in the Intel hands. I suspect the reality will be more in the lines of meego being both an upstream for Intel, Nokia and whoever, and a LSB-like spec for application interoperability on different systems. Possible. If this is what there expect, then there need to be quickly a major Linux distribution with width acceptance. Not impossible, but a very hug task ! This remind me the day when UNIX was more and more fragmented to the point every player lose. I think there is a limit into the number of major Linux distribution that can share the big part of the cake. Regards, Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
Christopher Intemann a écrit : My analysis is that the use of QT on Symbian and MeeGo will allow Intel to use the applications from Nokia and vice versa. So I don't see a need from Nokia to supply a Linux product line anymore. Why wouldn't they? Mobile phones are gaining more and more power, and will eventually merge with the netbook products. Yes, you a right. I also expect the two markets to merge. But the actual signal coming from Nokia do not say that. First, the only clear project Nokia have to be ready for the merge, Maemo, is now outside Nokia. Second, there have yet announced nothing that can possibly be a roadmap to be ready for that merged market. For me, Maemo was a such roadmap. The current Symbian roadmap is a fight against actual concurrents, not a way to merge the market. It could be feasible that future N-Series devices will rather utilize Intel Atom chipsets - which would, however, not be the worst IMHO. It can't be the Atom chipsets, really. The power envelop is an order to high. Even the Moorestown can't match the current ARM SoC. And next ARM SoC will be even better. I don't say that Intel can't product in the future a chip that match the next ARM Soc, but this will take some time to do so. Regards, Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
Yves-Alexis Perez a écrit : On mer., 2010-02-17 at 22:49 +, Carlos Morgado wrote: Honestly, I'll won't even bother with MeeGo 'till I see products and a decent roadmap. Meanwhile Nokia must just change it's mind, buy some GUI toolkit in Java and decide that's the way to go, go back to Symbian or just fold. Nobody knows. You might have missed the part where the first Meego phone won't be a Nokia. I wonder if Nokia have made Maemo precisely to allow Intel to enter the mobile computer (aka smartphone) business. The ofono project was already a step in that direction. Now Nokia at the MWC send basically 3 messages: 1) Maemo is no more. Even if it may survive for a last release. 2) The Maemo resulting work is now controlled officially by the Linux Fundation, but the real power are in the Intel hands. 3) Symbian^3 and Symbian^4 are the future on all foreseeable Nokia products. My analysis is that the use of QT on Symbian and MeeGo will allow Intel to use the applications from Nokia and vice versa. So I don't see a need from Nokia to supply a Linux product line anymore. Now if this is right, Nokia should have done ofono and Maemo for Intel by expecting something in return. Regards, Jean-Christian ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: RPM Vs. Deb (Was Re: MeeGo)
Fathi Boudra a écrit : That's pure speculation but it's the only rationale I found so far about the rpm choice. Quoting from a lwn.net comment: --- reference: http://www.desktoplinux.com/news/NS2068665492.html: Hohndel was quoted as saying that the move to Fedora was largely a "technical decision based on the desire to adopt RPM (Red Hat Package Manager) for package management" instead of Ubuntu's Debian DEB extension. RPM offers the advantage of containing license information, Hohndel was said to have noted, thereby enabling developers to create collections of software by license type or exclude software by license type. --- reference: http://www.phoronix.com/scan.php?page=news_item&px=Nj... "One of the examples cited by Dirk was the ability for RPMs to easily identify the license of packages and being able to build an environment including or excluding a particular license type." --- This is pointless. Debian package can contain license information if you want to. Please read the chapter "5.7 User-defined fields": http://www.debian.org/doc/debian-policy/ch-controlfields.html Adding just a "XBS-License:" line in each package control file do not justify to lose 5 years of work. Regards, Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
Kees Jongenburger a écrit : On Tue, Feb 16, 2010 at 9:59 AM, Jean-Christian de Rivaz wrote: Aside of this, I am puzzled to see a project that it targeted to support both X86 and ARM processors without even considering the multiarch future. Sound crasy to me. Debian have accumulated a immense amount of knowledge on how to do this the right way and there have made many changes in the package management to handle multiarch. RPM packaging is completely outdated about this. Hi, Debian does handle "multiarch" ok in repositories and such but wake up and look around it is not special or anything. Debian is far far behind when is comes to "multiarch" and real device support. They only provide unoptimized generic armv5 code http://www.debian.org/ports/arm/ and the way debian works (no cross compiling) makes it a pain to port to other platforms. You have to see not only the current state but also the goal. Only Debian will be ready for multiarch is a foreseeable future. Others distributions have just missed the point that all the current way to build embedded system will be obsolet soon. In the near future, there will be no difference between your PC and you phone from the distribution point of view. So a SDK for embedded system will be pointless. Even the word "embedded" will be dropped. It's perfectly doable to start a new armv7 port into Debian if it make sense to do it. now try and compare that to something like poky http://www.pokylinux.org/ I work with SB2, OE, Buildroot and LTIB. For me there are all already something of the past. Regards, Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MeeGo
Yves-Alexis Perez a écrit : On 15/02/2010 17:29, Luca De Cicco wrote: I would stay away of packaging holy wars (packaging is boooring) :). It is true that packaging has some technical implications, however I would focus more on the scenario we are going to experience. But packaging is a whole part of a good user experience. Bad packaging means *bad* user experience, trust me. Absolutely right. The success of Ubuntu and Debian have proved this. Aside of this, I am puzzled to see a project that it targeted to support both X86 and ARM processors without even considering the multiarch future. Sound crasy to me. Debian have accumulated a immense amount of knowledge on how to do this the right way and there have made many changes in the package management to handle multiarch. RPM packaging is completely outdated about this. Regards, Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: RPM vs. Deb (was Re: MeeGo)
Michael Cronenworth a écrit : Thomas Tanner wrote: I don't want a platform that is merely a Qt runtime enviroment (Symbian would be sufficient) but one which also offers me easy access to the complete GNU/Linux software world. Debian based distributions have offered working ARM ports for years but Fedora does not. Porting Moblin/Fedora to ARM would be lots of duplicated effort, using Maemo/Debian on X86 or ARM is for free. Thomas, you're getting all upset over nothing. The fact that RPM will now be used is nothing more than politics. No features will be lost. No amount of whining to this list will change what is already in motion. *cough* http://fedoraproject.org/wiki/Architectures/ARM *cough* I don't see any value in this continued discussion of RPM vs. Deb. Because you don't see any value into the hug advance Debian have in both infrastructure and quality to manage multiple architectures. There is no comparable effort in others distributions like Debian have proved to develop a multiarch distribution. Multiarch will probably start to be usable sometime after the next Debian release and this will greatly impact the way embedded systems will be build. Using obscure politic decision vs recognize the technical merit and effort should be added on top of the "How to destroy a community" list. Regards, Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [OT] Re: retromessenger for maemo and Nokia N900
Andre Klapper a écrit : > Am Montag, den 17.08.2009, 15:33 +0200 schrieb Jean-Christian de Rivaz: >> Andre Klapper a écrit : >>> Am Samstag, den 15.08.2009, 23:39 +0200 schrieb Max: >>>> Except that there is no N900. >>>> I can understand that people try to find a name for Nokia's >>>> next >>>> hardware release running Maemo and using "N900" has become >>>> common, but >>>> the text sounds like it is a real name of a product. >>>> Which it is not. >>> >>> Aha. Pictures 1,3,5 of your URL link to pages about the N900, "the >>> successor of the N800". So your software runs on the N810? >>> >>> Maybe you did not understand my email. >>> Don't come up with names that are made up. >>> Your webpage implies that an N900 exists. That's not the case. Of course >>> if your aim is to confuse potential users you do the right thing. >>> >>> And Google did not announce it. >>> Google only reflects the rumours and gossip out there. >>> >>> andre >>> Andre Klapper (maemo.org bugmaster) >> Why did you complain ? > > If you had read my email you should know: If you had read my email you should know that I am not the original poster, but someone that simply find your reaction not appropriate. Best Regards, Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: retromessenger for maemo and Nokia N900
Andre Klapper a écrit : > Am Samstag, den 15.08.2009, 23:39 +0200 schrieb Max: >> Except that there is no N900. >> I can understand that people try to find a name for Nokia's >> next >> hardware release running Maemo and using "N900" has become >> common, but >> the text sounds like it is a real name of a product. >> Which it is not. > > > Aha. Pictures 1,3,5 of your URL link to pages about the N900, "the > successor of the N800". So your software runs on the N810? > > Maybe you did not understand my email. > Don't come up with names that are made up. > Your webpage implies that an N900 exists. That's not the case. Of course > if your aim is to confuse potential users you do the right thing. > > And Google did not announce it. > Google only reflects the rumours and gossip out there. > > andre > Andre Klapper (maemo.org bugmaster) Why did you complain ? After all, Nokia is the only cause of this situation by having announced a new product with it main specifications without giving a name to it. So people outside Nokia have used the most logical one: "N900". Nokia have given the code name "RX-51" but it was too late and not in line with the existing N770, N800 and N810 names. If you still don't wants to say the name of the next product, you can simply ask to use the code name RX-51, without complain to a person that try to support your next product. That's so simple and elegant. Best Regards, -- Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo will switch (completely?) to Qt?
David Greaves a écrit : > Jean-Christian de Rivaz wrote: > > And each new languages need a manual custom binding to use QT because of >> C++. The GObject model has been designed exactly to avoid a such big >> wast of time. GObject allow automatic binding in any languages. This is >> why GTK is technically superior to QT. GObject is a hug success in a lot >> of very important libraries. > > Will this help? > http://www.kdedevelopers.org/node/3878 Yes, absolutely! Thanks for the link. I hope that one day QT and GTK will merge. Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo will switch (completely?) to Qt?
3rdShift a écrit : > On Mon, 2009-07-06 at 16:23 +0100, Aniello Del Sorbo wrote: >> 2009/7/6 Andrea Grandi : >>> Hi >>> >>> 2009/7/6 Klaus Rotter : >>>> ma...@bitblit.net wrote: >>>> > The way I understand it, Qt uses C++ but GTK uses C. So does one >>>> need to >>>>> learn C++ to write Maemo apps now? That would suck... >>> I think you'll be able to write them in Python too >> What always stopped me from writing Qt application was that I had to >> learn a new language to use it. >> Of course the same reason applies the other way around. >> >> As much as I would love to learn Qt, I really hate C++. >> And I don't want to rely too much on Python. > > If you plan to stay in the business as career software developer, then > the ability and willingness to retool yourself with new language/OS is a > must. Otherwise, you have a slim chance to make a living for yourself > and your family. Let me see, Algol/IBM360, Fortran/IBM360, PL/1/IBM360, > Pascal/PC, C/Win,UNIX, C++/Win,UNIX,Embedded, Java/* - you get the > picture. And this barely covers first 15 years of paid experience. The > army of software developers is expotentially growing in east europe, > asia, china, india, and here is US and writing new languages has become > extremely easy compare to the old days. And each new languages need a manual custom binding to use QT because of C++. The GObject model has been designed exactly to avoid a such big wast of time. GObject allow automatic binding in any languages. This is why GTK is technically superior to QT. GObject is a hug success in a lot of very important libraries. I don't see why we should left it for the widgets just because C++ fanatics don't want to learn how to code with a superior programming model that is open to any languages. Ask yourself: why there is so few general libraries written in C++ compared to the libraries written in C ? Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo development on Mac OS X
Jose Manrique Lopez de la Fuente a écrit : > Try vmware+linux+maemo sdk > > 2009/1/5, Ove Nordström : >> *I was wondering if there is a way to **install a Maemo development on Mac >> OS X? Last version of VirtualBox might be a better choice than vmware if your processor support virtualisation. I found it far easier to install and I/O (HDD and net) are very fast compared to vmware. -- Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: What does Nokia's acquisition of Trolltech mean to Maemo?
Jürg Billeter a écrit : > On Tue, 2008-01-29 at 21:06 +0100, Klaus Rotter wrote: >> Maybe the best would be C# (I like C# as a language design better that >> java) with a native gtk# interface and a compiler with compiles this to >> machine code. A gcc# would be nice... > > You might be interested in Vala[1][2], then. The absolute dream would be a Python to Vala translator. This will require to only use GObject compatible construct in Python, but when you have finish your Python code you can get a small ELF binary. Ok, I stop my delirium... :-) -- Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using available DSP tasks
Sorry, I missed the " ! dspmp3sink" at the end of each command into my previous mail. The correct commands was: gst-launch-0.10 dspg729src dtx=3 ! dspg729sink filesrc location=MyDocs/.sound/Here_is_the_story.mp3 ! dspmp3sink gst-launch-0.10 dspg729src dtx=3 ! filesink location=in filesrc location=out ! dspg729sink filesrc location=MyDocs/.sound/Here_is_the_story.mp3 ! dspmp3sink -- Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using available DSP tasks
Hello Simon and Daniel, Your help is truly fantastic! I have found the "gst-inspect-0.10 -a" command and I have now almost all the informations I need. I have tested this command: gst-launch-0.10 dspg729src dtx=3 ! dspg729sink filesrc location=MyDocs/.sound/Here_is_the_story.mp3 Most of the time this command raise a error in gst_dspg729src_start: "could not open resource for reading and writing". But sometimes it work perfectly well as expected, with as bonus the automatic gain control of the voice with silence detection, and all that without loading the main CPU. Very nice! But the following command never work as I expected: gst-launch-0.10 dspg729src dtx=3 ! filesink location=in filesrc location=out ! dspg729sink filesrc location=MyDocs/.sound/Here_is_the_story.mp3 The "in" file start recorded only after the "out" file has been played. And sometimes the command failed with an error in gst_dspmp3sink_open : "Could not open resource for reading and writing", witch is strange for the MP3 stream. Other problem, the G729 stream is only usable for a few seconds if it is recorded into a file. I actually don't know if the problem is while recording or playing the stream. I suspect that I maybe need to use something that look more like stream of packets instead of a file to handle the G729 stream. Best Regards, -- Jean-Christian >> P.S. Just to test that the karaoke idea will work I tested MP3 and >> G7.29 data (I couldn't find any G7.11 data to test) and they play >> together without troubles: >> >> E.g. >> gst-launch-0.10 filesrc location=20-16000HzExp5sec.mp3 ! dspmp3sink >> filesrc location=./audio-temp/transfer.g729 ! dspg729sink >> >> > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using available DSP tasks
Simon Pickering a écrit : > >> If the DSP in not the limitation, then the N800 could be used for a >> funny project I have now in my head. I there any documentation on how to >> program a Linux application to use some existing DSP tasks available >> on the N800? I am interesting about the MP3 decoder and a pair of low >> bandwidth coder/decoder like G711, G729 or ILBC. > > There is source available for the ARM-side part of the gstreamer sinks > (http://repository.maemo.org/pool/chinook/free/source/g/gst-plugins-dsp0.10/). > > That should show you how to use the dsp tasks. > > There's a fundamental problem though, the mp3 dsp task sends its data > directly to the audio codec (hardware) on the DSP-side, therefore you're > probably not going to be able to access the raw data to reencode it as > something else (unless it is also exposed in a buffer in shared memory). > > I am debugging an mp3 dsptask at the moment, so you may yet have > something to play with at some point in the near future if you can't get > the built-in tasks to work as you wish. > > Cheers, Hi Simon, Thanks for your explanation. After having read the basic Gstreamer documentation, I understand better the sink pad concept of the mp3 task. In the application I am thinking about now, I don't need to look at the raw audio data decoded by the MP3 task as long as I can mix with it an other raw audio stream. I fact I need to mix a MP3 stream and a G711|G729|ILBC|AMR stream. You can see it as a kind of karaoke: mixing music (MP3) and voice (low bandwidth codec). The result should simply be available on the output jack. Did you think it is already doable now ? Best Regards, -- Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Using available DSP tasks
Tuomas Kulve a écrit : > Jean-Christian de Rivaz wrote: > >> "g729_dec" was runnings. I wonder if this was a limitation from the DSP >> or from the Linux applications (e.g. Media Player and Skype trying to >> use the same device). > > I think the device stops all other audio when a VOIP call is made, but I > think this is how it's designed, not a technical limitation. I'm mostly > guessing here though. > > You should be able to test that quite easily by running couple > gst-launch instances from the command line. > Thanks for the gst-launch hint. I didn't know Gstreamer, so I will have to learn a bit before doing useful experiment. Seem to be a very nice open source framework. Regards, -- Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Using available DSP tasks
Hello, I have monitored the DPS tasks by executing periodically the command "cat /sys/devices/platform/dsp/dsptask*/taskname" while playing some tests with a MP3 in media player and the Skype test call. I found that the DSP can run many tasks at the same time, but I was unable to catch the "mp3dec" task running at the same time that the "g729_enc" and "g729_dec" was runnings. I wonder if this was a limitation from the DSP or from the Linux applications (e.g. Media Player and Skype trying to use the same device). If the DSP in not the limitation, then the N800 could be used for a funny project I have now in my head. I there any documentation on how to program a Linux application to use some existing DSP tasks available on the N800? I am interesting about the MP3 decoder and a pair of low bandwidth coder/decoder like G711, G729 or ILBC. Best Regards, -- Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N800: Loss of touch screen sensitivity/pressure detection
Neil Jerram a écrit : Would be great if this was a software problem, but my current impression is that something about the N800 screen is a lot less good than the 770. A agree. While the drawing application is a pleasur to use on the N770, acting almost like a real pen and paper, this is a nightmare on the N800. It's just impossible to draw a small point and the drawing is alway delayed relative to the pen position. Recalibration don't help. Clearly the implementation of the touche screen is different on the N770 and on the N800. I don't known any advantage of the N800 implementation. To me it's just far worst that on the N770. Best regards, -- Jean-Christian de Rivaz ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
