Replacing the standard maemo bluetooth pairing dialog.
Hi, I've made a compile of carwhisperer for the maemo platform ( http://www.internettablettalk.com/forums/showthread.php?t=20780). The app itself seems to work (from what I can tell anyway) but there is one problem with this. This program works on the principle of default security pins and the program comes with a script to do just this. I've added in the pin_helper configuration option in the hcid.conf and on a standard Linux system running BlueZ, this works. However, on the OSSO versions of BlueZ, this doesn't work. I've tried rebooting, disabling the bluetooth statusbar applet, I've tried moving btcond, btsdp, btsearch to another place, I've even tried moving the relevant files in /etc/dbus-1 to no avail. I can see with top that the dbus-daemon is using a little bit more power when asking for the paircode. I've even recompiled a hcid from the BlueZ website (i.e devoid of any OSSO modifications) and replaced my binary in /usr/sbin but I still get the maemo pair dialog. So, how would I replace maemo bluetooth pairing dialog with another program I want to run externally. Or make the maemo bluetooth pairing dialog not interfere so hcid will run the program specified in the pin_helper option. Regards, Faheem ___ 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
About release dates (was RE: maemo Bug Jar #7)
Hi, > Am Donnerstag, 5. Juni 2008 schrieb [EMAIL PROTECTED]: >> Frederic Crozat wrote: >> > Remember that most people are not used to Nokia policy to embargo >> > any date (even estimate) regarding software (or hardware) release. True. These people need to understand that Nokia is a company watched by competitors, the media, shareholders... Device launches and software releases have an impact in this context far beyond the software update itself. This is why Nokia generally doesn't disclose release dates. >> >> For simplicity's sake, I don't know when Diablo will be released. > > Quality first! Releasing shouldn't _only_ be a management > decision. When the quality is as expected then the (scrum ?) > team should hand over the responsibility to the management. > They can then powerpoint the great event ;-) And this is what the maemo development team does. To understand better what Josh is saying you need to know that there is a gap of time between the moment the development team says 'this release is ready' and the moment the image goes actually out. The public release date is decided from a business and marketing perspective based on many factors that go beyond the quality of the software. > Personally I > consider fix release dates as contra productive. Quality it > the key to success. There are lots of books about waterfall and agile development, and about feature or timebox based development. In fact all combinations exist i.e. agile + timebox. Also, who said our release dates are so fixed? Remember how upset some people were last year when I dared to give rough time estimations for the Hacker Edition and the OS2008 releases, and at the end they came later? Guess what was the role of quality in that. However, "consider fix release dates as contra productive" is easier said than done when you have factories, distribution channels, marketing teams and more releases ongoing at different stages, all of them needing to have a good coordination with you, while having to support also other development projects running in parallel elsewhere. -- Quim Gil marketing manager, open source maemo software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Having trouble installing the scratchbox development environment.
On Thu, 05 Jun 2008 21:56:58 +0300, Marius Gedminas wrote: > On Thu, Jun 05, 2008 at 03:46:28PM +, Hendrik Boom wrote: >> I'm following the instructions in >> http://inz.fi/blog/2007/10/22/multi-target-development-for-maemo/ >> as advised by Graham Cobb, and have run into a snag. > > Been there, done that, have a working scratchbox. > > (Actually, two, because http://maemo-sdk.garage.maemo.org/install.html > also worked for me, and seems a bit simpler to set up. It's not the > official way though, and it's an early alpha version, so beware.) > Tried this; didn't work. There's no sources.list line for Debian, Looking at the web site with the distros, I found that http://maemo- sdk.garage.maemo.org/download/host in its dests directory had entries for experimental, ubuntu-gutsy, and ubuntu-hardy so I used deb http://maemo-sdk.garage.maemo.org/download/host experimental free But in response to the apt-get, all I got was: lovesong:/farhome/hendrik# apt-get install maemo-sdk Reading package lists... Done Building dependency tree Reading state information... Done E: Couldn't find package maemo-sdk lovesong:/farhome/hendrik# Now there were packages there; in particular, there was an available upgrade of sbrsh from 7,6 to 7,6maemo1, but no maemo-sdk. Of course aptitude warns me that sbrsh is fron an untrusted source, but that's probably irrelevant. Debian also provides a scratchbox2 and sbrsh. It seems that they just forgot the Debian build. I went to the tracker, but there seems to be no way to submit a bug report to it. -- hendrik ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP SBC encoder task
On Sat, Jun 7, 2008 at 12:17 AM, Simon Pickering <[EMAIL PROTECTED]> wrote: > 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). 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. > 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? In theory it should be fairly easy to create a new GStreamer element that overrides the software one. Best regards. -- Felipe Contreras ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: policy: maemo packaging policy -draft
Hi! On Wed, May 28, 2008 at 10:32:22AM +0300, Eero Tamminen wrote: > A draft version of the "maemo packaging policy" is available > for commenting: > https://maemo.org/forrest-images/pdf/maemo-policy.pdf > > If you're packaging software for maemo, please take a look at it. * Testing on a device with no extra packages is a hard to do, unless you have two devices, or you're not actually using the one you have. I wish we had a complete hardware emulator so that you could test package installation on a pristine rootfs in a virtual machine. * Interactive prompts from maintainer scripts (such as asking where do you want to stick this new thing in your menus) are annoying for the user. I'd be inclined to add a sentence or two saying that these SHOULD be avoided where possible. * Splitting translations has a question about Debian/Ubuntu. I'm not a developer of either, but as far as I know Debian ships translation files for all languages in the same .deb that contains the software, while Ubuntu collects all translations from a big group of related packages into a language-pack-$group-$languagecode, so you end up with language-pack-lt, language-pack-gnome-lt, language-pack-kde-lt and so on. The Ubuntu solution is only possible because they release the whole stack at once. > As stated in the policy document, the comments and questions on this > policy should be mailed to the maemo-developers mailing list with > word "policy" in the subject. This thread qualifies. ;-) Marius Gedminas -- I have yet to see any problem, however complicated, which, when you looked at it in the right way, did not become still more complicated. -- Poul Anderson signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for maemo extras repository
Thanks, I'll take a look Fred - Original message - > 2008/6/6 Fred <[EMAIL PROTECTED]>: > > Looks like it works ... > > > > Can this pb be linked to the fact that I have a passphrase associated > > with my ssh key and that I may not answer the passphrase question as > > soon as it arises ? > > If that is the problem, are you aware of ssh-agent and ssh-add? > > Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
