Re: QT map widget
A start may be this widget: http://medieninf.de/qmapcontrol/ You might also want to look at the marblewidget (http://edu.kde.org/marble/). As far as I know it can be built without any kde dependency, and is pretty powerful. Apparently it's also already running on an N900 (from the bottom of the linked page, just in case anyone missed it): http://nienhueser.de/blog/?p=95 https://garage.maemo.org/projects/marble Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
On 11/06/2010 10:02, Till Harbaum wrote: with the switch to qt i think there's a need for a qt map widget. I really see a need for a unified widget to be used by all applications. The current situation with multiple different map widgets on maemo5 shows what imho should be prevented: - They store cached tiles at different locations wasting bandwidth as well as device flash space - No central point for map maintenance (e.g. cleaning the map cache or downloading entire areas into the cache for offline usage) - No easy and central way to add new map sources - The overall look and feel is different although they intend to provide similar function - Some widgets work behind network proxies, some don't - None of these widgets is really developer friendly I should add that I totally agree with the goal here. The question is whether it would be better to decide exactly what we want (in terms of features, hw accelerated rendering, etc.) and write something new, or to modify an existing piece of code. Certainly if this qmapcontrol is suitable that would make life easier (and from a quick glance it looks ok). Would a wiki page be useful to determine people's wishes for such a widget? Just thinking off the top of my head there are things like: Multiple map sources. Would that include things that are available but not necessarily fully legal e.g. Google maps - at least it should provide a way for third parties or users to enable such things? What about deciding what sorts of local POI lookups, routing, traffic info, etc. might be wanted, and whether it should/can come from online or local vector map data (e.g. OSM), or even RDS ;) and how these should be provided. Overlays are another important point - this was a stumbling block for Maemo-mapper for a long time iirc. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: QR-Code
Is there a project to QT QR-Code ? Take a look at the Qt branch of the maemo-barcode Garage project, or install mBarcode from extras-devel. We use libzbar for the QR decoding (thanks derf for writing the decoder) via a Gstreamer wrapper (thanks ensonic). More developers for the core of mBarcode and especially plugins always welcome as my time is currently rather short and I think Svenn-Arne is suffering from the same problem. Thank's ! Cheers, Simon -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Roberto Teixeira Sent: 13 May 2010 03:01 To: maemo-developers@maemo.org Subject: QR-Code Hi !Is there a project to QT QR-Code Is there a project to QT QR-Code ? Thank's ! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: QR-Code
Hi Daniil, QR is not mentioned in Debian package description. http://packages.debian.org/sid/libzbar0 I think maintainer should be contacted. It was introduced fairly recently (in 0.9 iirc) and fwiw we have 0.10 in the extras-devel feed iirc. See here: http://zbar.sourceforge.net/ Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: GStreamer, mp3 playback and the DSP
I'm currently using GStreamer to play mp3 files. I'm trying to move all mp3 decoding to the DSP but I'm unable to find any useful info on the matter. May I ask why you're trying to move mp3 decoding to the DSP? Are the mp3s the sound track/effects for a game, etc., so you want to have more CPU cycles to do useful work? The only thing i got so far is this paragraph from the wiki: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Ar chitecture/Multimedia_Domain#Audio_Codecs Most of the audio encoders and decoders are wrapped under the OpenMAX IL interface [OMAX], which abstracts the codec specific implementation (which in general can run on ARM or DSP). Unless a different solution is needed (due e.g. to sourcing problems, performance requirements or to fulfill some specific use cases) all the audio codecs will be running on the ARM side to simplify the audio architecture and to avoid the additional latency and load over the data path due to the routing of the audio data first to DSP and then back to ARM. So, obviuosly a different solution is needed but I coudn't find any documentation whatsoever. :) Anyone can help here? Are there any existing OpenMAX mp3 decoders targetted at the TMS320c64x DSP? If not, it would probably not be too painful to port one (where pain is all relative, but at least this would be less painful than trying on the more constrained and 8bit-less c55 ;) Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: GStreamer, mp3 playback and the DSP
I'm currently using GStreamer to play mp3 files. I'm trying to move all mp3 decoding to the DSP but I'm unable to find any useful info on the matter. May I ask why you're trying to move mp3 decoding to the DSP? Are the mp3s the sound track/effects for a game, etc., so you want to have more CPU cycles to do useful work? Yes, it's an emulator actually, and mp3 decoding is noticeably stealing CPU cycles. Ok, I just wanted to check that your reason was something valid and indeed it is. snip So, obviuosly a different solution is needed but I coudn't find any documentation whatsoever. :) Anyone can help here? Are there any existing OpenMAX mp3 decoders targetted at the TMS320c64x DSP? If not, it would probably not be too painful to port one (where pain is all relative, but at least this would be less painful than trying on the more constrained and 8bit-less c55 ;) Thats what the wiki article I quoted seems to imply, but it's not very clear and I couldn't find any further info. There's a multimedia framework diagram suggesting that there are OpenMAX audio codecs that run in the DSP via DSP-bridge, but not sure if this applies to maemo 5 and there's no info on how to use them. I must admit that I've not done any DSP work on the c64, though I did pay attention to it when the N900 was originally announced (and I thought I'd get a Pandora to fill the gap until it was shipped, glad I didn't pin my hopes on that now ;). Anyway I imagine some of the Nokians (and others) will know from first hand experience so please someone jump in if I've got the wrong idea. So yes, my understanding is that that is exactly what's involved, therefore it should be possible to write an OpenMAX compliant codec that uses the DSP bridge to transfer data back and forth to a decoder running on the DSP. There were docs and examples on one of the websites (this one iirc: https://gforge.ti.com/gf/project/omapbridge/ and DSP coding docs on this site: http://www.ti.com/sc/docs/psheets/man_dsp.htm), not sure about the OpenMAX docs, but I guess there will be example code floating about somewhere (or you might just wrap the DSP bridge interface stuff directly in a Gstreamer plugin and skip the OpenMax stuff completely). I think that writing/porting this should be reasonably straight-forward, optimising it less so, but at least afaiu the code shouldn't need major changes to get rid of 8bit types. However on the N8x0 devices it was not possible to directly output audio from the DSP due to a lack of api docs (it would need a re-write of the DSP kernel or reverse engineering the DSP audio codec api, which are things that would now be good for Mer, but would take some time, but that's another story). I don't know if it is currently (or would be relatively easily) possible to output audio directly from the N900's DSP. This is something you should try to find out, as on the N8x0, needing to pass data both to and back from the DSP (in this case for SBC encoding) clobbered video decoding on the CPU (CPU load was lower with SBC encoding on the DSP, but something, presumably memory contention due to the way the data was passed to and fro for both the DSP and framebuffer, dropped the mplayer decoded framerate down from iirc ~25fps to ~1fps). I imagine/hope the N900 + DSP bridge setup is better, but I really don't know. Does anyone know? Could a Nokian tell us about the possibility of direct audio output from the DSP and how efficient the data passing is in the absence of direct audio output? Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: music player with .lrc support !
Personally, I think it's too small for a 3 month project, though. However getting LRC parsing into gstreamer or MAFW for use by the Nokia media player would be a fine challenge for three months, IMHO. This certainly sounds useful. But since the Nokia media player is closed source, it would be kinda hard to make it display lyrics. An alternative would Wasn't the whole idea of MAWF to make it easy to replace the Media Player and only need to write the GUI stuff (leaving all the playlist stuff to MAWF, decoding to Gstreamer, and finding files to trackerd)? I've not looked at it though, so perhaps it's difficult to work with hence the lack of replacement players. Though if not, writing a proof of concept player to display the lyrics too shouldn't be too hard (he says). Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Performance of floating point instructions
in maemo-mapper I have a lot of code involved in doing transformations from latitude/longitude to Mercator coordinates (used in google maps, for example), calculation of distances, etc. I'm trying to use integer arithmetics as much as possible, but sometimes it's a bit impractical, and I wonder if it's really worth the trouble. Is the code slow at the moment and is it specifically the fp stuff that's slowing it down? If not, I'd say it's probably not worth the effort unless you're doing this for fun/out of interest. Does one have any figure about how the performance of the FPU is, compared to integer operations? A practical question: should I use this way of computing the square root: http://en.wikipedia.org/wiki/Methods_of_computing_square_roots #Binary_numeral_system_.28base_2.29 (but operating on 32 or even 64 bits), or would I be better using sqrtf() or sqrt()? I'd suggest writing some benchmark code for the functions you wish to compare. Does anyone know any tricks to optimize certain operations on arrays of data? There are SIMD extensions (http://www.arm.com/products/processors/technologies/dsp-simd.php). Basically, what we did with ThinX OS, is have a full blown soft-float toolchain which then used the already proven and highly optimized GCC's stack floating point operations. However , Maemo is not soft float, so I'd recommend to experiment with rebuilding Mapper using such a soft float enabled toolchain, statically linked to avoid glitches to system's libc or have a seperat LD_LIBRARY_PATH to avoid memory hogging, and see where it gets you. Soft-float is significantly slower than using the VFP hard-float (using mfpu, etc., flags on GCC on the N900 and the N8x0 for that matter), there should be emails containing benchmarks on the list from a long while back otherwise I can dig them out again. But Alberto's situation is slightly different as his integer-only code need not deal with arbitrary fp numbers (as is the case for the soft-float code) as he knows what his inputs' ranges will be, therefore he should be able to write more efficient and specialised fixed point integer functions that avoid conversion to and from fp form and that trim significant figures to the minimum he requires. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: External Repository and HAM
Marius Vollmer wrote: To be fair, libraries do not _need_ to be shared, sharing them is an optimization. True, but this is very inefficient on small-memory devices. It makes a huge difference to have, say, 3 applications sharing a library instead of having 3 copies in memory instead. And it's also rather a waste of the developers' time if someone has already gone to the effort of Debianising/getting it to work in general. How to resolve this? Ideally, library K should now be taken over by some maintainer (who could be one of the two mentioned, or someone else), but this time built as a universal library with all features enabled, useful for all developers. The good thing about a shared repo here is that at least the issue comes to a head quickly. Do we have procedures for handling this? Is this actually a problem? I've done this a fair few times, either had someone ask me if I'd recompile something with different configure options, or said the same to someone else. I don't see much point in building with all options until/unless they are needed as you increase the effort/build time/probably the installed size/etc. I've got to say I find this a real annoyance when porting Debian packages that include every possible combination of external libs in their requirements (recursively), when not many of them are probably necessary for what I want and it means I need to get even more support libs working (and when I'm thinking of FORTRAN apps here, that's often actually a real pita). Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Extras-testing improvements
Also, the idea that an application can both be low quality and end user ready is bizarre. If the general Nokia view is that Extras apps should also look pretty and have nice design (i.e. so they reflect well on the device), which is a good goal for all apps, but should not be a requirement, then we need another repo layer between Extras-testing and Extras proper, where apps that work but are perhaps not up to the stringent prettiness standards can be placed. I do not represent the general view of my employer or anyone else, just myself. My apologies. But poor quality applications reflect badly on maemo.org community as well. Do you want to be part of a community which is known for its low quality standards? From the list you show below, quality is obviously something that people judge differently. For me quality is not that an app doesn't crash or break things, but that it looks nice, spelling is good, it works efficiently and quickly, etc. Notice that the current extras-testing QA requirements are quite low: 1. [ ] Bug database exist. Annoying, but not hard to add (particularly if you choose a tmo thread instead of bugzilla). 2. [ ] Licensing ok. 3. [ ] No illegal/dubious content. Yep, no piracy is acceptable. 4. [ ] Working provided features. Yep. crashing apps are bad. 5. [ ] No missing announced features. If something doesn't work (yet), don't advertize it. Don't dissapoint users. 6. [ ] Optification ok. Should we start accepting packages that break SSUs ? 7. [ ] No performance problems. 8. [ ] No power management issues. This could be clarified to belong only to always-running apps (such as hildon-desktop plugins). 9. [ ] No known security risks. This is a bit sketchy, but certainly allowing things like default password ssh server would be very very bad for endusers. I wouldn't call these things the quality of an app, and I think using that word is rather misleading. But anyway we're all still singing from the same hymn sheet, so that's good. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Extras-testing improvements
Also, the idea that an application can both be low quality and end user ready is a bizarre. I completely agree with Graham Cobb here, Extras should contain apps that work no matter how pretty or poorly spelled they are. To repeat myself, this is not really the issue here. Some testers might get carried away (at which point they need to be corrected), but the testing guidelines are quite clear about certain things being blockers, and others (like aforementioned spelling and general prettiness) not. There are borderline cases (like icons, bugtrackers, etc) but still, those are just shades of gray, they do not change the process fundamentally. Ok, I'm quite happy with that, my only issue is with the repeated use of the words Quality of an app which means different things to different people (as shown by the way reviewers, and we, act and respond differently). Regards, Attila Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: External Repository and HAM
remove it if they don't like it. It is not about the quality of the app itself: its usability, its GUI, how well it works, whether it is useful, whether it has screen shots, etc -- that is what crowd-sourced rating systems are about (the stars, the reviews, the comments). Any app without a screenshot is not going to get good comments or make its way to the front page of the Downloads section. Poor apps will drop to the bottom -- but being at the bottom does NOT mean they should be excluded. I think this is a fundamental misunderstanding for (some) users who at least sometimes give a thumbs down because some feature hasn't been implemented/doesn't work very well/etc/etc. But then should the promotion process also take into account whether the app is unfinished/has spelling mistakes/etc. These are all bad things and perhaps an app shouldn't be promoted if these are present, but they are vastly less important than if an app is badly behaved and could crash your device/steal your wife/etc. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo extras repository package uploader/maintainer verification?
What checks there are in place to verify that the package uploader and the package maintainer field (shown to people who install the packages) match? I think Niels has a check for that in the QA software he has written, in fact, I am certain of it. :) This check does not currently default to stopping the incorrect uploader / maintainer from uploading the package. It is possible to change this behavior and I think in the future this check will default to stopping package uploads that do not have the correct maintainer information. I'd suggest that the autobuilder checks to see that the uploader's email address is included in one of the *Maintainer fields; but there is the slight problem of what happens when someone is uploading someone else's package (e.g. as a favour when they are away from a build machine)? I'd also be tempted to move the existing Maintainer field to XSBC-Maintainer and substitute the uploader's name/email automatically if they are not already in the Maintainer field, though again this suffers from the uploading package for a friend problem. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo extras repository package uploader/maintainer verification?
I'd suggest that the autobuilder checks to see that the uploader's email address is included in one of the *Maintainer fields; but there is the slight problem of what happens when someone is uploading someone else's package (e.g. as a favour when they are away from a build machine)? There's also packages which are maintained by a team but uploaded by an individual. And there are also packages taken from Debian/Ubuntu and uploaded without any change. I don't think we should stop them from coming. It's possible to find real uploader name in autobuilder logs and might be in the /packages web UI as well. Bringing new checks like this to the system wouldn't make entrance barrier lower for newcomers. Automatically fixing the Maintainer field of these straight re-compiles would actually make the entrance barrier slightly lower, the compiler (person) would have one less job to do editing debian/control. And really it is the straight re-compiles that are the issue here and certainly we don't want to stop them. Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo extras repository package uploader/maintainer verification?
Thanks -- I have no issues with dropping my name into the maintainer field; I just didn't want to steal any credit from the real authors of those things that I just repackaged. I do know the language of everything I've repackages; and could probably muddle my way through something I didn't know. ;-) Change the original Maintainer field to iirc XSBC-Original-Maintainer and add yours in the place of the original. Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Autobuilder build error (unmet dependencies)
Is this an effect of the PR 1.1 problem and I have to rebuild libIllumination, too? Yes. What you see there is that libillumination0 is built against newer gstreamer and libosso (from pr1.1) The fastest way to solve this is to submit the package again (increase revision) Have all the existing extras-* packages been (automatically) tested against the new SDK? I suppose that's the best way to make sure that they will all be installable. Apologies if I missed the announcement of this. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: How to access geotag information?
GPS data is stored in tracker for images only. Till wants GPS data for *all* file types. I really REALLY think tracker is the only useful way to deal with geotags especially in a mobile device where indexing may really be expensive with respect to CPU power and battery. We have two problems: 1) Who set the location information? Responsibility of applications. 2) Where should that information be stored? In tracker. but ... 1) No application is really setting location information except the image viewer (and only for images) 2) Tracker 0.6 cannot store efficiently that information. We could try to add a File:Location property, so you could set location for everything known by tracker, but it is going to be very very inefficient. This will be fixed in 0.7 . It would be preferable to also store the lat/lon information so that applications could use that if they see fit (e.g. map apps) as well as the pre-reverse geocoded location name, otherwise there's additional overhead and severe inaccuracy of the geocoding. From a quick websearch I can see that video can and is geocoded at least (either once uploaded, or for e.g. some Sony camcorder with a built-in GPS), so adding support for geocoded videos would be nice. I can also envision other files adding geocoding metadata about themselves to the tracker database, even if the file itself doesn't support internal geocoding metadata (is that possible, I guess it should be?) so adding a geotag field (or fields I hope for name and lat/lon) would be a nice, cool and future proof thing to do (but yeah it will waste some space for files that don't use it, but probably not much, though I've not looked at the db so I don't know for sure). Anyway I think it's a shame we don't make more use of our geo-information and the ability to enable it in general on the N900 - the IM app doesn't report actual location data which is a real shame (and hence my interest in using Google's Latitude instead), contacts can contain addresses but not more accurate lat/lon, etc. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: FM RDS data
I'm thinking of a small usage, a app that found the freest frequency (by listening fm with the transmitter) and change the frequency of transmitted music to the found one and send an rds signal by the transmitter, so you don't have to change frequency on your car receiver (or everything else). Great to hear this, I was thinking of trying something similar when I had some time. The FM transmitter also has a basic receiver built in (afair from the spec sheet), i.e. not the one that is built into the Bluetooth chip that is used to listen to the radio, which I imagine is designed for just such a usage (I think it just returns a signal level for each frequency, but I'd have to take another look at the sheet to be sure) does anyone know if we can access this at the moment? Cheers, Simon -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Martin Grimme Sent: 07 January 2010 07:23 To: Benoît HERVIER Cc: maemo-developers@maemo.org; Aldon Hynes Subject: Re: FM RDS data Hi, yes, RDS PS and RDS RT can be modified. See http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Us ing_Multimedia_Components/FM_Transmitter_API_Usage Martin 2010/1/7, Benoît HERVIER kher...@khertan.net: About FM and RDS modifying RDS signal transmited from the tablet is possible ? I'm thinking of a small usage, a app that found the freest frequency (by listening fm with the transmitter) and change the frequency of transmitted music to the found one and send an rds signal by the transmitter, so you don't have to change frequency on your car receiver (or everything else). I know that fm transmitter emit an rds signal ... but can that be changed ? Does there is documentation about the fm transmitter and receiver somewhere on Maemo ? Thanks a lot 2010/1/6 Martin Grimme martin.gri...@gmail.com Hi, the FM receiver's interface for RDS is exposed via sysfs. So any application can read RDS data from it. The frequency bands the receiver is capable of are US/EUR (87.5 - 108.00 MHz) and Japan (don't remeber, but I think starts somewhere at 70 MHz). A region switch in the driver (sysfs-Interface again but as root) switches between the frequency bands. Martin 2010/1/6, Aldon Hynes aldon.hy...@orient-lodge.com: I have been approached by a person interested in sending data from a sensor via FM to a cellphone which would in term transmit this data to the Internet. I am interested in figuring out if this is something that could be done with an N900. With that, I have a few specific questions: First, can anyone point me to information about how to programatically receive RDS data? I've read that the FM receive app is supposed to do that, but I haven't managed to receive RDS data that way yet, and I don't have the source code. Second, does anyone have any idea what frequencies the FM receiver can tune into? The programs I've seen have focused on the traditional commercial FM band, 88 Mhz to 106 Mhz. Can the FM receiver tune in higher or lower frequencies? If so, what is the real frequency range of the FM Receiver. Third, are there other data formats that can easily be sent and/or received from the Nokia phone? If so, can people point me to any of these other data formats? Any help you can provide would be greatly appreciated. Aldon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Benoît HERVIER - http://khertan.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Developing Map-based apps for N900
If I want to develop an app that integrates with a map plugin, then obviously I want to use Ovi maps but the Ovi Maps SDK doesn't support Maemo and as far as I know the Ovi Maps app for Maemo can't be used as a plugin. There must be work going on behind the scenes to resolve this situation - in the mean time I would be greatly appreciated if someone from Nokia could provide some direction so developer like myself avoid wasting time on solutions that might be dead-ends when the real solution is eventually announced. The way I see it there are several potential solutions: 1) I could write a Qt App that embeds Ovi Maps into a QtWebKit widget. I don't think this is currently possible due to it's lack of support for Maemo/Linux but I will do some prototyping here any way and see how far I get. 2) Write a Qt app that embeds Google Maps into a QtWebKit widget. 3) Wait for a dedicated Ovi Maps plugin for Maemo to be developed. Will there ever be such a plugin? Can someone from Nokia comment on this please? I'm not from Nokia, though I would like to know if the mapping situation will improve out of the box. With that said, Maemo-mapper is now available for the N900 as is Emerillon in Extras-devel (uses liblocation but needs its menus hildonising still). Emerillon is plugin based so that might give you another useful option. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Google Latitude
Hi all, Though this is probably more of a -users subject, I thought some testing might be worthwhile to begin with, plus I'd hate to have to actually pay attention to the -users list ;) I've been wondering about Google Latitude for a while now (ever since we were at the summit and trying to meet up in the same pub in a place were we didn't know the geography and couldn't pronounce the street names). Anyway, this seems to work to some extent: Install the maemo-geolocation plugin for the browser; In the browser open www.google.co.uk/maps/m?view=datamode=latitudesource=moggl=uk which is the page the iPhone opens. There doesn't seem to be a check on the useragent (except if you try to open google.co.uk directly). I guess it will be something similar for you guys in the US, a combination of desktop Firefox + User Agent Switcher + tcpdump should tell you exactly if you can't work it out by guessing. Then click away and use the (web)app. Not sure how location updates work, whether they are handled automatically or not, something to be tested. It also might be a better bet to work out the protocol the Google maps Latitude page uses to avoid the overhead of having the browser running all the time. But I don't know, it might be ok powerwise - anyone thoughts? Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Google Latitude
Not sure how location updates work, whether they are handled automatically or not, something to be tested. It also might I'm sat in my flat (i.e. with only a cell id location), and can see myself jumping all around Bath, so I guess updates are handled automatically. The one strange thing is that the last update message doesn't seem to be set by this webapp, while it is set by the Google homepage Latitude plugin, not sure/not looked how to fix that as it would be useful to know when the last update was. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Google Latitude
I'm trying this right now, but belive me: using Google services (Gmail, Maps, Reader, ecc...) with N900 is something that make you say: what is this shit?! I want an iPhone! :( GOOGLE: PLEASE, release your suite for Maemo! Thanks! Well yeah, it would be good if they would, but for Latitude at least, it doesn't seem to bad (though the webpage design leaves something to be desired as some buttons are in the bottom right hand corner where you have to tap to un-maximise the window. Have you seen Macuco (I think it's called) which is a Qt webkit app which masquerades as an iPhone browser? Does that work any better for e.g. Gmail? Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Debianisation help with packaging libgmp
Hello everyone I've packaged up and pushed libgmp to extras-devel, but obviously made a mistake in the Debianisation as it's trying to install a file to my build directory (so don't try installing it yet). I can guess why the code I inserted is wrong, but can't work out what to put in to actually make it work. I've tried altering the rules file, but to no avail. We're talking about the debian/rules file in the install: section, which currently looks something like this (tabs removed). install: build-stamp install-prep $(MAKE) DESTDIR=`pwd`/debian/tmp -C build install dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmp3c2 usr/lib/libgmp.so.* dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmp3c2 usr/lib/libmp.so.* dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmpxx4ldbl usr/lib/libgmpxx.so.* dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmp3-dev usr/lib/lib*.so dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmp3-dev usr/lib/lib*.a dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmp3-dev usr/lib/lib*.la dh_install --sourcedir=$(CURDIR)/debian/tmp -plibgmp3-dev usr/include dh_install --sourcedir=$(CURDIR)/build -plibgmp3-dev -Xgmp-mparam.h usr/include/gmp*.h # dh_install -plibgmp3-dev build/gmp-arm.h $(CURDIR)/debian/tmp/usr/include # Install upstream ChangeLog, AUTHORS, NEWS, and README only in -dev package dh_installchangelogs -plibgmp3-dev dh_installdocs -plibgmp3-dev AUTHORS NEWS README The build/packaging failure message is this: dh_install --sourcedir=/home/simon/build/Octave/gmp/gmp-4.3.1+dfsg/build -plibgmp3-dev -Xgmp-mparam.h usr/include/gmp*.h dh_install: libgmp3-dev missing files (usr/include/gmp*.h), aborting This part should install the arch specific header file (e.g. gmp-arm.h) from the $(CURDIR)/build directory. I put in the commented out line (just after the one I repeated above) which worked, but fails for the x86 build of course, so back to something generic. The gmp-arm.h file that I'm interested in installing does exist in the $(CURDIR)/build directory just in case you were wondering. Any help appreciated. Thanks, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Geocoding library for Fremantle?
GeoClue offers a geocoding api, but as we use liblocation rather than GeoClue, and as I remember someone saying at the summit (in the presentation on location stuff) that there would be an api to do (reverse)geocoding, I was just wondering if this is indeed the case and when we might see such a thing? Named libaddress perhaps? Maybe this is what you want: http://maemo.org/api_refs/5.0/5.0-final/cityinfo/ Thanks for the pointer, but I think that api only has access to a limited number of cities contained in the database used by the world time app. This is on the device, which is an advantage, but I think I'll have to use something like GeoClue or geonames.org to obtain enough accuracy/range of cities. Something is used to reverse genocide the liblocation supplied lat/lon and to set the contact message location, so it may as well be available for us to use rather than having to write our own for every app. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Geocoding library for Fremantle?
Hi all, I'm looking for a geocoding library to run on the N900. I want to take the location string attached to those N900 using online contacts who provide it, and plot that on a map (Emerillon). Of course having to parse the message string and then do the geocoding is rather wasteful (of CPU, network traffic and accuracy) and it would be vastly more efficient and useful to just have a contact contain the raw lat/lon/accuracy data, but we've got to work with what we've got. GeoClue offers a geocoding api, but as we use liblocation rather than GeoClue, and as I remember someone saying at the summit (in the presentation on location stuff) that there would be an api to do (reverse)geocoding, I was just wondering if this is indeed the case and when we might see such a thing? Named libaddress perhaps? Thanks, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: mbarcode/maemo-barcode dialog oddity and progress report
So I'm more than happy to do this (after I look at libgdigicam to work out how to focus the N900's camera and turn the LED on), as long as people want to use it, I don't want to waste time chopping things up if no-one wants to use it afterwards. I want to use it. =) An easy-to-use wrapper like that can encourage the creation of scanner software for business applications: consider the use of nokia internet tablets as part of a cost-effective distributed system for inventory. Many specialized scanning devices on the market are disgustingly high: for about $2000, you get a mobile computer/scanner with stats (Intel XScale PXA255 Processor @ 400MHz, 64MB RAM, Windows Mobile 2003) that the N810 can wipe the floor with. At lower prices, you devices with archaic OSs and hardware specs. At $700, you get just the scanner without the computer. The nokia internet tablets are a steal! Well controlling the N900 camera is reasonably straight forward using the gst_photography_*() commands, I'll write up a page and stick that on the wiki asap. I've moved the backend (i.e. the decoding part) to use zbar for 1D and QR codes and am still using libdmtx for Datamatrix codes (would be nice to get that linked in as part of zbar so there's just one api to deal with). I also just uploaded the zbar files to the autobuilder (and it failed as I forgot to add a Python dep). So basically all of the low level components are (or will soon be) in place. Will keep the list updated with the progress of the wiki zbar building. On the topic of mBarcode itself, I've got the autofocus working, and you can grab a test code here for the N900 (and a zbar deb too): http://people.bath.ac.uk/enpsgp/nokia770/mbarcode/test/ I'll (try to) debianise it this evening and also check the Diablo code to see that it still builds after all the hacking around the N900 stuff has needed. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: mbarcode/maemo-barcode dialog oddity and progress report
For 1D codes mbarcode will attempt a very basic webscrape of Amazon and will (hopefully) return a title (rather than a segfault). For URLs encoded in a QR code/datamatrix it will open the webbrowser and for vCards it will add them to your contacts. Why is it necessary to do a webscrape of Amazon. Amazon has plenty of simple APIs for getting data freely and easily. The REST based ones are extremely simple and you get back an XML document with everything you need. It quite possibly isn't necessary, this is certainly not my area of expertise, just something I wanted to get working ASAP. When I looked at how to do this I found a mixture of web scraping tools and ones that use Amazon Web Services. AFAIK AWS requires that you register to obtain a key, and I'm not sure of the exact terms and conditions, but I presume they will not want me to share my key, but I may be wrong about this. I guess you're also talking about AWS? What is your take on the key issues - share mine, or get each user to register themselves and get a key? Perhaps the registration could be automated. Any thoughts? Patches welcome of course. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: mbarcode/maemo-barcode dialog oddity and progress report
Hi Kimmo, So all in all it's still work in progress, but it does at least work well enough to test. Except that I use dialogs to ask the user if they want to open a decoded URL/add a decoded vCard, and if these dialogs are displayed the UI locks up straight afterwards. If I comment them out the code continues quite happily after opening the browser/adding the URL, so the fault must presumably lie with the dialogs. What kind of windows you are playing with? We have a special feature in Fremantle where Gtk+ dialogs do not use pointer grabs anymore (*, so it's possible that Gtk+ gets confused there when it does not receive the pointer events. *) This is done to allow the touch screen lock to do the pointer grab and discard all pointer events even if a dialog is open. It's just a plain dialog afaik (GUIs also not being my area of expertise). The dialog does close, so I imagine that means it's getting the click event, but after it closes the rest of the UI locks up. The exact code is here: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/branches/simon_wip/maemo-barcode/web.c?revision=103root=maemo-barcodeview=markup Scroll right to the bottom to see either the openURL() or addVCard() functions, which are the ones that use dialogs and then lock up. Thanks, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: mbarcode/maemo-barcode dialog oddity and progress report
For 1D codes mbarcode will attempt a very basic webscrape of Amazon and will (hopefully) return a title (rather than a segfault). For URLs encoded in a QR code/datamatrix it will open the webbrowser and for vCards it will add them to your contacts. Why is it necessary to do a webscrape of Amazon. Amazon has plenty of simple APIs for getting data freely and easily. The REST based ones are extremely simple and you get back an XML document with everything you need. It quite possibly isn't necessary, this is certainly not my area of expertise, just something I wanted to get working ASAP. When I looked at how to do this I found a mixture of web scraping tools and ones that use Amazon Web Services. AFAIK AWS requires that you register to obtain a key, and I'm not sure of the exact terms and conditions, but I presume they will not want me to share my key, but I may be wrong about this. Replying to myself, another option (which is the same one that Android Scan/CompareEverywhere uses) would be to move the scraping to a server. This might let me use a single key for all the queries (though it may still break the terms and conditions, I'd have to look) and would also reduce on-device processing and the amount of data that needs to be transferred. Or we could try hooking into the Android Scan/CompareEverywhere webservice ;) Any thoughts? Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: mbarcode/maemo-barcode dialog oddity and progress report
On Thu, 2009-10-15 at 10:43 +0100, Graham Cobb wrote: On Thursday 15 October 2009 09:10:44 Simon Pickering wrote: Replying to myself, another option (which is the same one that Android Scan/CompareEverywhere uses) would be to move the scraping to a server. This might let me use a single key for all the queries (though it may still break the terms and conditions, I'd have to look) and would also reduce on-device processing and the amount of data that needs to be transferred. While you are tolerating discussion of enhancements!... lol :) If you do use a server, it would be great if you implemented an offline mode where I could scan barcodes all day without network connectivity and, later, process them when I am online. Some of the places one might want to scan barcodes (barcodes on display adverts, on buildings like in Westergasfabriek, or in warehouses) might not have great network connectivity. Most professional barcode readers which I know of seem to do the scanning offline and process the barcodes once they are plugged into their docking/charging station. Yes, in any case I was planning on allowing the raw data to be saved if a lookup is not possible (for e.g. isbns and also for web urls, etc.), I currently assume an internet connection (which should apparently be fine for Fremantle ;)), but I need to get the code to ask for one and/or have an offline scanning setting (oh dear more gui elements - a menu!) This brings up a slightly larger question of how modular is your current implementation? It feels like it would be good to have a library (accessible from C and Python) which would have an API like scan the barcode the user is currently pointing the camera at and give me back something that tells me what sort of barcode it was and the data it contains (maybe with some sort of callbacks to allow some user interaction if needed to give them help/feedback with the scanning). The subsequent processing (database, lookup, etc, etc.) is the sort of thing that various people might create separate applications for, although it might be useful to expose some useful APIs there as well: lookup this barcode number on Amazon, save this barcode in barcode database called 'My Books', etc. Is that how it works at the moment or something you are looking in to? Yes this is indeed a good idea. At the moment it's not modular as everything is mixed in, however the code is structured such that it won't take long to separate out the processing from the video taking from the gui etc. The question is then how many separate layers? I guess a wrapper/lib to process a barcode from an image buffer. An extra optional layer that can be placed ontop of this to allow the user to see what they are pointing at and to click Scan! (which we may do away with once the camera app is opened up, then we can add the bottom-most layer as a plugin to optionally analyse stuff taken with the main camera app). On top of these/using these one can do the other stuff such as web-lookups, databases, etc. The web-lookups should possibly also be part of the bottom-most layer though, or perhaps separated off into their own package as they will generally be needed no matter the app. Someone mentioned sending the barcodes out over DBUS, is this of interest? Any use cases? So I'm more than happy to do this (after I look at libgdigicam to work out how to focus the N900's camera and turn the LED on), as long as people want to use it, I don't want to waste time chopping things up if no-one wants to use it afterwards. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: mbarcode/maemo-barcode dialog oddity and progress report
Hi Jody, On Thu, 2009-10-15 at 21:42 +0300, Jody Fanning wrote: On 15.10.2009 10:57, Simon Pickering wrote: For 1D codes mbarcode will attempt a very basic webscrape of Amazon and will (hopefully) return a title (rather than a segfault). For URLs encoded in a QR code/datamatrix it will open the webbrowser and for vCards it will add them to your contacts. Why is it necessary to do a webscrape of Amazon. Amazon has plenty of simple APIs for getting data freely and easily. The REST based ones are extremely simple and you get back an XML document with everything you need. It quite possibly isn't necessary, this is certainly not my area of expertise, just something I wanted to get working ASAP. When I looked at how to do this I found a mixture of web scraping tools and ones that use Amazon Web Services. AFAIK AWS requires that you register to obtain a key, and I'm not sure of the exact terms and conditions, but I presume they will not want me to share my key, but I may be wrong about this. I guess you're also talking about AWS? What is your take on the key issues - share mine, or get each user to register themselves and get a key? Perhaps the registration could be automated. Any thoughts? Patches welcome of course. Cheer I'm pretty sure you are able to share the key. I do have an AWS account and have used it for my own stuff (in Java though). But all those applications around must have a key embedded since they never ask you to register yourself. There must be some other open source applications around that fetch data from Amazon using AWS. Amazon did make things a little more complicated a few months ago though. All requests must be signed, but they generally provide code samples for how to do everything. One thing is to check the licensing of the interfaces. There was something recently about different licensing between mobile devices and other uses that came up with the iPhone. But the advantage is that you won't have any problem with the page layout breaking things. Plus their APIs provide pretty much every detail about an item you could think of. OK thank you, I'll take a look at this. Of course if anyone knows about this and/or wants to submit code patches, they will be greatly appreciated! Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
mbarcode/maemo-barcode dialog oddity and progress report
Hi all I've been hacking away at maemo-barcode (now called mbarcode to remove the maemo bit as we're not supposed to use that;) and have made some progress. The code is here: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/branches/simon_wip/maemo-barcode/?root=maemo-barcode binaries here: (you need to install libdmtx0, then just run the mbarcode binary after chmod'ing it): http://people.bath.ac.uk/enpsgp/nokia770/mbarcode/fremantle/ I should add that the code should also run on Diablo, but the diablo dir on the above webpage is out of date so you'll need to compile it yourself (please let me know if it doesn't compile/run). I plan on supporting both Fremantle and Diablo devices, don't worry! In terms of features: 1D (EAN13/UPC12), datamatrix and QR codes are supported. For 1D codes mbarcode will attempt a very basic webscrape of Amazon and will (hopefully) return a title (rather than a segfault). For URLs encoded in a QR code/datamatrix it will open the webbrowser and for vCards it will add them to your contacts. The UI is very rough and ready and needs serious work; the webscraper is very basic and could do with more love (there are some other basic codes in the source, but they are disabled as I've not had time to debug them yet); the database functions on the latter notebook pages also need serious work (the goal being to be able to store details about barcodes you've scanned - mainly 1D products, e.g. DVDs, Books, etc.). So all in all it's still work in progress, but it does at least work well enough to test. Except that I use dialogs to ask the user if they want to open a decoded URL/add a decoded vCard, and if these dialogs are displayed the UI locks up straight afterwards. If I comment them out the code continues quite happily after opening the browser/adding the URL, so the fault must presumably lie with the dialogs. Any ideas what might be going wrong here? I am also open, of course, to patches for anything, but especially webscraping fixes, debianisation, UI thoughts, etc. I imagine I'm going to have to split the source code into some separate files for diablo/fremantle (e.g. camera code, gui code as these will be significantly different) rather than using lots of #ifdefs, does this sound reasonable? Thanks for looking, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: mbarcode/maemo-barcode dialog oddity and progress report
The code is here: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/branches/simon_wip/maemo-barcode/?root=maemo-barcode binaries here: (you need to install libdmtx0, then just run the mbarcode binary after chmod'ing it): http://people.bath.ac.uk/enpsgp/nokia770/mbarcode/fremantle/ I should add that the code should also run on Diablo, but the diablo dir on the above webpage is out of date so you'll need to compile it yourself (please let me know if it doesn't compile/run). I plan on supporting both Fremantle and Diablo devices, don't worry! I've just uploaded a diablo binary to http://people.bath.ac.uk/enpsgp/nokia770/mbarcode/diablo/ vCard importing is disabled for the time being (as I've not looked at the syntax for Diablo), and although the code opens the browser, it just seems to open the start page for me. In fact for both platforms, I should place the URL/text in a text box so that people can select and copy it. Note to self! :) Curiously the Diablo code doesn't seem to suffer from the lock-up after opening the dialog to ask if I want to open a URL. Your theories/patches for the Fremantle code are welcome, as are enhancements for the Diablo code items that aren't working currently (URL opening, vCard adding, etc.) and for anything else you see. Enjoy! Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Built-in reverse geocoding in Maemo 5?
Hi all, I seem to remember hearing that reverse-geocoding is provided by Nokia on Maemo 5, and was just wondering which package contains this functionality and if there are any docs/examples of its use? Thanks, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Becoming root in maemo 4 SDK
Use the fakeroot command [1]. Cheers, Simon 1. http://www.scratchbox.org/documentation/user/scratchbox-1.0/html/fakeroo t.html -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Akshey Jawa Sent: 29 September 2009 14:39 To: maemo-developers@maemo.org Subject: Becoming root in maemo 4 SDK Hi, How to become root in maemo 4 sdk? Akshey ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: How to use extras-testing correctly?
this has been a good informative discussion. since we are working on beta, can i suggest something. anidels point about app feedback *from the device itself* is important. if me as a user selects extras testing and installs a an app because anidel said his new version is there from that moment on, it should be the device itself that monitors the process. in the same way the crash reporter pops up and asks a question after a crash, can we discuss a path to similar for testing apps? perhaps if the app itself in testing had a flag added to its desktop file (or some other way, a list perhaps *hand waving*) and when the user has run the app they are testing, or 1/2/12/24 hours after installing the user was directly asked what are your feelings on this app? That would annoy me something rotten. I'd prefer an opt-in system, e.g. by adding a Feedback/ratings section to the application manager in which installed apps are listed and users can then rate/comment on them. That way if there's something especially good/bad I can go there and comment, but if I don't want to I don't have to. However, I do like the idea of asking people why they are uninstalling something, just as long as it uses radio buttons/listbox for the responses (so it's quick and I don't have to type anything if I don't want to), with a text input box for extra comments/description. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: How to use extras-testing correctly?
you have installed an app from the -testing repository. you are therefore signing up to be a tester. i dont expect normal apps to have this procedure. it is merely a way to expedite feedback Ah yes, forgot this was specific to -testing. Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
N900 camera control - focus movement, white balance, auto-focus calcs, etc.
Hello everyone, I'm looking into how to use the camera on the N900 when it is released, I would like to be able to write some code in Python if at all possible, but I guess I can move my app back to C if needs must. Anyway, the camera will need to be focused, so I have been trawling through the kernel code and gstreamer source to try and work out how to do this, but I thought I may as well just ask as it may save me some time. I see there are ioctls for the ad5820 focus piezo controller which could be used (though I've not looked to see if there's a dev entry for that device yet), and Qole pointed out that the /dev/video0 device reports that it has v4l2 extended controls, including the ability to move the focus (though no mention of autofocus there afaict). I understand I should be able to adjust the focus through a gstreamer element such as camerabin or the photography interfaces, but ideally I'd like to do this from Python. Is v4l2camsrc linked to these btw? The other option (which means I don't have to wrap one of the gstreamer elements for Python) is to use the v4l2 extended control command ioctls directly on the /dev/video0 device. I'm assuming that should be possible anyway, certainly the Python part looks pretty straight forward (see e.g. FMRadio.py). While we're on the subject, I see some header files for what I presume is a Ti binary blob named isp_*.h. isp_af.h contains header information for autofocus functionality afaict. Is this functionality exposed to userspace anywhere? Looking through the package list, I came across a libgdigicam, might this be involved...? Anyway I'm going to keep experimenting with the above, but thought I'd see if anyone else has any bright ideas. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Entry widget in Fremantle toolbar
GPE Contacts has an entry widget in the toolbar so people can enter searches directly. This works fine on earlier versions of Maemo but in Fremantle I can't click in the widget or enter text into it. Any ideas what is wrong? The Home applets don't support text input. http://wiki.maemo.org/QA_Porting_to_Fremantle#Limitation_of_Home_Area_a pplets Cheers, Simon -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Graham Cobb Sent: 02 September 2009 16:06 To: maemo-developers@maemo.org Subject: Entry widget in Fremantle toolbar GPE Contacts has an entry widget in the toolbar so people can enter searches directly. This works fine on earlier versions of Maemo but in Fremantle I can't click in the widget or enter text into it. Any ideas what is wrong? Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Entry widget in Fremantle toolbar
in the toolbar Ah sorry, misread, ignore me :) Simon -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Graham Cobb Sent: 02 September 2009 16:06 To: maemo-developers@maemo.org Subject: Entry widget in Fremantle toolbar GPE Contacts has an entry widget in the toolbar so people can enter searches directly. This works fine on earlier versions of Maemo but in Fremantle I can't click in the widget or enter text into it. Any ideas what is wrong? Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
OpenGL is not available in the device but OpenGL ES2 is. Notice that this is a big problem when porting OpenGL applications from the desktop PC world. Some kind of OpenGL to OpenGLES conversion layers are possible but with some FPS cost, I assume. Something like this perhaps, I imagine there are also others: http://forum.openhandhelds.org/viewtopic.php?f=14t=884 Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Location framework question
Hi all, Just a small question about the location framework, I understand that the framework will use different backends, in the same sort of way that GeoClue does (see [1]), are we allowed to know what backends will be available? GPS is in there, what about things like WiFi access point locations (i.e. the same thing that the iPhone does) and cell tower id numbers? I'm just wondering how continual the reporting of the location information will be, and therefore what sorts of cool apps would be possible. I'd also be interested to know the power hit that using things like the GPS and communicating data will have on overall battery life. Not much point having a cool context/location aware app that tracks your movements if it halves your battery life, etc. Cheers, Simon [1] http://wiki.maemo.org/Task:Maemo_roadmap/Fremantle#Location_framework ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Am Mittwoch 03 Juni 2009 schrieb Qole: I really want the next Maemo device to succeed, and one of the first things the gadget blogs and technophiles will want to see is the games. This means Playing games? What input method do you expect to use? Till Bluetooth games controller/kb! :) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Gsoc Idea Barcode Reader
Producing a useful interface to let people obtain a decoded string/etc. from whatever sort of barcode is a worthy goal (and having the code select from a range of decoders preferably), as is improving the speed of some of the 2D decoders, as is producing web scraping functions that could be used to obtain info about a decoded barcode. This came up in discussion recently on irc. Can I suggest you look at providing a dbus interface. This should give you hooks into a few areas and some well defined but well linked breakpoints for the project. It also lets you link to non-python solutions. Absolutely. C/C++ is a better choice for the decoder parts anyway as they have to be fast and memory efficient. The C/C++ library which performs the barcode decoding functionality would then be wrapped to allow its use in Python, etc. I've added a page on the wiki with some thoughts about areas that could be attacked by GSoC (and in general for that matter). I've not added any links to examples (e.g. Delicious, Andoid Scan) to illustrate my thoughts yet. Please feel free to add ideas/comments (and please say who you are when you do so). Thanks, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Gsoc Idea Barcode Reader
I've added a page on the wiki with some thoughts about areas that could be attacked by GSoC (and in general for that matter). I've not added any links to examples (e.g. Delicious, Andoid Scan) to illustrate my thoughts yet. Oops, might pay to add the link of course :) http://wiki.maemo.org/GSoC_2009/Barcode_scanner Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Gsoc Idea Barcode Reader
Also, i think we should look at GOCR as the alternate toolkit that can be used for the project. Looks like that project has been renamed to Conjecture now (http://www.corollarium.com/conjecture/). Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Gsoc Idea Barcode Reader
Also, i think we should look at GOCR as the alternate toolkit that can be used for the project. Looks like that project has been renamed to Conjecture now (http://www.corollarium.com/conjecture/). Reading the EAN-13 barcode should not require to complicated ocr software I think the basic is to draw 3 lines over an image , make it black white and look for known patterns (first only a series of black white and then looking at the length). Do you think I am underestimating this part of the problem? No you're not underestimating it really, though in real life the black and white are not so black and white, more shades of grey ;) Anyway this particular part of the problem (1D decoding) has already been solved many times and it seems somewhat pointless to do it again (as the existing 1D codes are pretty fast). Producing a useful interface to let people obtain a decoded string/etc. from whatever sort of barcode is a worthy goal (and having the code select from a range of decoders preferably), as is improving the speed of some of the 2D decoders, as is producing web scraping functions that could be used to obtain info about a decoded barcode. I'm sorry I've been pretty busy in the past couple of weeks, but will write up some (useful, I hope) comments regarding this project (on the wiki page? Or on the GSoC page?). Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Gsoc Idea Barcode Reader
Hi Steffen, some month ago i tried to port http://zebra.sourceforge.net/ to the maemo platform. The Zebra Barcode Reader can decode barcodes from a live video stream (v4l) an static images (jpeg, bmp, etc.). Thanks for the pointer. For maemo-barcode we currently use the main logic provided by the Batoo project (http://people.inf.ethz.ch/adelmanr/batoo/), but it looks like zebra decodes more types of 1D barcode so I'll have a look at it. If im informed correctly, the n810's webcam has also a v4l interface that could be used for the barcode decoding. It should be quite easy to port it. Its coded in C and its sourcecode is available. I'll try to get it compiled in the week. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Gsoc 2009: Barcode Scanner
I am interested in working for maemo in this year's Gsoc. I am in particular interested in the idea 'Barcode Scanner' listed on maemo's idea page for this year's Gsoc. I have quite a lot of experience in Python and hope to use the same for the development purpose. Dunno about GSoC, but take a look here: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/branches/simon_wip/maemo-barcode/?root=maemo-barcode In C though I'm afraid. hacky binary here: http://people.bath.ac.uk/enpsgp/nokia770/maemo-barcode/ I've been developing this (slowly) from the test code a group of us put together last year to test 1D barcode recognition (and others - QR, dtmx, etc.). I've been very slow as I've had little time and have also needed to learn the wonders of SQLite and GTK+ (~lart listboxes). The code is pretty messy, but hopefully the idea is clear: Barcode scanner, with web-lookups and various lists into which the barcodes and their web-looed-up data can be saved (e.g. DVDs I own, DVDs I'd like, etc.). My driving force was the fact that I have lots and lots of books, and can never remember which ones of a series I still need. I was hoping to get this all cleaned up far more before putting it out for public consumption, but all the talk of GSoC made me realise there's little point in people re-doing the bits I've already done (though some may vote to wipe the slate clean of course ;)). I'd be more than happy to have some help to speed up cleaning things up and getting everything working (for example I've just noticed that my data view doesn't currently update when you add a new record, search dialog is currently un-implemented, probably lots of bugs in the GUI actually, same for the database code too I imagine), web-scraping functions are currently stubs, the GStreamer output wasn't bring displayed when the analysis loop is running (loop too tight?), etc. Apologies for unleashing this mess on the world! ;) Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Reliably Getting Position Information From Gstreamer
Hi Nick, I'm trying to figure out if there's a bug in Maemo's gstreamer or if I'm doing something wrong. It seems that if I seek too many times in rapid succession gstreamer will report a false position (normally 0) when query_position is called. I hacked together a sample player[1] that demonstrates this behavior (from the pygst tutorial example 3.1). Once the file starts playing seek_from_current is called once every 0.1 seconds. On a regular Linux desktop it works perfectly, but on Maemo the song will end up being reset to 0 every few seconds (this is because query_position is reporting a wrong number that's 0 or close to it). The DSP GStreamer sinks (and for mp3 you'll be using the dspmp3sink) have problems with returning their stream position afair. These was a question long ago about why the DSP continues to run at full pelt when the player is paused and iirc it came down to the fact that the DSP could not accurately return its current stream position and then (accurately) start from there again. This is my guess of what's causing your problem, but I'm sure one of the Nokia/Gstreamer chaps will be able agree/disagree with this and point you in the right direction. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to create a BMP image using c or python
hi All, I know that Jpeg image can be created with Gstreamer , while how to create a BMP format image by c or python? Any help would be appreciated, thanks in advance! Google? A bitmap is just a header followed by the data (which can just be raw data if you don't want to implement RLE code). E.g. format of the file: http://en.wikipedia.org/wiki/Windows_bitmap and here's an implementation that you could copy and change: http://cpansearch.perl.org/src/DHUNT/PDL-Planet-0.05/libimage/bmp.c All you need is some data and stdio.h Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: How to create a BMP image using c or python
Look at this: http://maemo.org/development/documentation/manuals/4-0-x/how_to_use_came ra_api/ You can replace the create_jpeg() fn with one that does what you want with the buffer of raw data that is passed to it. Simon -Original Message- From: dongmei zhou [mailto:dongmeizhou2...@gmail.com] Sent: 23 February 2009 12:37 To: Simon Pickering Cc: maemo-developers@maemo.org Subject: Re: How to create a BMP image using c or python hi All, Thank you for your tips and I want to add a point that I want to get BMP file form N800 camera,You know that we can get jpeg file through Gstreamer got from N800 Camera, what about BMP file? 2009/2/23 Simon Pickering s.g.picker...@bath.ac.uk hi All, I know that Jpeg image can be created with Gstreamer , while how to create a BMP format image by c or python? Any help would be appreciated, thanks in advance! Google? A bitmap is just a header followed by the data (which can just be raw data if you don't want to implement RLE code). E.g. format of the file: http://en.wikipedia.org/wiki/Windows_bitmap and here's an implementation that you could copy and change: http://cpansearch.perl.org/src/DHUNT/PDL-Planet-0.05/libimage/bmp.c All you need is some data and stdio.h Cheers, Simon -- BRS! Thanks! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Does anyone know the mechanism in Nokia's LCD driver?
Would the manual mode help to avoid tearing? Yes, and it does help to avoid tearing. At least this works fine for XV extension. But getting tearfree scrolling/panning in GTK applications for example is a bit more challenging. I can provide a more detailed explanation if anybody is interested. Yes please :) Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Need information about GStreamer elements
Just to clear more, I only have stream of raw data to play. When you say raw, what type of raw? i.e. there would be differences between playing raw pcm data if it's alaw or ulaw, etc. I was able to play it using playbin and setting its URI property with 'file:///xxx'. What was the xxx in the above? Do you have a sample? Cheers, Si -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers-boun...@maemo.org] On Behalf Of Vikrant Mhaske Sent: 12 December 2008 05:56 To: 'Vikrant Mhaske'; maemo-developers@maemo.org Subject: RE: Need information about GStreamer elements Just to clear more, I only have stream of raw data to play. I am ignorant about its type or anything. I know I have to use some low level element as source element. I was unable to find such source element which takes only raw data as a source. Any pointer in this regard would be appreciated. From: Vikrant Mhaske [mailto:vikrant_mha...@persistent.co.in] Sent: Friday, December 12, 2008 10:45 AM To: 'maemo-developers@maemo.org' Subject: Need information about GStreamer elements Hi all, I have been trying to play audio file inside maemo. I was able to play it using playbin and setting its URI property with 'file:///xxx'. But the thing is, in my application I get the stream of type say iostream from internet. Now how could I use available GstElements to play this stream. Playbin only allows me to use file or http protocol to specify source. Regards, Vikrant Mhaske DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
the unstable repository--whatever, so the user decides (perhaps with the encouragement of some of their peers) to dive in, add the unstable repository and install the application. Use an install file to install the application in question? Assuming the application needs libraries which are contained in the extras-devel repo, you'd need to temporarily enable that repo. My feeling is that the repos enabled/added as part of install files should be disabled immediately after the app in question has been added in any case, so I suggest this change is made to the way Application Manager handles the install files. Would that achieve the desired goal? It would require that a list of application install files are available (perhaps auto-generated from the contents of the repo, or perhaps by the author in question?) packages origin (color coding, a small icon) and notices might also help (this package is unstable software, and may contain many significant bugs, are you sure you want to install it?), or even some sort of apt pinning system to ignore certain updates. I also like the idea of flagging applications that come from somewhere other than Extras, and I suppose it would be possible to have an Updates section with Stable and Unstable candidates in it (or perhaps allow updates to be sorted by their origin repo - and have Extras as the default origin). But these are still more for power users, simply disabling the repo immediately after use is imo a better bet for unskilled users. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Beyond Application Manager Categories
But the current AM is a pretty unfriendly place for browsing a long list of available applications. In the past, I kept saying that I don't want the AM to turn into a portal for applications, that should be left to the browser. We have downloads.maemo.org, which is this portal. Are people using it? As a thought experiment, could we remove the Browse installable applications button from the AM and get by with just downloads.maemo.org? Should we work on better integration? Definitely not until the browser works faster and it's easier to click links. For me, AM is far quicker and less frustrating than having to browse that site (slowly) and click the little links. There is another angle: many applications are extensible with plugins and add-ons, etc. There is a lot of potential there to simplify juggling with these packages. For example, there is no point to even show the pidgin-l10n-klingon package if you don't have Pidgin installed. This add-on management is probably a bit hard to do for a portal site like downloads.maemo.org. But the current AM is not much better. We spoke about this before (not sure whether it was on the list or not, does anyone have a link - Jaffa?), but basically I would like to be able to see what plugins an app has before installing it. I might want to see if Pidgin has current support for Gadu (or any other protocol, etc.), I'd prefer not having to install it to be able to see the available plugins. I do agree though that hiding them would clean up the list and would be suitable for most of the time (though it should be possible to unhide them if needed). Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: ALSA PCM DSP Plugin
Can anyone tell me if the dsp tasks for pcm output allows non-blocking calls and if it supports async operation via callback/semaphore? You should be able to tell by looking at the ARM-side (and available) source for the Gstreamer DSP plugins. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Projects Nokia should support (yours?)
On Mon, Oct 27, 2008 at 10:35 AM, Fred [EMAIL PROTECTED] wrote: Would VLC (http://www.videolan.org) be a good client ? There was a port for Maemo but it was underpowered. It has the capacity to be embedded and could be a very good all-purpose (all-codec) media player ... Perhaps this is one of the days when VLC developers regret the decision to not synchronize/collaborate with GStreamer when GStreamer was there? Since Nokia supports GStreamer for very obvious (to the maemo community) reasons, supporting a competitor project wouldn't be a very wise idea. DISCLAIMER: This is my very personal opinion and it may very well be wrong. Agreed, we have officially supported GStreamer and the excellent mplayer which can be wrapped if someone wants a (different) gui. VLC certainly doesn't classify as a killer app bearing these in mind IMHO. Something with more mileage, though still not really a killer app, would be working on optimisation of the backend libs that all three media players use (therefore any media player would benefit). But this will have to wait until we see what the hardware is capable of really. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Proposal for Diablo's authoritative list of package categories
- Development worklow? Do you want to have a structured process with an agreed set of features in scope, a UI plan and so on or do you see better to continue the ad hoc approach of discussion+patches? Specially if you expect us providing i.e. nice icons this is not something that needs more planning from our side. I think some formalised set of features would be useful, especially to draw in more developers (so they know what's going on and who's doing what and what they could do). Though we should leave it somewhat open-ended and allow extra features to be added to that formalised set as and when they come up and are discussed (otherwise people might get bored as they can't hack on what they want to do). - Collaboration channels? Do you want something like a garage environment + git + bugs.maemo.org or do you prefer to continue the thread in maemo-developers? Personally I'd prefer a Garage project/environment, that way it's all centralised rather than being mixed in with the more general maemo-developers list. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Application manager category view proposals
Having thought about it a bit more, I think there are 3 realistic scenarios: 1) Force the Application Manager to do it, based on a simple rule like having an i18n label defined. 2) Force the Application Manager to do it, with an external package defining the metadata. 3) Force the Application Manager to do it, sourcing the metadata from *.maemo.org I like #3 personally. In all 3, I think there's a case for a setting which ignores this. Then, if someone is selling tablets with a bespoke environment, they can still push updates from their own repository which only applies to their walled-garden users, not general mainstream end-users. Just allow the Red-Pill mode (for example) to disable updates. Then anyone who wants to can manually alter their own cached/local Sections list and leave it be. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: printing logs (printf) when application starts from menu
I wrote an application named My_app that plays audio and also records voice from microphone. I usually use this application from command prompt. There are lots of printfs in it for debugging purpose which gets printed on terminal when the application is run. I just put the application in the start menu and it does not behave properly as it should. More particularly the recording from mic is problematic. I have no way of accessing the printf at present as the application is starting from Start Menu - Extras - My_app Is there any way that I can get this printf printed in some file when I start this application from the menu. It will be still much better if I can open another window and it keeps printing the printf even when I start My_app from the menu. Sounds like this would be a useful feature for the hildon-launcher to support. I would like to see hildon-launcher reporting errors to some central server (a la M$ Windows error reporter) and any stdout/stderr output would would be a useful thing to have. This reporting tool does actually exist within Nokia for internal testing, but would probably also be useful for the outside world, obviously with tweaks to where the debugging information is sent. I remember on Opie (running on the Zaurus) there was a central log screen which showed the output of all of the Opie applications. I wonder if this would be an option, or perhaps just automatically piping the output from individual applications a pid-specifc temporary log file under /var (which could then be sent off with an error report should one occur, or would otherwise be deleted when the app closes). Hildon launcher is here: https://stage.maemo.org/svn/maemo/projects/haf/trunk/maemo-launcher/launcher/ Have a look and see what patches you think might do the job. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Projects Nokia should support (yours?)
It's a little unclear whether it's targeting volunteer developers working on this in their spare time who might be interested in making a living on it, or companies who are working on free software, or volunteers who just want a hand, but are very happy staying volunteers. We are referring here to community projects, which imply open planning and development. In practice this calls primarily to volunteers and open source code but maybe there are exceptions worth considering - you decide. Sounds good, so where shall I lay out initial ideas for how I'd like maemo-barcode (name to be changed, suggestions welcome as part of this process) to move forward and to get suggestions and help in doing this? In the Garage project itself on its mailing list, or on some more visible page (in the wiki perhaps)? I'm all for this, my gut feeling about why projects never quite make it is that the (probably sole) developer runs out of time/motivation/moves on to other things; with collaboration there is more motivation for developers to keep working (moral support and karma) and even if someone drops out there are others to keep going with it. Financial support is always nice, but I do wonder how that will work with the idea of community collaboration and projects with multiple contributors. Certainly it would be good for specific (perhaps odious) tasks (vorbis on the DSP for example, as there's no other way to motivate it afaict) but perhaps not for applications unless they really are one-man projects. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Projects Nokia should support (yours?)
I still don't know if I can propose an application that is not started yet. Just in case you don't remember, I explain my idea again. My goal is creating a GPS position sharing client. What this application will do? I try to explain in few simple steps... snip 3) you start adding other people to your contact list and you choose if you want to share your GPS position with them (I suppose yes, else why you add them?? :P ) There is already a method of providing location data over the XMPP/Jabber protocol which the built in messenger uses (thought it's not implemented at the moment): http://xmpp.org/extensions/xep-0119.html By using the existing IM infrastructure you'd not need to register anywhere, you just tell and obtain position info from your existing contacts (which is fine IMO, I don't want any old person, even if they register on some website to know my position). 4) At this point, when you walk around in your city, in your country ecc... and you're connected to internet (with UMTS you can be always connected, right? I use to be always connected using N810+N73+Tre Italy UMTS), you can share your position to your contact list. snip Think about a situation like we were in Berlin: - Hey John! Where are you? -- Well... I'm... at that corner... don't know the street name... uhm let's try to get at McDonald... - Which one? There are at least 3-4 McDonald here! this is just an example where those two people could use it. I think there are lot of situation where real time gps position sharing could be usefull. Yes, sounds nice. Though I'd focus on trying to find the beer gardens ;) I hope someone find this idea interesting. Please, don't limit to steal the idea, let's try to create this together. Quite, will presence data and for that matter GeoClue as a location provider be available in Freemantle? Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Projects Nokia should support (yours?)
3) you start adding other people to your contact list and you choose if you want to share your GPS position with them (I suppose yes, else why you add them?? :P ) There is already a method of providing location data over the XMPP/Jabber protocol which the built in messenger uses (thought it's not implemented at the moment): http://xmpp.org/extensions/xep-0119.html Sorry, should probably be this one: http://xmpp.org/extensions/xep-0080.html Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: ALSA sound driver for Nokia 770 and DSP programming
Recently I have been trying to make it running and seems like we have a very good chance to have it working nicely. It is also interesting, that the linux-omap guys seem to be developing a new driver [3] for AIC23 which may eventually become a better alternative. Very nice! Good stuff Siarhei :) Have you built a replacement DSP-kernel yet? I will try your patch in mamona which IMO provides the most easy way to test those things out. Mamona is based on OpenEmbedded and every other distribution made from it bases its sound core on ALSA not gstreamer ... Sounds like a useful test-bed. It is good that a new driver is in development, however I have doubts that we will be able to run 2.6.27+ on the N770 soon ;). Is the AIC23 also in the N8x0 devices? From the N810 datasheet, it looks like it contains a TVL320AIC33NIZQER, or in shorter form a TVL320AIC33: http://focus.ti.com/docs/prod/folders/print/tlv320aic33.html I seem to remember there being something different in the N800, anyone got the datasheet handy for the N800? Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo-mapper vector data backend follow-up
Hi Till, do you want an honest reply: Don't do that. Maemo-Mapper isn't meant to handle vector data. Period. Indeed, but maemo-mapper will not be handling the vector data, that will be the job of the render/routing server; maemo-mapper will continue handling bitmap data. These are my concerns: - Plenty of duplicate data will get stored that isn't required since Maemo-Mapper will locally cache tiles that have been generated on the device itself. This can be disabled - only a memory cache is used, no file cache; though it might be useful to cache the tiles to a file cache and clear that when the app closes to avoid unnecessary processing when panning. I don't know. - Rendering is less than optimal because Maemo-Mapper asks for tiles. You'd have to a) render most things several times as most objects will span several tiles and b) have to render more data than required as Maemo-Mapper does some caching in advance. True, this then boils down to how fast the rending can be performed and with what CPU load. - You'd need massive interfaces between your renderer and Maemo-Mapper for all kinds of interaction with the maps. You'd e.g. have to communicate POI details, street details, etc etc ... Well the only interfaces that are really required are ways of sending rendered tiles, and sending GPX routes from A to B, and lookups of the lat/long of POI locations/street locations, etc. - The entire thing will not be trivial to use and debug as you are basically planning to cut an already complex navi application into two parts which then need proper coupling. I'm sure it won't be trivial, but the rendering engine and routing engines should be pretty well self contained, I can't see why it should be any more difficult than it appears at first glance. - All navigation functionality of Maemo-Mapper is imho done on an external server in advance. You'd also have to port a navigation engine onto maemo and couple it with maemo-mapper as well as with your tile renderer. Indeed, this is the idea. I'd rather use software that was designed to use vector data. E.g. navit has been ported to maemo by a bunch of people incl. myself. We all didn't put much effort into this and the results are barely useable. But it's imho way more effective with respect to vector data to continue with a program like navit than Maemo-Mapper. You are probably right there (certainly things like 3D views are outside the scope of maemo-mapper), but there is a desire to support local vector-data backends, and this is a discussion of whether it can be done. I fully support the work on Navit and other navigation/mapping programmes, this is simply looking at an expansion of the abilities of maemo-mapper. Regards, Till Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo-mapper vector data backend follow-up
Hi all, A few of us sat down with John Costigan (aka Gnuite) after his presentation at the Maemo Summit and as well as drinking a few beers/vodkas discussed how to achieve the end goal. I just thought I'd start the conversation going here and summarise my thoughts (John has probably not even made it home yet!). For those who didn't see the presentation, it was basically asking for input on how to use vector data as a backend to provide tiles and routing information, without needing to completely re-write Maemo-mapper and change the way it handles data. The idea that John presented was that we should store the vector data locally and act like the OSM/Google server and serve Maemo-mapper with image tiles and route GPX data in just the same way as already happens. The advantage here is that the two projects are pretty well separated (though John said he'd be happy to make alterations to Maemo-mapper if needs be). The other positive aspect of this split is that if someone were to reverse engineer the TeleAtlas/Navteq storage format, which might be slightly controversial, it wouldn't impact on Maemo-mapper or any other backend (e.g. OSM). So, considering OpenStreetMap as our vector data set (Garmin is another option as I believe there's an open source library which can understand their database format; likewise for British University users Ordnance Survey data is available; and for those in the US there is Tiger census data; world-wide NASA Shuttle Radar Topography Mission contour data; i.e. there's at least a few sets of data which could be used), these are my initial thoughts. The OSM data is stored in a MySQL data base (though the data we download as *.osm is an XML dump I think); there is an API to query the database using XML. As we'd already be running as a server, and would gain no advantage in using the API should the database format change (as we access the database directly, so need to implement the db-side of the API), I would propose we ignore that, and act on the data directly, should we decide that it doesn't need pre-processing. The only disadvantage to this, it that if we implemented the API, we could also work online and talk to the main OSM database directly. Not sure how much use/interest there would be in that. Thoughts? So, we have some data, now we have to be able to do something with it. There are a number of programs which can render OSM data that we should look at adapting rather than writing it all from scratch. Tile rendering == There's a list of OSM rendering programs here [0]. Mapnik [1] is the program which renders the map tiles currently downloaded by Maemo-mapper. This requires that the OSM MySQL database be processed and turned into a PostGIS database. It doesn't look like this is something that could be done on-device due to the time and memory requirements. PostGIS rendering is probably a good thing as other map data is stored in this format. This is supposed to be difficult to setup though, and I don't know the cpu/memory requirements. Other applications such as Navit [2], Gosmore [3] also require that the database be processed to turn it into something other than MySQL. Pyrender [4] might be a possibility, though it is designed to work from a tile server (where a tile is a tile of metadata rather than image data) rather than the MySQL database. I'm tempted to quickly pull together something using pyrender (it currently parses XML directly afaik, so will need some tweaking to read from MySQL if that's the backend of choice). Using a proper db rather than parsing the XML should hopefully allow it to scale better than it is supposed to do atm. Obviously C will be faster, but perhaps more people will get involved if it's Python...? Any thoughts on this? Navigation/routing == Again, there are a number of programs which do this [5]. Again Gosmore [3] and Navit [2] and another Python program, Pyroute [6], are on the list. I don't know much about these, how processor intensive they are or how fast they are. Does anyone have any ideas? Pyroute appears to use raw OSM vector data (though not as a MySQL database as that's not a dep, unless that's assumed for a Python install?); Navit and Gosmore both use their own converted data formats. Again I'm tempted to try using Pyroute with a MySQL db. Same arguments as above. So to summarise, it looks to be possible. Let discussion commence! Cheers, Simon [0] http://wiki.openstreetmap.org/index.php/Rendering [1] http://wiki.openstreetmap.org/index.php/Mapnik [2] http://wiki.navit-project.org/index.php/OpenStreetMaps [3] http://wiki.openstreetmap.org/index.php/Gosmore [4] http://wiki.openstreetmap.org/index.php/Pyrender [5] http://wiki.openstreetmap.org/index.php/Routing [6] http://wiki.openstreetmap.org/index.php/Pyroute P.S. Rana is a combination of Pyroute and Pyrender, search for it on the osm wiki. ___ maemo-developers mailing list
Re: Maemo-mapper vector data backend follow-up
Hi Pierre, I have been looking at pyrender and did try recently to have a on the fly vector map rendering in python. It was so slow i decided to use pre made tiles instead. Hmm, ok, well that's indicating that we should use C then. I also used most part of pyroute to try to make off line route calculation: http://sayhoo.garage.maemo.org/ It works but it eats too much memory. Thanks, I'll take a look at that - is it because it stores the data in memory rather than using a db? I also dont know how one could represent big enough a route to connect 2 foreign city (but, as i do not own a car, this is only a theoretical problem :-) ) I had been thinking exactly the same thing, how to parse the database and chose the route without needing all of the data in memory/a very long time. Presumably this problem has been solved and there must be papers which explain either how to pare down the data, or how to store memory-efficient route representations. Obviously it could be done by iteratively loading the data for a given area, not sure how much memory would be needed to store the possible routes though as it iterates along the path. Sounds interesting :) Navit is supposed to be able to do general routing (beyond a single city which is stated as a limitation of Pyroute due to memory reqs. see http://almien.co.uk/OSM/Routing/), so looking at/transplanting that code might be a starting point (and it does rendering too). Those graphs on the link above look cool :) Anyway, good to see that there are others interested in the topic :) Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Moderator speak up - is maemo multitouch thread ok or not
Someone else mentioned possible patent infringements, I don't know how much of a factor this is. Who said so ? What parent infringements ? I have carefully analyzed patent applications by Apple and full-text patents granted to Apple and there is nothing what can be infringed with another multitouch solution by Nokia, Samsung, Google or others. Just learn to read patent law and patent full texts. Great, I have some experience with reading patents (mainly for Jazelle), could you give us the patent numbers (preferably US patents so we can use the Google search) so we can also look at them? putting together good business cases to say how multi-touch will be beneficial ask Steve Jobs I don't have his email; do you? No-one is stopping you, in fact if you can get the non-multitouch resistive screen to produce useful multitouch-like behaviour, which is what Gary (lcuk) has been looking at, I'm sure we'll all be very pleased. Who is Gary ? Gary is lcuk on IRC. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Moderator speak up - is maemo multitouch thread ok or not
I am really surprised, there is a small group of maemo developers showing interest not to discuss maemo multitouch and showing interest to have maemo no-multitouch in next years. I think Igor was fairly explicit in what he said, capacitive multi-touch was not very precise, therefore a resistive screen was chosen. This is fine by me as I do want to have very find control over where I click with my stylus. Someone else mentioned possible patent infringements, I don't know how much of a factor this is. I'm not sure anything we say will affect this, though putting together good business cases to say how multi-touch will be beneficial (and being explicit about how) would probably be a good start (in the same way that we have been justifying why the PowerVR driver should be released, etc., on the wiki). Quite contrary to iPhone developers , doing their best to make iPhone No.1 gizmo. Not through their discussion of multi-touch mind you :) Multitouch is hot and market added value. You can try to stop multitouch development but please offer something better. No-one is stopping you, in fact if you can get the non-multitouch resistive screen to produce useful multitouch-like behaviour, which is what Gary (lcuk) has been looking at, I'm sure we'll all be very pleased. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
dsp-sbc and video output problems
Hi everyone, As at least some of you know, the dsp-sbc task works (for all the music I've tried anyway, but I know there are some oddities, which I'm going to investigate - e.g. qwerty's music ;). This is all well and good, but we don't gain much, except possibly better battery life if we scale the CPU speed right back while we decode (and even then I don't know if it will be more efficient). The goal had been to offload sbc encoding to the DSP to allow e.g. mplayer to use more cpu to do video decoding. I and others have done some testing with the dsp task, and with the cpu at 400MHz, although the sbc encoding works fine, the video stutters quite severely (producing 1fps output). This is obviously not workable, so it needs fixing if possible. I've converted the existing task, which uses bulk transfers (where the copying is done in the kernel) to use shared memory and word transfers for synchronisation. This should cut the amount of time the kernel spends doing memory copying by some significant margin (i.e. ~4 bytes data copied rather than 512+78 bytes per transfer, of which there are 375/sec). This hasn't improved things though, the video is still at 1fps. Before I look at DMA or other exotics, I thought I'd ask if anyone knows about the bandwidth limitations of the memory controller/memory? The dsp mp3 task which works with mplayer while displaying video consumes (not quite sure how to work out exact bitrate here), let us say a 5Mb file in 3min or so, which gives 28.4kb/sec (kilobytes that is). My sbc encoder eats 48000hz stereo 16bit data, which equates to 187.5kb/sec input. It also spits out 78 bytes for every 512 bytes it reads in, which adds an extra 28.5kb/sec to the total bandwidth requirement. So, am I running up against a fundamental limitation of the memory architecture? Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Navigating on OSM data on maemo
The big issue at the moment is that the OSM data (which is what I'll be using at least as I don't have any Garmin maps for Navit) lack certain metadata which would be useful. The main thing here is the road speed, or some indicator of what the road speed might be (e.g. road type data - in town/country/etc.) currently you will have difficulties to determine if a way, for example, is in a certain country or within a residential area. I guess it still will last a while until we have enough such data in our database. There are probably some hacky ways around this in the absence of the actual data, avoiding a given radius around a town location (and perhaps even caching data on the population so we know what radius, or knowing the radius itself if this is available). Obviously bypasses will probably not work too well with this though. Hacky as I said ;) But does it matter right now? Some examples already show that routing based on OSM data is possible, and that the results can copete with the results of commercial routers. No, not really. We may as well get a handle on how to do routing at least. One thing that might be complimentary to the existing on-line routing methods is calculating tracks back to the existing route (e.g. if you stray or need to divert), in this case it wouldn't matter too much about the speed of the road as the distance wouldn't be too great. BTW: There's some discussion about standardizing a binary file format for mapping applications @OSM-dev (Call to mobile developers: OSM binary file format). No clue if it will be successful, but at least there's a wiki page :) : http://wiki.openstreetmap.org/index.php/OSM_Mobile_Binary_Format Thanks, I'll take a look at that. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Navigating on OSM data on maemo
I am wondering if currently anybody is working actively on porting navigation software with offline routing to maemo with osm data. I know that somebody worked on navit somebody else on Gosmore, but I have not seen updates since a long time...is there anything else going on? Navit could be a perfect companion on Maemo. Compiles, runs and routes nicely - as long as there's no gps signal... :( Unfortunately it frequently freezes as soon as gpsd is running. Unfortunately my C knowledge is rather nonexistent so I cannot debug or improve this behaviour. There are (rather dated) packages on [1]. The author asks for patience regarding updates as he's working on some stuff. These updates are apparently a new GUI and routing in libgarmin. I am certainly interested in navigation software (thanks for pointing out gosmore, I'd missed it). The big issue at the moment is that the OSM data (which is what I'll be using at least as I don't have any Garmin maps for Navit) lack certain metadata which would be useful. The main thing here is the road speed, or some indicator of what the road speed might be (e.g. road type data - in town/country/etc.) I imagine there may be ways to get around this and still have a half decent routing system, and then implement these sorts of checks once the metadata catches up. I've not been able to try Navit (probably due to the mentioned gpsd problem) - it never wanted to do anything when I was running it. I'm more tempted to take a stab at gosmore as I assume it will be simpler code and easier to hack and modify ourselves. I should add that onion is planning to add routing abilities to his fork of maemo-mapper (see here: http://wiki.openstreetmap.org/index.php/User:Onion/Mapper#Todo_List) so developing a bear-bones routing system would probably benefit lots of different projects (and most of all, be interesting to do). Anyway, count me in :) Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Navigating on OSM data on maemo
I am wondering if currently anybody is working actively on porting navigation software with offline routing to maemo with osm data. As well as the previously mentioned: Navit (http://wiki.navit-project.org/index.php/OpenStreetMaps) Gosmore (http://wiki.openstreetmap.org/index.php/Gosmore) There are a couple of others which should be mentioned, which can use (free) OSM data. See here: http://wiki.openstreetmap.org/index.php/Routing E.g. Roadnav as preliminary support for OSM (http://roadnav.sourceforge.net/). It says it can do navigation to anywhere in the USA, but with the right maps I suppose this would scale to anywhere. Pyroute/Rana does/do routing in Python using OSM data (http://wiki.openstreetmap.org/index.php/Pyroute being replaced by http://wiki.openstreetmap.org/index.php/Rana) There is a mailing list linked from the osm routing page, as well as a couple of other wiki pages about routing which would probably be worth reading. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: PowerVR MBX driver for Maemo?
We are not providing it at the moment for legal / Licensing reasons. The current closed source driver for Omap 2420 is not GPL compliant and Nokia can't deliver such a driver. We are working to get some version of driver available to developpers but it won't be any Nokia supported version. The plan is least tell in Maemo Summit could we resolve existing problem and make driver some way available. More info from https://wiki.maemo.org/Talk:Drivers_justification Thanks for that Kate :) Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: DSP SBC encoder update
I should add that running DSP tasks will move the CPU frequency to 330MHz, so this is probably not the answer to everyone's prayers with regard to freeing the CPU to do Xvid decoding or the like. There is a kernel patch to not force the CPU to 330MHz (the DSP runs slower) and I'll do some testing to see if the DSP task can run in real-time at the lower DSP clock speed. Then it will be significantly more useful. Right, I've tested the SBC encoder task with the ARM running at 400MHz (and therefore the DSP running at 133MHz (rather than its top speed of 220MHz with the ARM running at 330MHz). Thanks qwerty for the link to the patch. Anyway the task runs and plays music, but there are far too many drop-outs and the sound gets progressively deeper on the run up to each dropout (due to the encoder being too slow). So it certainly needs more optimisation before it could be considered for this role. The change which has allowed it to encode an entire song rather than just a few seconds was to move the input and output buffers from SDRAM (OMAP main memory) to SRAM (DSP fast single access memory). There are probably other things which would benefit from being moved, the sbc-priv data (or parts thereof) for one. This structure is pretty big so I allocated it in SDRAM, but at least parts of it might be better off in faster local memory. This is something to look at. I looked at this yesterday evening (thanks to derf, crashanddie, and others for answering my C questions), trying to move some parts of the priv structure to SARAM (sorry for the SRAM typo above). Unfortunately just moving the bare minimum (the X array) won't happen as there's not enough SARAM (so dsp_dld tells me). I don't know where it's all gone, anyone have any ideas? I currently have a fast_in[] array in SARAM to which I copy part of the data from the slow (SDRAM) X[] array in the sbc_analyze_eight/four() fns before it's used in the _sbc_analyze_eight/four() fns. These two fns are inlined, so this memcpy is performed in every loop through the code (called something like 150,000 times in total for my test file iirc). I'm not sure if the faster manipulation of the data makes up for the copy overhead (it is a faster 32bit copy at least). No clocks available, so I'll try removing this optimisation and testing what it sounds like. More importantly, if the whole X array could be placed in SARAM, there'd be no need for my memcpy anyway and I'd have the benefits of faster access. I'm not too sure how to analyse the code to work out how much data is allocated in SARAM (to work out if I'm close to fitting it or have no chance). Talking about SARAM, the input and output buffers (which the dsp task uses for bulk transfers) are in SARAM, this is what I changed to make the task play in real-time so this obviously makes a difference. It would be good if I could avoid having to copy from the input buffer into one of the priv structure arrays (which holds the PCM data). This is probably not really a big saving compared to optimising the main loop as the read fn is not called all that often (~5000 times for my test file), but every little helps and obviously did before. The input array is currently read into a 2D array, I need to check and see the array dimensions and whether I could write the data into it directly (and place it in SARAM rather than the input array). The output array has data packed into it, so I'm not sure I'll get any savings from fiddling with this. There may yet be other little bits of code which would benefit from being moved to faster memory (or intrinsic-ised), it's just a bit hard to quantify the memcpy slowdown vs. any possible memory access speedup gains without any way of timing individual parts of the code :( I'm currently revisiting my attempt to re-write the inner loop to use lots of DSP intrinsics and the like in the hope that this will provide some sort of speed up. Again to be tested with the mk1 ear ;) Anyway, that's about where I am. If anyone wants to take a look at the code and suggest possible locations for optimisations I'm all ears :) Thanks for reading, Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: DSP SBC encoder update
I looked at this yesterday evening (thanks to derf, crashanddie, and others for answering my C questions), trying to move some parts of the priv structure to SARAM (sorry for the SRAM typo above). Unfortunately just moving the bare minimum (the X array) won't happen as there's not enough SARAM (so dsp_dld tells me). I don't know where it's all gone, anyone have any ideas? Do you use any buffers allocated by malloc? My guess is that malloc does allocation of DARAM and SARAM memory. In any case, memory returned by malloc should be not worse than the memory buffer explicitly statically placed to EXTMEM. Yes, I think you're right, in the avs_kernelcfg.cmd file it talks about a DARAM_heap and a SARAM_heap, presumably it's possible to allocate from either somehow (using the CSL MEM_* calls probably, I don't know off hand which heap is used for task data, but will have a look this evening). It also talks about a/the stack being in SARAM. To answer the question, only if the thing to be malloc'd is small. In this case it's only a couple of structures (and they are large), so I've manually created them in EXTMEM2. I know this is not ideal, but they won't fit in SARAM. Over lunch I had a play with the things I talked about in my last email. Removing the memcpy (from the slow SDRAM X[] array to the fast SARAM fast_in[] array) made the code marginally slower - at least there were more drop outs, so it appears that the memcpy() overhead is less than the extra time needed to access the data in SDRAM. I shaved a few array elements off the output[] SARAM array (down from 100 to 78 elements, this fits the current Bluez encoder parameters, but if they were changed upwards, both the input[] and output[] arrays would probably need to be made bigger). I also removed the #PRAGMAs I had been using to place the const data from sbc_tables.h in SARAM as from looking the avs_kernelcfg.cmd file, .const data is already placed in SARAM (SARAM_DATA section) and I thought this might free up some room to fit the X[] array in SARAM directly. It didn't. Moving the const tables freed 72x32bits, removing the fast_in[] array (not needed if X[] itself is fast) freed 80x32bits, but the X[] array requires 2x160x32bits. It still doesn't fit :( Brad (Midgley) was talking earlier about implementing zero-copy; this would be good as then at least some of the data could be left in the SARAM input/output arrays (both faster because these are SARAM and because it doesn't need a copy). I'll have a look at this. So onto trying to optimise the inner loop... Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: DSP SBC encoder update
Do you use any buffers allocated by malloc? My guess is that malloc does allocation of DARAM and SARAM memory. In any case, memory returned by malloc should be not worse than the memory buffer explicitly statically placed to EXTMEM. Yes, I think you're right, in the avs_kernelcfg.cmd file it talks about a DARAM_heap and a SARAM_heap, presumably it's possible to allocate from either somehow (using the CSL MEM_* calls probably, I don't know off hand which heap is used for task data, but will have a look this evening). It also talks about a/the stack being in SARAM. I'm sorry if it was not clear enough. Just use normal malloc from C library without any CSL_MEM_* stuff. You can add some debugging prints for the addresses of allocated blocks and identify what kind of memory they are actually in (DARAM, SARAM, SDRAM). By the way, this information is especially important if you want to use DMA, as you need specifically configure the type of memory (not just address) when setting up DMA transfer. No, I understood, I was just mentioning that there appear to be two heaps to chose from - presumably one is used by the DSP tasks (malloc is probably #defined as one of the CSL MEM* fns in the DSP Gateway task functions). Over lunch I had a play with the things I talked about in my last email. Removing the memcpy (from the slow SDRAM X[] array to the fast SARAM fast_in[] array) made the code marginally slower - at least there were more drop outs, so it appears that the memcpy() overhead is less than the extra time needed to access the data in SDRAM. Yes, accessing SDRAM memory is extremely slow. And if you access SDRAM memory using 16-bit accesses instead of 32-bit accesses, the overhead doubles. So if your data processing algorithm does not deal exclusively with 32-bit data accesses, you are better not to run it to process data in SDRAM memory. Copying data to a temporary buffer in DARAM or SARAM, processing it there and copying results back to SDRAM would be faster in this case. The X[] array data type is an int32, so even accessing 32bit from SDRAM is still slower than using a local buffer (depending on what you need to do with it of course). I shaved a few array elements off the output[] SARAM array (down from 100 to 78 elements, this fits the current Bluez encoder parameters, but if they were changed upwards, both the input[] and output[] arrays would probably need to be made bigger). I also removed the #PRAGMAs I had been using to place the const data from sbc_tables.h in SARAM as from looking the avs_kernelcfg.cmd file, .const data is already placed in SARAM (SARAM_DATA section) and I thought this might free up some room to fit the X[] array in SARAM directly. It didn't. Moving the const tables freed 72x32bits, removing the fast_in[] array (not needed if X[] itself is fast) freed 80x32bits, but the X[] array requires 2x160x32bits. It still doesn't fit :( 2x160x32 bits is only 1280 bytes, which is hardly too big. Try to allocate buffers with malloc and copy constant tables there on initialization. It know there's not much free SARAM memory (note that the DSP Gateway kernel also appears to hold the majority of its data in the DSP internal memory). But parts of the SARAM and DARAM are reserved for the stack and heaps, which may well have free space on them. It appears that 0xc00 (8bit) bytes are reserved for the stack, the DARAM heap is 0xbf40 bytes in size and the SARAM heap is 0xd000 bytes long. So this may mean that there's enough space in the SARAM if I use malloc to get the memory from the heap. I had thought that the heap would be fairly small so I was #PRAGMAing my large structures to be placed in SDRAM; this was probably the wrong thing to do. I'll test and report back. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
DSP SBC encoder update
Hi all, I'm happy to say I've got the DSP task working for more than 4s now, in fact it even runs all the way to the end of the song, as expected ;). You can download version 1.0.0 from here: https://garage.maemo.org/projects/dsp-sbc/. This is for Diablo only. This consists of a tarball containing the DSP task and command file, a tweaked Bluez-utils which can use said DSP task for SBC encoding (so it will just work with mplayer and the like) and an installation script which writes some config data about the new task to the DSP dynamic loader conf file and then extracts the tarball, installs the deb and tells you to reboot. [Note to would-be DSP hackers: rather than rebooting, you can just run dsp_dld in the terminal to restart the loader daemon, but make sure you've made a symlink from /lib/dsp/dsp_dld_avs.conf - /lib/dsp/dsp_dld.conf as this is where it expects to find the conf file.] If you want to go back to software encoding, rename the sbcenc.o file (in /lib/dsp/modules) and it will automatically fall back to the original software method (it falls back whenever the DSP fails, and renaming the task will cause it to fail). I've not checked to see if the fallback method is as quick as the original code, I'd be interested to know though if anyone is bored. I should add some logic using an env var or similar to switch method - anyone have some example code I could use? You still need to enable a2dp with either johnx's a2dp deb which can be found here: http://www.internettablettalk.com/forums/showthread.php?t=13468 or manually (use the deb, far easier). I should add that running DSP tasks will move the CPU frequency to 330MHz, so this is probably not the answer to everyone's prayers with regard to freeing the CPU to do Xvid decoding or the like. There is a kernel patch to not force the CPU to 330MHz (the DSP runs slower) and I'll do some testing to see if the DSP task can run in real-time at the lower DSP clock speed. Then it will be significantly more useful. In the meantime, it may or may not use less power this way, please let me know if you do any testing. Next bit is for those interested in the gory details: This is pretty much the same code I had running a week ago or thereabouts, and it was only encoding ~4s of audio in real-time (using bulk transfers ioctls for sync). I tested the SW encoder and it would encode a test file more slowly than the DSP method but would output more seconds worth of audio when testing with mplayer, which made me wonder if the DSP was just cursed (or perhaps something to do with the CPU speed being set to 330MHz when the DSP is running...). The released code is from my mk2 branch: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/mk2/?root=dsp-sbc The change which has allowed it to encode an entire song rather than just a few seconds was to move the input and output buffers from SDRAM (OMAP main memory) to SRAM (DSP fast single access memory). There are probably other things which would benefit from being moved, the sbc-priv data (or parts thereof) for one. This structure is pretty big so I allocated it in SDRAM, but at least parts of it might be better off in faster local memory. This is something to look at. I tested the speed of the bulk transfers (29s au file, took ~20s to encode with the DSP and ~9s to just transfer the data), which are pretty slow as you can see. I then decided to convert the task to use shared memory and some polling and sleeping to synchronise (mk4 branch: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/mk4/?root=dsp-sbc). The mk4 code takes absolutely forever to run though, the same test file which takes ~20s with the bulk transfer method (mk2) takes ~45s using shared memory. Unfortunately there appear to be no clocks available in the DSP kernel (which makes benchmarking code quite tricky) and also means you can't sleep() between polling memory. So the DSP task sits in a tight polling loop (bad!) and the ARM sleeps for 1us and then polls the shared memory. Anyway, there's something not right and I'm not sure what it might be (the DSP manages ~650 loops before the ARM presents it with input data), the DSP then processes and the ARM sleeps for 1 loop (1us) before the DSP gives it back the encoded data, and so on. This is not a good method for the task to use, but I am interested to know why it's so slow, so may do some more work on it eventually. Talking about a lack of clocks, the mk3 branch was my attempt to rewrite the sbc conversion fns using DSP intrinsics, dual MACs, and the like. It doesn't produce the correct output data (probably some issue with my Q15 arithmetic, this was only the first hack at the code) but also didn't improve the speed of the code (and with no clock fns it's hard to tell where the bottleneck is) so I'm leaving it alone for the time being. Last but not least, even when running at 165MHz (or whatever the conservative governor produces) the sw fall back code doesn't produce any error messages (when
AGPS performance
Hi all, Just a quick question. Diablo has seen the introduction of working AGPS (yay!), but I've been wondering if we'd gain better performance by having a more accurate way of telling the SUPL server (which sends us the data we need about satellite positions, etc.) where we are? The tail-end of https://bugs.maemo.org/show_bug.cgi?id=2878 has some comments on this (and Quim told me to make an enhancement bug, but I'm not yet sure whether this will enhance anything, hence the email). Does it make any difference if we have something more accurate than the ~300km radius Marko is talking about? If it does make some (minor?) difference then it would be worth having an API to be able to access the SUPL service so that it could be integrated with maemo-mapper (which has much higher magnification on the map and therefore would give more precise locations than the ~50mile square pixels in agps-ui) and/or integrate it with GeoClue to use other backends to provide an initial location. I don't know enough about this stuff. Does anyone know if: a) the SUPL server calculates the ephemeris/etc. data for the exact position that is sent to it, or does it only calculate for some specific sized grid, then returns the nearest set of data? b) The area over which the ephemerides/etc. are actually valid (is it really a ~300km radius or is this just good enough for most cases)? Thanks, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
dsp-sbc task update
Just a quick note really. Thinking that I ought to try to optimise the _sbc_analyze_eight()/_sbc_analyze_four() fns as these are called lots, I re-wrote them to use DSP intrinsics, dual-MACs, etc. I hasten to add that my code doesn't actually work, I get what I understand is saturated output - loud white noise. So there's still some sort of problem in there (not unexpected for the first run after conversion). The real issue is that this has done nothing in particular to the overall decode time. So either my optimisations are rubbish (quite possible, but afaict I've done what needs to be done) or the code is being held up somewhere else. So, this is where the problem comes - from SPRU376A, the TMS320C55x DSP Programmer's Guide (Rev. A), ch3.3, it says to use the clock() fn to time individual parts of the code. I've tried this, and the function always returns the same value (each 16bit part (high and low) of the 32bit integer = -1792 (when output with %d for signed short; the dbg() fn can only output 16bit values)). Any clues? I'm not sure how to go about timing the code without some sort of clock, other than to just look at the code and guess at what might be optimisable. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Power management is going to drive me mad!
Is it possible on the N800 to programatically shut down the wifi interface and bring it back up? I have an application that very occasionally needs network connectivity. If I leave my device connected to wifi, the battery dies too quickly. I would like to have the software turn on the wifi interface, do its thing, and then turn the interface off to conserve energy. I've considered other solutions, but I think this is the simplest answer. If you change the settings to allow auto-connect it will automatically connect whenever libconic (or whichever one it is) asks for a connection. To get it to disconnect you can set the idle timeout to something suitably short (5min I think). This ought to work, though is perhaps not ideal if you have other apps which will keep the connection busy once your chosen app has finished using it (though you shouldn't really have any of these. Likewise if you have any apps which try to connect more frequently, these will also be allowed and might increase your power consumption. I'd personally like to be able to specify connection intervals and then allow all apps to use the connection for a specific time interval, without worrying about whether it will idle for long enough to switch off, and whether some other app will ask libconic to open a connection more frequently than I want (e.g. connect every hour for 5 min, then disconnect even if something is still using the connection). This would have to be done at the libconic level, so that apps which call it were none the wiser. I should add that this is not such a big issue with the N810 as it can quite happily sit connected to the network (running ssh sftp sessions) all evening every day of the week without needing a charge. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
DSP work updates (SBC Tremor)
Hello everyone, Just some updates. The SBC task appears to run correctly, it just runs too slow to be used for more than ~1s by Bluez. The next task is to speed it up. I will crack on with this, but if anyone fancies a look, then please feel free and send me advice/patches/abuse/etc. The output of gprof (run on X86) is shown below: % cumulative self self total time seconds secondscalls Ts/call Ts/call name 0.00 0.00 0.00 160672 0.00 0.00 _sbc_analyze_eight 0.00 0.00 0.00 160672 0.00 0.00 sbc_analyze_eight 0.00 0.00 0.00 5023 0.00 0.00 __read 0.00 0.00 0.00 5021 0.00 0.00 __write 0.00 0.00 0.00 5021 0.00 0.00 sbc_analyze_audio 0.00 0.00 0.00 5021 0.00 0.00 sbc_calculate_bits 0.00 0.00 0.00 5021 0.00 0.00 sbc_crc8 0.00 0.00 0.00 5021 0.00 0.00 sbc_encode 0.00 0.00 0.00 5021 0.00 0.00 sbc_pack_frame 0.00 0.00 0.001 0.00 0.00 encode 0.00 0.00 0.001 0.00 0.00 sbc_encoder_init 0.00 0.00 0.001 0.00 0.00 sbc_finish 0.00 0.00 0.001 0.00 0.00 sbc_get_codesize 0.00 0.00 0.001 0.00 0.00 sbc_get_frame_length 0.00 0.00 0.001 0.00 0.00 sbc_init 0.00 0.00 0.001 0.00 0.00 sbc_set_defaults So basically _sbc_analyze_eight() sbc_analyze_eight() are the things to look at speeding up. To give people a head start, here is where you should be looking to work out how: A2DP specification which says how the SBC encoder is supposed to work: http://www.bluetooth.com/NR/rdonlyres/800D10CD-DE3D-4D51-ABC0-726C8DF26151/921/A2DPspecv10.pdf From here (Ti DSP docs): http://www.ti.com/sc/docs/psheets/man_dsp.htm SPRU281F.pdf - TMS320C55x Optimizing C/C++ Compiler User's Guide Ch3 - Optimizing Your Code SPRU376A.pdf - TMS320C55x DSP Programmer?s Guide Ch3 - Optimizing C Code SPRU422I.pdf - TMS320C55x DSP Library Programmer?s Reference On to Tremor. I've gone back to debugging why it doesn't recognise the Vorbis stream (while it's unpacking the code books) and it looks like some sort of buffer corruption. Here's the output from the DSP (the = A,B form is low,high 16bits): [276990.164062] vorbis_book_unpack: check alignment, byte 1 = 17218 [276990.164062] vorbis_book_unpack: check alignment, byte 2 = 86 [276990.164062] vorbis_book_unpack: Mapping Case 0 [276990.164062] vorbis_book_unpack: s-used_entries 0x= 128 [276990.164062] vorbis_book_unpack: s-used_entries16 0x = 0 [276990.164062] vorbis_book_unpack: s-entries 0x= 128 [276990.164062] vorbis_book_unpack: s-entries16 0x = 0 [276990.164062] vorbis_book_unpack: s-dec_nodeb=2 [276990.164062] vorbis_book_unpack: s-dec_leafw=1 [276990.164062] _make_words: Entered; n=128, 0; quantvals=0, 0 [276990.164062] _make_words: l[i]=5 [276990.164062] _make_words: entry=0,0 [276990.164062] _make_words: l[i]=5 [276990.164062] _make_words: entry=1,0 [276990.164062] _make_words: l[i]=5 [276990.164062] _make_words: entry=2,0 [276990.164062] _make_words: l[i]=5 [276990.164062] _make_words: entry=3,0 [276990.164062] _make_words: l[i]=6 [276990.164062] _make_words: entry=8,0 [276990.164062] _make_words: l[i]=5 [276990.164062] _make_words: entry=5,0 [276990.164062] _make_words: l[i]=6 [276990.164062] _make_words: entry=9,0 [276990.164062] _make_words: l[i]=5 [276990.164062] _make_words: entry=6,0 [276990.164062] _make_words: l[i]=6 [276990.164062] _make_words: entry=14,0 [276990.164062] _make_words: l[i]=5 [276990.164062] _make_words: entry=8,0 [276990.164062] _make_words: l[i]=6 [276990.164062] _make_words: entry=15,0 [276990.164062] _make_words: l[i]=5 [276990.164062] _make_words: entry=9,0 [276990.164062] _make_words: l[i]=6 [276990.171875] _make_words: entry=20,0 [276990.171875] _make_words: l[i]=5 [276990.171875] _make_words: entry=11,0 [276990.171875] _make_words: l[i]=2 [276990.171875] _make_words: entry=2,0 [276990.171875] _make_words: l[i]=26 [276990.171875] _make_words: entry=0,336 [276990.171875] _make_words: l[i]=5 [276990.171875] _make_words: entry=12,0 [276990.171875] _make_words: l[i]=31 [276990.171875] _make_words: entry=32,10752 [276990.171875] _make_words: l[i]=18 [276990.171875] _make_words: entry=20481,1 [276990.171875] _make_words: l[i]=30 [276990.171875] _make_words: entry=17,5376 [276990.171875] _make_words: l[i]=12 [276990.171875] _make_words: entry=1345,0 [276990.171875] _make_words: l[i]=3 [276990.171875] _make_words: entry=6,0 [276990.171875] _make_words: l[i]=1 [276990.171875] _make_words: entry=0,0 [276990.171875] _make_words: Overpopulated tree, return -1 [276990.171875] _make_decode_table: _make_words() 2 True [276990.171875] vorbis_book_unpack: Error in
Re: DSP SBC debugging
Hi Brad
Right, well goodish news, the dsp sbc encoder appears to work. It can be
used with mplayer to play ~1s of audio, then it all goes quiet.
this is how it was when trying the floating point version on an
emulated fpu. There's no way it could keep up.
Ok, so the symptoms sound familiar, that's a good start.
though as I understood that the code could run in real-time on a 200MHz
StrongARM chip, I'd thought the DSP would be able to also run it without any
tweaks?
the dsp is not going to perform well on general-purpose code. There
are a few matrix ops that need to be rewritten first probably.
sbc_analyze_{four,eight} are the main culprits. These have been
optimized to combine remove multiplications whenever unnecessary,
but to preserve symmetry on a dsp you'll undo that to get it optimal.
Yes, ok. Is there, lurking around somewhere, a copy of the first code
that was written, before the various optimisations were put in? It
would be interesting/useful to look at something like that to see
where the DSP might be changed.
If not then fair enough, I'll have to work through the code and as you
say undo the optimisations before applying DSP-specific ones, etc.
Anyway, what I'm saying is that at first glance I can't really see a faster
way of transferring the data across (though I will do some testing to see
what the cold hard figures say), but if anyone spots a mistake or two in my
logic please pipe up.
I'm not sure how this impacts you but the soft codec could benefit
from zero copy. We'd need to change the internal representation to
match host-endian stereo audio and only copy it if the incoming data
is not in that format. There is a complication in that the codec has
some state from previous encode calls, so we'd need to rework things
so a buffer we refer to isn't changed by the client between calls.
Zero-copy could work if I used a shared memory buffer, but that would
mean I'd need to open the DSP device and map the shared memory buffer
somewhere earlier in the code, and be able to pass that buffer address
back to the code for it to use it.
In the meantime, I'll test just how long the bulk transfers take (I
did a quick cheat test by not calling sbc_encode() on the DSP side
(but accepting the data, and then passing it back) and just setting
len and encoded to the values I know the code produces. Unfortunately
the encoder stalls at the end of the stream (which doesn't help time
very much to get an accurate value). I need to have a fiddle with the
code and see what sbc_encode() returns when there's no/not enough data
to process to try to avoid the stall when I'm faking it.
Cheers,
Simon
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: maemo.org community leadership - the maemo.org Community Council
Hello Darius, Council is not the best solution, as council still has no rights but obligations. What rights does the council need if it is elected by the community? It has the power of the people. One thing should be discussed and disclosed yet, what is a role of Nokia in maemo.org to avoid legal issues and problems in the future. Linux developers should be fully aware in advance if they work and devote their time for Nokia Corporation, for maemo.org not-incorporated, maemo.org - organization , incorporation pending or just work for fun, for free, for the community. Well this is to be a community project. The copyright of the maemo.org name will be held by Nokia so they have a final veto (they also pay for and maintain the site), but my understanding is that they would like the community to run/organise/develop the site for the community. Therefore any developers (web developers I guess you mean) will be working for fun, for their community. I should add that there are a few people (Dave Neary - docs, Niels Breet - website and to a lesser extent Andre Klapper and Karsten Braeckelmann - bugtrackers) who are paid by Nokia to work on/for maemo.org part-time. I imagine that that they will be doing what the community wants them to do. I don't see this being a problem. Working for Nokia Corporation on corporate products is really great think. But please aware, any software code is still copyrighted to its author not Nokia and today and forever. So you at Nokia need to establish legal relations between copyright holders and the Nokia Corporation. Presumably the copyright of the website contents will be under a Gnu Free Documentation Licence (a la Wikipedia) or a Creative Commons Licence. What's the current licensing model (http://maemo.org/legal/terms_of_use.html). This is presumably something that could be discussed if people have a preference one way or the other. Another way is to discuss such contractual relations between Linux developers and corporations having global status and set terms, have lawyers from Free Software Foundation and other organizations to represent developers in relations with corporations to facilitate intellectual property rights transfer under US, EU IT rights protections acts, rules, regulations. There are no contracts. This is community for community. If someone decides they can no longer take part (in the council for example), they will need to be replaced. How this would happen is something that has to be worked out (by this discussion for example). But please don't advice Nokia to incorporate third party copyrighted Linux code into one of its product without such writtenm contract or agreement on transfer of intellectual property rights. We're talking about a website and community infrastructure here, not a released software product. And you at Nokia and from Nokia, please follow an example by Apple, having developed iPhone, iPod Touch and new 3G GPS iPhone please look at repositories of community made software, look at SDK policy. If there's a real problem here (what's wrong with the SDK policy - email me in a separate thread please), then this is the sort of thing the maemo.org council should be addressing when it has its meetings with Quim. Global Corporation like Nokia can't risk investing into community projects, products, developed for free by developers volunterring their work for the community. It already has Nokia should incorporate Maemo.org as a business entity, corporation and nominate directors, board, officers and have job done under supervision and management provided by Nokia. The whole point of this is to allow the community to exist and grow without being controlled by Nokia, but rather to be a partner in the direction of that growth. I think your opinions, while interesting, are at odds with those of the majority. Cheers, Simon (aka lardman) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: maemo.org community leadership - the maemo.org Community Council
I'll humour you... Council is not the best solution, as council still has no rights but obligations. What rights does the council need if it is elected by the community? It has the power of the people. -- (sorry no chance to edit properly under Google Groups editor) -- exactly replce hte power of the people by the power of the corporation and you can make a business and manufacture Nokia Internet Tablet to be hot product, market challenge. Fine, if we wanted to we could indeed, possibly, do this. But we don't want to. That is not the point of the maemo.org community. This email thread was started with the goal of obtaining feedback about how to organise a community council. If you have anything relevant to say about *that*, please do say it, otherwise you're going off-topic. One thing should be discussed and disclosed yet, what is a role of Nokia in maemo.org to avoid legal issues and problems in the future. Linux developers should be fully aware in advance if they work and devote their time for Nokia Corporation, for maemo.org not-incorporated, maemo.org - organization , incorporation pending or just work for fun, for free, for the community. Well this is to be a community project. -- Ok. Hardware is corporate project, Nokia Internet Tablet. No chance to have community to finance development and production of hardware. Indeed. That is not the goal, see my reply above. We are not planning on taking over the Maemo project and creating competing hardware + software but rather on making the community - Nokia interaction as productive and easy as possible. The copyright of the maemo.org name will be held by Nokia -- ok. But copyright to service name, trademark makes no software product. What makes Linux software is developers. You're off topic again; we're talking about a community and documentation, not about software. so they have a final veto (they also pay for and maintain the site), You need pocket money to buy and pay for web site or you can even get one for free. To register a new domain cost you another pocket money. So money is not an issue. Indeed money is probably not an issue, this could happen somewhere else, but why not here, where the well known name points (maemo.org) and with the cooperation of Nokia (after all the point here is to work with them, that's the reason we're doing this!) Issue is developers. Not with regard to how to organise the community - Nokia interaction it is categorically nothing to do with programmers. It would be great to encourage more programmers to develop for the platform and the establishment of a community driven maemo.org should facilitate that (well at least it would make me happier and I'm a developer). Therefore any developers (web developers I guess you mean) will be working for fun, for their community. -- ok, great and what about a case, another nice web place, website created asks developers from maemo to move to their website and work for another project ? So be it. If they offer a more compelling platform on which to develop then they can and will leave. It's up to Nokia + the community to provide both compelling hardware and a useful community. This is not about trying to lock people into the platform, except by virtue of it being so cool that why would you want to leave and do something else. I should add that there are a few people (Dave Neary - docs, Niels Breet - website and to a lesser extent Andre Klapper and Karsten Braeckelmann - bugtrackers) who are paid by Nokia to work on/for maemo.org part-time. I imagine that that they will be doing what the community wants them to do. I don't see this being a problem. -- very bad solution The ruler is one you hires you and pays for your services. And if the paymaster says that they should do what the community asks of them - works for me. Paying a community , paying some members of the community to organize other members of the same community to work for free is not a good idea as it makes Maemo a corporate project and no more community project. People have been hired based on their skill sets - I see no problem in having a number of people who know what they are doing to advise how the website documentation should be organised and to maintain the underlying website infrastructure, etc. I do not know how to do either, and indeed it may take up quite a bit of my free time (which is when I do my DSP hacking and write these emails) to be able to do these tasks. I assume that when the time comes and we have a large enough community contributing, etc, some of these roles may no longer be necessary as they will be taken over by community members. To get the ball rolling, we need (and have) these people now. Community project is really general term used on the Internet if you with collaborators to work for you for free under non-for-profit status or you can't afford to
RE: maemo.org community leadership - the maemo.org Community Council
be so nice not to say what I should write My apologies, I hope that you will therefore be so polite as to not bother other people who are interested in the theme of the thread/question by not posting off-topic replies. I'll take that as a yes. if we wanted to we could indeed who is we ? no more community ? You brought it up, you explain - I see no reason why *a* community couldn't do so, just not *this* community (or at least not this one with my participation). If you have anything relevant to say about *that*, please do say it, otherwise you're going off-topic. If you expected my YES as the only on-topic, you were wrong. NO is the same relevant as your YES. I don't care if you say YES or NO, just that you answer the questions on-topic rather than going off on a tangent. I say NO for your Council. Thank you for your input, can you tell me why (and this is probably the first on-topic theme in this series of emails) or what alternative you think would improve the situation? If you are already self-nominated to your Community Council, just say so and don't waste our time for any discussion. I am not. The point of the thread (if you go back and read the first post) was to work out what sort of structure a community council should have, how many people it should contain, how they should be elected, what they should do, etc. It's not really a community council if the community aren't involved... hence the question. If people want me to be a part of it I would be happy to be, if not I'm fine with that too. The fact that a number of us have been thinking about this does not give us defacto positions, as I repeatedly say, the community must decide what and who it wants. This email thread was to ask the community's opinion and someone had to start it (and it wasn't even me :). Nokia , as a corporation, has one business goal to generate profit to the corporation , in vestors and shareholders. There is no other goal for business corporations. Look at Microsoft, Yahoo, Google and others. You can still attract volunteers, but your goal is making money. Today, tommorrow and after tommorow. For Nokia, their goal is to manufacture Nokia Internet Tablets and sell at a reasonable price, to compete with Sansung, Apple and others and generate profit for investors, shareholders. Yes indeed. And supporting the maemo.org community will benefit all parties: the community members by better organising documentation, streamlining and improving interaction with Nokia (bugs, feature/status requests, hopefully beta code testing, etc.); and Nokia by making it a more pleasant/easier/more productive place for independent developers to do good work. I've probably missed lots of things off there, but that's my view with my developer's hat on anyway. Any activities by communities financed, sponsored, donated by Nokia or other corporations, must follow the basic goal of the corporation. In general yes, and here the community adds value to Nokia. So there should be no problem unless this is all simply a rant against Nokia/commercial use of Linux, and in fact you had no intention of giving any useful input to the questions that were posed? Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: DSP SBC debugging
I've moved to Diablo as it uses bluez-utils-3.28 which has the same API as version 2.32 on which I based the DSP code. Patching the DSP SBC encoder into bluez-utils 2.38 I can use sbcenc (good sign) so I tried to play music from mplayer using the a2dp tools produced by johnx to set it up. Sorry about the typos in the version numbers there. That paragraph should read as follows: I've moved to Diablo as it uses bluez-utils-3.28 which has the same API as version 3.32 on which I based the DSP code. Patching the DSP SBC encoder into bluez-utils 3.28 I can use sbcenc (good sign) so I tried to play music from mplayer using the a2dp tools produced by johnx to set it up. I get the following error message: snip DEBUG: _snd_pcm_bluetooth_open: Bluetooth PCM plugin (Playback) DEBUG: audioservice_send: sending BT_GETCAPABILITIES_REQ DEBUG: audioservice_recv: trying to receive msg from audio service... DEBUG: audioservice_recv: Received BT_GETCAPABILITIES_RSP alsa-lib: pcm_bluetooth.c:1589:(bluetooth_init) BT_GETCAPABILITIES failed : Input/output error(5) alsa-init: playback open error: Input/output error Could not open/initialize audio device - no sound. Audio: no sound Video: no video Exiting... (End of file) (none):/home/user/MyDocs/.sounds# Good news, I also get this error with the standard un-DSP-enabled bluez-utils-3.28. So it's (probably) not my fault. It would still be interesting to know why it happens mind you as I'd like to use a2dp. Does a2dp work for anyone else using Diablo? Regards, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: DSP SBC debugging
DEBUG: _snd_pcm_bluetooth_open: Bluetooth PCM plugin (Playback) DEBUG: audioservice_send: sending BT_GETCAPABILITIES_REQ DEBUG: audioservice_recv: trying to receive msg from audio service... DEBUG: audioservice_recv: Received BT_GETCAPABILITIES_RSP alsa-lib: pcm_bluetooth.c:1589:(bluetooth_init) BT_GETCAPABILITIES failed : Input/output error(5) alsa-init: playback open error: Input/output error Could not open/initialize audio device - no sound. Audio: no sound Video: no video Exiting... (End of file) (none):/home/user/MyDocs/.sounds# Good news, I also get this error with the standard un-DSP-enabled bluez-utils-3.28. So it's (probably) not my fault. It would still be interesting to know why it happens mind you as I'd like to use a2dp. Does a2dp work for anyone else using Diablo? Ah, user error - need to re-pair the headset. Sorry for the noise. Ball's back in my court now, some more DSP code debugging to do (it doesn't seem to like the type of data that's being passed to it, which is not unexpected as it's only been tested using one type of input file thus far). Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
DSP SBC debugging
Hi all, I've moved to Diablo as it uses bluez-utils-3.28 which has the same API as version 2.32 on which I based the DSP code. Patching the DSP SBC encoder into bluez-utils 2.38 I can use sbcenc (good sign) so I tried to play music from mplayer using the a2dp tools produced by johnx to set it up. I get the following error message: (none):/home/user/MyDocs/.sounds# a2dp enable (none):/home/user/MyDocs/.sounds# mplayer Moby-In_My_Heart.mp3 MPlayer 1.0rc1-maemo.27.n8x0 (C) 2000-2006 MPlayer Team CPU: ARM Internet Tablet OS version: RX-34+RX-44+RX-48_DIABLO_4.2008.22-8_PR_MR0 [MENU] Can't open menu config file: /root/.mplayer/menu.conf Menu inited: /etc/mplayer/menu.conf Playing Moby-In_My_Heart.mp3. Audio file file format detected. == Trying to force audio codec driver family dspmp3... Opening audio decoder: [dspmp3] MP3 audio pass-through for Nokia 770/N800 (fake decoder) ADecoder preinit failed :( ADecoder init failed :( Trying to force audio codec driver family libmad... Opening audio decoder: [libmad] libmad mpeg audio decoder AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000-176400) Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3) == DEBUG: _snd_pcm_bluetooth_open: Bluetooth PCM plugin (Playback) DEBUG: audioservice_send: sending BT_GETCAPABILITIES_REQ DEBUG: audioservice_recv: trying to receive msg from audio service... DEBUG: audioservice_recv: Received BT_GETCAPABILITIES_RSP alsa-lib: pcm_bluetooth.c:1589:(bluetooth_init) BT_GETCAPABILITIES failed : Input/output error(5) alsa-init: playback open error: Input/output error Could not open/initialize audio device - no sound. Audio: no sound Video: no video Exiting... (End of file) (none):/home/user/MyDocs/.sounds# Note that I've uncommented the #define ENABLE_DEBUG line in pcm_bluetooth.c to get some more info out. I have tried following the code back from bluetooth_init(), where the error occurs, but can't work out where/why it should occur (the code ends in an IPC and I don't know enough about the code to know where it goes to/from). I'd be very grateful for some advice/help in debugging this problem. If you'd like to test for yourself (and you probably need to be running Diablo for package compatibility), the ARM code which should be substituted into the bluez-utils-*/sbc directory can be found in the Garage svn under dsp-sbc/mk2/arm/ and a binary DSP task can be found here: http://people.bath.ac.uk/enpsgp/nokia770/dsp/sbc/sbcenc.o.diablo.rename-me (rename to sbcenc.o and place in /lib/dsp/modules/) to go with the sbcenc.cmd file which can be found in dsp-sbc/mk2/dsp/ (again place this file in /lib/dsp/modules/) You will need to add an entry line to the /lib/dsp/dsp_dld_avs.conf file like this: sbcenc tab _task_sbcenc tab 1 tab /lib/dsp/modules/sbcenc.o tab /lib/dsp/modules/sbcenc.cmd Then restart the dsp_dld to reload the conf file (by simply running dsp_dld in a terminal). DSP output can be seen in dmesg. A compiled bluez-utils can also be found here: http://people.bath.ac.uk/enpsgp/nokia770/dsp/sbc/bluez-utils_3.28-0osso4_armel.deb Thanks, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP SBC encoder task
I've re-written the original thread-based (async) code today and it's now synchronous - a call is made to sbc_encode() on the ARM and it's passed through to the DSP and the work is done and the data passed back. This should all fit in without any changes to the code which calls the sbc_* functions. They still call just sbc_init(), sbc_encode() and sbc_close() and all the DSP stuff is handled in the background. If there are parts which need access to lower level data (the example sbcenc code doesn't), then I'll have to write a link in to the DSP to retrieve that data. Not a big issue, but I'll have to take a look at the Bluez code and GStreamer bits to see if this is needed (or someone let me know). A couple of questions still remain about the maximum size of a single PCM or SBC data transfer (so I can make the DSP buffers as small as possible) - any thoughts? Other than that, I'm hopeful it should just drop in to replace the contents of the sbc directory in Bluez-utils and compile and work. I just tried to cross-compile Bluez-utils, and other than the lack of Flex (which is a dep) Scratchbox is complaining about not being able to run binaries it has produced. Any suggestions? Too late in the evening here to do any more today, but I'll get it working tomorrow. In theory it should be fairly easy to create a new GStreamer element that overrides the software one. With regard to overriding, I tried a bit of code to look at an env var and choose SW/DSP from that, but it doesn't seem to work. Strange, as I've also written the DSP code so that if the DSP fails for any reason it will fall back to using the sw encoding method (and that works). Probably a silly error I've missed, but it's late so I'll take a look at it tomorrow. The latest code is available in the Garage project under the mk2 directory if anyone wants to have a play with it while I'm asleep :) Right, I've created some binary DSP modules, which are available for the 770 and os2008 (chinook) devices for download from the Garage page. The SBC code seems to drop straight into the bluez-utils-3.32 code (certainly it compiles), however there is an error when I move the updated bluez-* files over to my N800 test machine and try running mplayer over a2dp. I think this basically means I'll need to recompile something else. If anyone knows what, or fancies having a go please speak up :) The error (returned by mplayer) is: Nokia-N800-50-2:/home/user/MyDocs/.sounds# mplayer Moby-In_My_Heart.mp3 MPlayer 1.0rc1-maemo.27.n8x0 (C) 2000-2006 MPlayer Team CPU: ARM Internet Tablet OS version: RX-34+RX-44_2008SE_2.2007.50-2_PR_MR0 [MENU] Can't open menu config file: /root/.mplayer/menu.conf Menu inited: /etc/mplayer/menu.conf Playing Moby-In_My_Heart.mp3. Cache fill: 0.00% (0 bytes) Audio file file format detected. == Trying to force audio codec driver family dspmp3... Opening audio decoder: [dspmp3] MP3 audio pass-through for Nokia 770/N800 (fake decoder) ADecoder preinit failed :( ADecoder init failed :( Trying to force audio codec driver family libmad... Opening audio decoder: [libmad] libmad mpeg audio decoder AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000-176400) Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3) == alsa-lib: pcm_bluetooth.c:1505:(audioservice_recv) Error receiving data from audio service: Success(0) alsa-lib: pcm_bluetooth.c:1521:(audioservice_expect) Bogus message BT_GETCAPABILITIES_REQ received while BT_GETCAPABILITIES_RSP was expected alsa-init: playback open error: Invalid argument Could not open/initialize audio device - no sound. Audio: no sound Video: no video Exiting... (End of file) Which looks like some sort of API change. I'm not sure if libasound.so needs to be recompiled (though I seem to get a plugin for it when compiling bluez-utils, so I'm doubtful), or if mplayer needs to be recompiled (which I'll try in a minute to see). Anyway, as I said, the DSP binary (and source) code (which tends to be the limiting factor with people playing with these things) is available for download, so all you then need to do is use the sbc source from the Garage repo and compile away and test things. Let me know if it works :) Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP SBC encoder task
It would be easier to plug your work into everything else if you wrote it up as a patch to the regular sbc.c so it transparently chooses the soft or dsp codec at runtime. It would work with the alsa plugin, gst, and eventually pulse without extra work. Marcel will have to weigh in if it's to be accepted upstream. In any case, we'd need an override. It could be done with an environment variable like SBC_CODEC with values eg soft, dsp, auto with auto the default if it's not set. This does step around gstreamer a little, but anyway, alsa and pulse don't have the greatest gstreamer integration to start with... Yes, that sounds like a good idea. At the moment I'm effectively running all of sbcenc.c on the DSP, while I should just be doing sbc_encode() + whatever init and clean-up routines are needed to handle the DSP on the ARM and to pass it the stream format data. I've started looking at the Bluez code and it looks like it should be reasonably easy (he says!) to have just these bits running on the DSP (expect lots of questions still though). Would it be synchronous? I mean, that the encoding will start with sbc_encode, and before the function returns the output would be ready. I haven't done DSP development, but I've used DSP libraries and all of them seem to be asynchronous. I've re-written the original thread-based (async) code today and it's now synchronous - a call is made to sbc_encode() on the ARM and it's passed through to the DSP and the work is done and the data passed back. This should all fit in without any changes to the code which calls the sbc_* functions. They still call just sbc_init(), sbc_encode() and sbc_close() and all the DSP stuff is handled in the background. If there are parts which need access to lower level data (the example sbcenc code doesn't), then I'll have to write a link in to the DSP to retrieve that data. Not a big issue, but I'll have to take a look at the Bluez code and GStreamer bits to see if this is needed (or someone let me know). A couple of questions still remain about the maximum size of a single PCM or SBC data transfer (so I can make the DSP buffers as small as possible) - any thoughts? Other than that, I'm hopeful it should just drop in to replace the contents of the sbc directory in Bluez-utils and compile and work. I just tried to cross-compile Bluez-utils, and other than the lack of Flex (which is a dep) Scratchbox is complaining about not being able to run binaries it has produced. Any suggestions? Too late in the evening here to do any more today, but I'll get it working tomorrow. In theory it should be fairly easy to create a new GStreamer element that overrides the software one. With regard to overriding, I tried a bit of code to look at an env var and choose SW/DSP from that, but it doesn't seem to work. Strange, as I've also written the DSP code so that if the DSP fails for any reason it will fall back to using the sw encoding method (and that works). Probably a silly error I've missed, but it's late so I'll take a look at it tomorrow. The latest code is available in the Garage project under the mk2 directory if anyone wants to have a play with it while I'm asleep :) Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP SBC encoder task
Just a quick note to say that the DSP task encodes the test .au file correctly. Still a minor ;) issue that the DSP crashes after the DSP has finished the encoding task (I think this is probably due to a non-existent semaphore being written to, will have to test my theory tomorrow). snip in case of using GStreamer, you should provide a GStreamer element that allows you to offload the SBC encoding to the DSP. Currently we are using sbcenc which will do it for us. Atm we have to use ALSA to produce A2DP output, is the data sent thought here simply piped straight into sbcenc running standalone? I'd like to make sure that the people who currently use it (e.g. from mplayer) are also able to continue doing so using the DSP. Certainly a GStreamer wrapper is next on the list of ToDos after I stop the DSP from crashing ;). Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP SBC encoder task
Hi Chaps, I have been thinking more about this and I think another approach could be considered. It would be easier to plug your work into everything else if you wrote it up as a patch to the regular sbc.c so it transparently chooses the soft or dsp codec at runtime. It would work with the alsa plugin, gst, and eventually pulse without extra work. Marcel will have to weigh in if it's to be accepted upstream. In any case, we'd need an override. It could be done with an environment variable like SBC_CODEC with values eg soft, dsp, auto with auto the default if it's not set. This does step around gstreamer a little, but anyway, alsa and pulse don't have the greatest gstreamer integration to start with... Yes, that sounds like a good idea. At the moment I'm effectively running all of sbcenc.c on the DSP, while I should just be doing sbc_encode() + whatever init and clean-up routines are needed to handle the DSP on the ARM and to pass it the stream format data. I've started looking at the Bluez code and it looks like it should be reasonably easy (he says!) to have just these bits running on the DSP (expect lots of questions still though). What do you mean by it stepping around GStreamer? From my quick look at the code, the same init/clean-up and sbc_encode() routines seem to be used for both GStreamer and the ALSA bits; what more does GStreamer need to know? Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP SBC encoder task
I only say stepping around gstreamer since the gst way would be to make one gst plugin for soft and one for dsp codec and let gst choose one when building a pipeline. ie, they're prepared for multiple implementations of a given codec. Ah, ok, I'm with you now. Well as you said before, let's not worry to much about complying with that way of doing things hey :) Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
DSP SBC encoder task
Hi all, Just a quick note to say that the DSP task encodes the test .au file correctly. Still a minor ;) issue that the DSP crashes after the DSP has finished the encoding task (I think this is probably due to a non-existent semaphore being written to, will have to test my theory tomorrow). I've not looked at the rest of the Bluez code, so am not sure exactly how to plumb this DSP task in (though I'm hopeful it will be pretty much a drop-in replacement. Fingers crossed :) ). The code (and some binaries if you're daring) are in the Garage dsp-sbc project. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Hello Maemo - CFSONID 2008
So the answer is no. As long as Maemo's goal is not 'providing a 100% free platform' as well I[0] will not contribute[1] to it and I expect that with more and more freedom respecting projects/products you will have a hard time finding people who do. This is what I had in mind in my LinuxTag maemo.org presentation: there are people who will not want to contribute to Maemo just because Nokia does not completely adhere to the free software principles. By that I did not mean to imply that Nokia should put free software above their bottom line. My point was that Nokia should evaluate the extra value received from free software zealots (this word is probably too strong, but I don't have the time right now to pick a better one) with value lost from opening their proprietary components. Is zealotry that wide-spread and that much of a stumbling block for some people? I'd prefer it to be open, but if it is possible to work within the constraints that Nokia impose (due to IP/NDA/etc. restrictions), as long as they are helpful in providing ways to use the functionality of the closed components, then I can accept that there are real reasons for the limitations and still be happy to use and develop for the device. Unfortunately I'm no economist and I cannot evaluate either. Looking at the increasing popularity of free software in the IT sector it seems to me that free software benefits outweigh proprietary benefits, but this is not a choice I can make for Nokia; it's one Nokia has to make for themselves. Perhaps, but we are quite often talking about interfacing with hardware from a company which makes lots of mobile devices, rather than software only service providers. My feeling/understanding is that closed components such as BME will stay closed as the IP is too valuable to release to competitors; the best we can hope for is some sort of API to communicate with the hardware via a closed component. This is not a problem for me as long as it is available. Likewise the wifi driver will not be open sourced as it belongs to someone else. We won't see the source for this released either, but perhaps we will see a more open source friendly version in a later tablet as long as it is cost-effective (same goes for the charging hw). Closed software-only (as in they don't talk to hardware) components are something we have more chance with; quite a few of the closed components don't seem to contain anything very hi-tech, but are just closed. This might just be because no-one has thought to open them; or to avoid competitors copying the whole interface/os in one go (though it wouldn't be beyond a company to just re-write these parts I'd guess); or perhaps to avoid developers screwing up the Nokia UI spec. and then releasing images which reflect badly on Nokia. Lots of perhapses of course :) Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: LinuxTag ticket?
Hi Michael, Just a quick question. Do presenters need to buy a ticket or do they get in free as they are presenting? I'm not bothered either way but would like to know so I can get one in advance and get the discount. I just asked the organizers. Presenters will get free access to LinuxTag. Besides that, as Simon already pointed out, we're having this snowball like system to give free tickets to the community. So, how many snowball do you need? just email me.. ;-) Great! Do we just state our names when we get to the front gate, or do we need a (free) physical ticket? Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Help with YV12-YUV420 converter
You can find the code I wrote here: http://qstream.org/viewvc/trunk/qvid/src/video_out/maemo_dsp_yuv/ A whole bunch of DSP related documents and things I collected are here: http://qstream.org/~krasic/770/dsp/ Thanks Buck I'll take a look. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: SBC DSP task, converting from 8bit to 16bit chars, any spare eyes?
Thanks to those who replied. I've had a couple of mistakes/places where I've added unnecessary code/optimisations pointed out to me :) I'll fix those and see where we go from there. Cheers, Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Pickering Sent: 15 May 2008 23:33 To: maemo-developers@maemo.org Subject: SBC DSP task, converting from 8bit to 16bit chars, any spare eyes? If anyone's bored and fancies looking for some of the mistakes I've no doubt made converting the BlueZ SBC encoder code to use the DSP's 16bit chars rather than the more normal 8bit chars, please take a look at the code in the dsp-sbc Garage project and let me know what I've messed up, or any other thoughts you might have. https://garage.maemo.org/plugins/scmsvn/viewcvs.php/dsp/sbc/sb c.c?root=dsp-sbcr1=4r2=1diff_format=h Cheers, Simon P.S. I'll be happy to never again see a bitwise operator! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
