Re: Telephone API question - answering a call.
Hi, On Wed, Jan 27, 2010, Dave Neary wrote: > This page: > https://garage.maemo.org/plugins/wiki/index.php?com.nokia.csd.Call&id=1106&type=g > > has a link to this file at the top: > http://www.bleb.org/software/maemo/telephony-maemo.c I'm not sure which version of the BlueZ maemo telephony driver has been copied to that location, but it's better to refer to the very latest version in BlueZ git as the file has seen many bug fixes during its lifetime: http://git.kernel.org/?p=bluetooth/bluez.git;a=blob_plain;f=audio/telephony-maemo.c;hb=HEAD However, the answer_call function that was quoted is at least still the same. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gwobex problem
Hi Christian, On Wed, Oct 07, 2009, Christian Kuersteiner wrote: > < ACL data: handle 45 flags 0x02 dlen 42 > L2CAP(d): cid 0x01cc len 38 [psm 3] > RFCOMM(d): UIH: cr 1 dlci 12 pf 0 ilen 34 fcs 0x4f > OBEX: SetPath cmd(f): len 34 flags 2 constants 0 > Name (0x01) = Unicode length 26 > : 00 50 00 68 00 6f 00 6e 00 65 00 20 00 6d 00 65 > .P.h.o.n.e. .m.e > 0010: 00 6d 00 6f 00 72 00 79 00 00.m.o.r.y.. > > HCI Event: Number of Completed Packets (0x13) plen 5 > handle 45 packets 1 > > ACL data: handle 45 flags 0x02 dlen 13 > L2CAP(d): cid 0x0041 len 9 [psm 3] > RFCOMM(d): UIH: cr 0 dlci 12 pf 1 ilen 3 fcs 0x89 credits 1 > OBEX: SetPath rsp(f): status 401 len 3 > > Can I somehow match the status 401 to the final error code? hcidump converts the one byte OBEX errors to HTTP equivalents (since they are originally derived from HTTP anyway). 401 would therefore mean "Unauthorized", i.e. most likely you are at least giving the right directory name (otherwise you'd get 404 = "Not Found") but the server refuses the action. gwobex in turn uses the byte value as it comes over the air and so you should be getting 0x41 (i.e. 65) in your application in this case. > Thank you for your help! No problem! :) Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gwobex problem
On Tue, Oct 06, 2009, Christian Kuersteiner wrote: > Do you think from the gw-obex point of view that it matters that I will > not connect to the OBEX FTP profile but rather to the OBEX Push profile? > I try to implement a Bluesnarf++ attack where this is the case. gw-obex doesn't really care which OBEX profile it's connected to. The different functions will always try to do the same operations (but they are of course likely to fail if you connected to OPP but try to use FTP operations such as folder listing or SetPath). Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gwobex problem
Hi Christian, On Mon, Oct 05, 2009, Christian Kuersteiner wrote: > I'm using GwObex to achieve some Obex FTP functionality. I can list the > root directory on my test phone with gw_obex_read_dir(). However it > fails when I try to change in a directory with gw_obex_chdir(). > What I suspect is that since all my directory has a whitespace (e.g. > "Memory Stick", "Phone memory") the function fails. Did somebody > encounter similar problems? Is there a workaround or did I misunderstand > the API (the directory name should be UTF-8 but I think this doesn't > matter with whitespaces)? What you describe should be work just fine. Note that the directory name shouldn't be the absolute path but just the name of the directory as it is relative to the current directory. One thing you could do to debug this further is to take a HCI trace of the data that gets transmitted. I.e. install bluez-hcidump and run "hcidump -XV" while doing the test case (be sure to start hcidump before connecting so it is able to deduce that the high-level protocol is OBEX). Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: The *right* way to do a2dp
Hi, On Fri, Jun 26, 2009, Andre Klapper wrote: > Am Donnerstag, den 25.06.2009, 19:50 -0400 schrieb Nick Nobody: > > I just got a pair of bluetooth headphones and was wondering what is the > > right way to enable a2dp. > > No real help from my side; but if you find out please add a comment to > https://bugs.maemo.org/show_bug.cgi?id=2754 to share knowledge. I think it's good to point out that the bug in question is not about what was requested (support for connecting to A2DP headphones) but for the opposite role (acting as an receiver for audio (i.e. A2DP Audio Sink) ourselves). Regarding enabling A2DP with diablo, I don't think there's any single "right" way since imho that would require proper integration with the system wide audio routing policies which'd (afaik) require changes to components which aren't open. What can be done (and what has already been done) is to make use of the BlueZ ALSA userspace plugin and gstreamer elements that come with the diablo rootfs and the point a third-party ALSA or gstreamer player to use them. However, as I mentioned this is still not the same kind of integration that has been done for the mono Headset profile in diablo. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: openobex and bluetooth problem, Maemo 4.1.2
Hi, On Tue, May 26, 2009, Christian Kuersteiner wrote: > I try to use openobex (with libopenobex1-1.3osso5) with bluetooth. When > I use BtOBEX_TransportConnect() on the tablet I get an error (negative > value). If I use the same code sequence on my Ubuntu system everything > works fine. > Has anybody some experience with libopenobex and bluetooth? Is it > possible that bluetooth is not supported with the openobex library for > maemo? You can use the maemo libopenobex with Bluetooth but you need to use FdOBEX_TransportSetup and give it a connected RFCOMM socket. The BtOBEX* functions are not available in the maemo version of openobex since including them would mean linking with libbluetooth which in turn would mean that libopenobex (and all applications linked to it) would become GPL (instead of LGPL which is its intended license). > To try another way I took my chance with GW Obex (the libopenobex > wrapper). Somehow I am stuck again. This time when linking my program I > get the following error: > > snarfattack.cpp:51: undefined reference to `gw_obex_setup_fd(int, char > const*, int, _GMainContext*, int*)' > collect2: ld returned 1 exit status > > From googling about I saw that this is normally a problem with not > giving the library to the linker. But I give the parameters "-lgwobex > -lglib-2.0 -lopenobex" which are needed for libgwobex and the linker > doesn't complain that there is not such a library. May somebody give me > a hint what is going wrong and where I might look for a solution? I am > sure it is a probably stupid error in my setup but I just get out of ideas. It's a long time since I last did anything with gwobex, but the provided pkg-config files should contain the right compiler and linker options. Your issue might also be something C++ specific (I noticed your .cpp suffix) which I know very little about. You might also want to take a look at osso-obc which is a command line obex client that uses gwobex: https://stage.maemo.org/svn/maemo/projects/connectivity/osso-obc/trunk/ Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Would like to know the status of (was RE: Corporate ownership of open source projects [LWN])
On May 7, 2008, at 14:18, Simon Pickering wrote: > 1. DSP SBC task - In the roadmap there used to be (what I > interpreted as) > mention of implementing a DSP task to handle encoding audio for A2DP > use > (where A2DP stands for Advanced Audio Distribution Protocol and is a > Bluetooth protocol for sending data to Bluetooth stereo headsets > [1]). SBC > stands for subband codec, which is the default encoding method > required by > A2DP hardware. At the moment this encoding must be carried out by > the ARM in > software, but if the task could be offloaded to the DSP it would > free up the > ARM to do other things (such as decoding video better). > > This is really just a yes/no, are Nokia doing anything as if they > are, I > won't bother. AFAIK no. However, you might want to take a look at the recent optimizations that have been made to the SBC codec that comes as part of BlueZ. Several of the optimizations specifically target arm so the value of pushing the encoding to the DSP side is less than it was e.g. one year ago (however it might still have enough value for being worth doing if you have the time and interest). Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Source for bluez-utils
Hi Paul, On Sat, Feb 03, 2007, Paul Brook wrote: > Where can I find up to date source for the bluez-utils package? > repository.maemo.org contains the binaries for version 3.7osso11, but the > source packages are only version 3.7osso6. I'm not sure why the repo doesn't have a matching source package for the binary package (it *should* have it), but you can at least get the source from svn: https://stage.maemo.org/svn/maemo/projects/connectivity/bluez-utils/tags/ Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] wiiremote (Was: Nokia: simple method to gain agaming audience on 770/800)
Hi Kon, On Wed, Jan 24, 2007, Kon Wilms wrote: > The wiimote will not pair with the N800/770 via the onscreen dialogs because > they force input of at least a one digit passkey for the bluetooth pairing. > The wiimote doesn't make use of passkeys - it will simply pair without one. Actually this is not quite correct. The wiimote doesn't support pairing at all (and if it did the Bluetooth specification would require a minimum one digit passkey). The "connect" that the UI allows you to do to paired devices simply calls the "hidd --connect " command, so you should be able to connect to your wiimote just fine by issuing that command e.g. from the command line. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Bluetooth Headset Support - Status update?
Hi, On Sat, Jan 13, 2007, Gopi Flaherty wrote: > Does anybody know if the N800 uses the same Bluetooth chipset as the > 770? 770 has a TI chip while the N800 uses a CSR chip (BlueCore4). To use SCO audio using existing bluez software you need to get the chip into SCO over HCI mode (I think both devices are by default in SCO over PCM mode, i.e. try to transfer audio over a direct HW link between the bluetooth controller and the DSP). You'll probably find the procedure for manipulating the SCO routing on the CSR chip somewhere on bluez related web pages (maybe the available SW even does it automatically) since CSR dongles are quite popular. I don't know the exact procedure my self. AFAIK, the procedure of changing the SCO routing on the TI chip requires a proprietary TI HCI command. I'm not sure we can publish it since it's documented in TI docs which have quite strict publication restrictions. I.e. this still needs some internal investigation. However, even with the command, neither the chip firmware nor the driver have been tested with SCO so there is guarantee that it'd work. We are currently working on integrating SCO support (Headset Profile to be exact) nicely with the new and still experimental D-Bus based service infrastructure of bluez and the rest of the internet tablet software. The plan is to use the DSP routing instead of the HCI routing, which should improve latencies. So, you should see support for this in some SW update in the future. Unfortunately I can't give any exact schedule currently, but you can follow the progress quite well simply by looking at what's going on with bluez (i.e. CVS commits & mailing list discussions). You'll probably see some preliminary support in the next release of bluez-utils (version 3.9). Oh, and it's possible that A2DP support will come along at some point too since from the bluez side the plan is to integrate it to the same audio daemon as HSP/HFP. However, from our (Nokia) perspective it hasn't been given the same priority as HSP so in the short term support for it will be very unofficial if it exists at all. Some ideas (a very early draft) for the planed architecture can be found at the bluetooth-alsa pages: http://bluetooth-alsa.sourceforge.net/future.html Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Bluetooth pairing with Motorola V3i
On Fri, Nov 03, 2006, Chris Lord wrote: > On Fri, 2006-11-03 at 16:31 +0200, Kimmo Hämäläinen wrote: > > On Fri, 2006-11-03 at 14:01 +, ext Chris Lord wrote: > > ... > > > As far as my phone is concerned, it seems to be paired, but no pair is > > > stored on the 770. This used to work perfectly on the 2005 edition and > > > pairing still works perfectly with my friend's Motorola V3 (just not my > > > V3i..) > > ... > > > > Did you try pairing the phone again with the 770 after upgrading to > > IT-2006? > > Yes, pairing is what is failing here. I have a V3i too, and it pairs just fine. Actually, we ordered this phone precisely because we got these problem reports with it. I heard that there's a bug in some motorola phone firmware versions when doing an SDP service search attribute request (which is what IT-2006 does). Though that doesn't quite explain why it works on 2005 for you. You might want to try to get a firmware update for your phone and see if it solves the problem. The problem should also go away with future versions of our software when the UI starts completely using the BlueZ D-Bus API. This is because bluez will do an SDP service search request and then a separate service attribute request which apparently should work fine with these buggy phones. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] BT PIN blues ...
Hi Ian, On Tue, Aug 01, 2006, Ian Malcom wrote: > I am trying to use com.nokia.btpin. I register my own > handler. My "guess" at the signature is no arguments > in, a string out. However, the handler function never > ends up getting called. Looking at code snippets, I > "believe" that btpin will send my handler a PinRequest > message. Using the system monitor shows no activity > other than the pin_req message. > > Any help would be much appreciated! I need to get this > working for a school project in the next few days, and > the lack of documentation is driving me to tears. Take a look at the README [1] file which comes with osso-bttools source (the package that btpin belongs to). It describes the handler registration interface. The actual pin request interface is identical to the one that pre-3.0 versions of bluez have when configured to use D-Bus for pin handling (unfortunately this interface doesn't have much documentation). [1] http://www.maemo.org/platform/docs/bttools.html To parse the parameters in the pin request use something like the folowing: dbus_message_get_args(message, NULL, DBUS_TYPE_BOOLEAN, &out, DBUS_TYPE_ARRAY, DBUS_TYPE_BYTE, &bda, &bdalen, DBUS_TYPE_INVALID)); The pin reply consists of one string parameter. For more details take a look at the btpin and bluez-pin source code. Btw, in the future btpin will go away in favor of the new D-Bus passkey handler system provided by hcid (which is actually very similar to btpin). This bluez D-Bus interface is actually already in the 2006 release and btpin is just a wrapper to it. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] (no subject)
Hi, On Wed, May 31, 2006, Ade Bamigboye wrote: > To fully make use of the BlueZ stack, an application needs to run as > root on the N770. > > Is there an easy way to make an application always run as "root" ? Currently no. However, (AFAIK) the 2006 OS release will allow you to install packages with root privileges. > Is there an alternative for applications to access functions within > the SDP without running as root. Are you talking about server or client side SDP functionality? Enabling sdpd on the current SW releases requires root, but creating new local service records or performing client side operations should be possible without root. (btw, the 2006 OS release will have sdpd running by default so that problem will be solved there). Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] chatscript/syslog question
Hi, On Wed, May 10, 2006, Mischa Molhoek wrote: > is there a way i can find out what AT command is sent to my nokia > phone by my nokia 770. > > there is no syslog, so i can't see whats happening. or can i..? how:) AFAIK it's not possible with an unmodified SW image. If you're ready to get root privileges and install some extra stuff your options are one of the following: 1. install and use hcidump (bluez-hcidump package) 2. install syslog (klogd & sysklogd packages) Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Disconnect rfcomm stays between bt_disconnected and rf_disconnected
On Thu, Apr 06, 2006, Jari Tenhunen wrote: > 'hciconfig hci0 down; hciconfig hci0 up' failed for me too, i.e. it > didn't revive the BT. So that trick isn't excactly the same as putting > the cover on or switching to offline mode. Well, that should be exactly what happens when you put the cover on, with the possible exception that btcond will also try to disconnect any open connetions. So you may also want to try hcitool dc before running the hcitool hci0 down command. Also make sure that you are root when running the commands. > Johan, do you have any idea on what is causing the BT jam in these > cases? Unfortunately not, but it sounds like a quite low level problem (maybe in the BT chip firmware). However, we're investigating it. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Disconnect rfcomm stays between bt_disconnected and rf_disconnected
On Thu, Apr 06, 2006, Johan Hedberg wrote: > Or using the HCIDEVDOWN and HCIDEVDOWN ioctl's from C code. That should be HCIDEVDOWN and HCIDEVUP of course (see the source code for hciconfig or btcond for examples). Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Disconnect rfcomm stays between bt_disconnected and rf_disconnected
On Thu, Apr 06, 2006, koos vriezen wrote: > For the short term, it would be helpfull if someone could point to a > way to disable this device, like w/ offline mode or plastic cover, > programmaticaly. Using the commandline: hciconfig hci0 down hciconfig hci0 up Or using the HCIDEVDOWN and HCIDEVDOWN ioctl's from C code. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] What BlueZ protocols / interfaces are actually supported on the N770 ??
Hi, On Mon, Mar 06, 2006, Ade Bamigboye wrote: > If the bluez Bluetooth stack is included with the N770 operating system one > would assume that all bluez protocols and interfaces are supported without > exception. > > This does not appear to be the case as certain HCI interface functions are > not accessible from applications running on the N770. > > Is there a definitive list of protocols / interfaces actually supported on > the N770 ? where can we obtain this information ? The bluez software on the 770 has not been modified in any special way, so it should support whatever normal bluez supports. The kernel is of course enforcing a security policy on some HCI commands so you need root privileges for them. Could you perhaps describe your use case in more detail, and tell exactly what you have found out not to be working? Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Creating Bluetooth connections programmatically ?
> What is the best way to programatically create and authenticate a > bluetooth connection to a a bluetooth device ? > > In this scenario the N770 is acting as the Master device. HCI commands > such as hci_read_remote_name work but hci_create_connection seems not > to work. hci_create_connection requires root privileges. If you only want to do a pairing with the remote device you can use btpair (via D-BUS or by calling it directly from the command line): http://www.maemo.org/platform/docs/bttools.html Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Registering bluetooth service
Hi, On Mon, Feb 13, 2006, Ari Paavilainen wrote: > Has anyone managed to register a bluetooth service to local sdp server. > I have a piece of code that tries to do that but it fails in call to > sdp_record_register(). Error is 29 = ESPIPE = Illegal seek. By default the 770 does not have sdpd enabled. You can enable it e.g. by editing /etc/init.d/bluez-utils (find the line that starts with SDPD_ENABLED=). After the change you'll either need to reboot or run /etc/init.d/bluez-utils restart. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] btcond / d-bus problems
On Wed, Dec 28, 2005, Andrew Ramsay wrote: > That seems to have done the trick, I reflashed it, installed xterm and > ran the dbus-send command again, and this time it popped up a window asking > for the passcode then returned "/dev/rfcomm0". Thanks for your help. Nice to hear that it's working. Btw, there's a known bug with the rfcomm_release method: it does release the device but btcond forgets to update its list of bound devices so subsequent calls to rfcomm_bind will return a "profile already bound" error. This has already been fixed in our local repository and I'll try to get the fix also to future official SW releases. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] btcond / d-bus problems
On Wed, Dec 28, 2005, Andrew Ramsay wrote: > Is there anything obviously wrong with that? Nothing obvious, except that you should be passing a pointer to the string (i.e. char **) when calling get_args (and when done with the returned string free it with dbus_free). However, that shouldn't cause the problem you're describing. Do you get the same result if you use dbus-send from the command line: dbus-send --system --type=method_call --print-reply \ --dest=com.nokia.btcond /com/nokia/btcond/request \ com.nokia.btcond.request.rfcomm_bind string:00:02:76:C0:56:A4 string:SPP Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] btcond / d-bus problems
Hi Andrew, On Tue, Dec 27, 2005, Andrew Ramsay wrote: > I started off with the basic example program which just connects to the > session bus, lists the services available, then exits. That works fine > with both session and system buses. I then tried to modify it slightly to > obtain a proxy for the "com.nokia.btcond" service, which didn't work until > I discovered you had to connect to the system rather than the session bus. > Once I'd got the proxy, I tried to call the rfcomm_bind method as > suggested in the wiki. However, all I get back is an error saying that > this method doesn't exist on the com.nokia.btcond.request interface. > Calling any of the other methods results in the error > "com.nokia.btcond.invalid_dev", which is supposed to indicate an invalid > BDA from what I can tell, although the address I'm using is definitely > correct. You didn't mention which object path you're using, but it should be "/com/nokia/btcond/request". You should also be giving the rfcomm_bind method call two arguments: the BT address (e.g. "11:22:33:44:55:66") and the profile name (e.g. "SPP"). > Can anyone help me out here? As I said, I have no previous experience with > D-BUS programming, so I may well be doing something very wrong and just > haven't noticed yet. I'm using the Glib bindings for D-BUS since that was > what the example code used. If anyone has actually done this already I'd > be very interested to hear how you did it. It is quite possible that the GLib bindings are buggy in the D-BUS version that the current 770 SW images use. If you are still experiencing problems I'd recommend trying out the low level C-bindings. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] bi-di BT-link between two 770s
On Wed, Nov 09, 2005, Johannes Eickhold wrote: > As the wiki states on http://maemo.org/maemowiki/BluetoothGPS root > access is requiered to create the needed rfcommX device node. Following > that HowTo i successfully read NMEA data from my GPS mouse. I don't know > how to do this without such a device node. I just updated the wiki page by removing unecessary steps. I also added some info about using the btcond API. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] bi-di BT-link between two 770s
On Wed, Nov 09, 2005, Johannes Eickhold wrote: > > Searching for remote devices and creating outgoing RFCOMM connections > > (e.g. to serial port profile) doesn't require root privileges, so that > > should work just fine with the normal firmware. > > As the wiki states on http://maemo.org/maemowiki/BluetoothGPS root > access is requiered to create the needed rfcommX device node. Following > that HowTo i successfully read NMEA data from my GPS mouse. I don't know > how to do this without such a device node. Well, the wiki is wrong :-) You can connect to the device as normal user using e.g. "rfcomm connect /dev/rfcomm0 " (the mknod part in the wiki is unecessary because udev should do the job for you). The bind method described in the wiki does indeed require root privileges, but even in that case you can use the rfcomm_bind method of the btcond D-BUS interface [1] which doesn't require root privileges. Actually, if you intend to use gpsd for GPS access I think the bind method is better because gpsd will only open the device when needed (so the BT connection will also only be created when needed). [1] http://www.maemo.org/platform/docs/osso-gwconnect.html Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] bi-di BT-link between two 770s
On Sun, Nov 06, 2005, Patrick Ohly wrote: > Another use of Bluetooth could be connecting the 770 to a GPS receiver. > With its large screen it would make a nice moving map display, although > my primary use would be to simply transfer waypoints and track data to > and from a Garmin eTrex during cycling trips. I currently use an iPAQ > with Familiar Linux for that purpose, but might replace that with the > 770 if I can get it to work - currently I still wait for a > Bluetooth<->RS232 adapter (the eTrex only has a serial port). > > I'm sure it can be done with root access, but making the same > functionality also available to users of the official firmware > certainly would be nice. Searching for remote devices and creating outgoing RFCOMM connections (e.g. to serial port profile) doesn't require root privileges, so that should work just fine with the normal firmware. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] bi-di BT-link between two 770s
Hi Aleksandr, On Sun, Nov 06, 2005, Aleksandr Koltsoff wrote: > 1) When starting the game, how does the end-user "see" the other 770-device? > ie, is pairing necessary, and is there a GUI for this (connection damager?) There's no GUI for currently for this. Pairing isn't necessary, but you may want to implement it if you want better security for the connection. > 2) What do I need to do to make 770 visible to the other 770 (assuming there > is a GUI for this on the other side). Can this be done programmatically > without requiring user intervention? It's possible to do programmaticatlly, but requires root privileges. You might want to take a look at the source code of hciconfig to see what it does with the piscan command. If you want inquiry scan (aka discoverable mode) to be always enabled you can also set "enable iscan" in /etc/bluetooth/hcid.conf. > 3) Is using RFCOMM-sockets between the devices a suitable transport? (I'm > looking for something akin to TCP). It can be assumed that only one program > will be active on a device at one time that needs this, so I guess BT-MAC > address is enough to connect? An RFCOMM socket is probably good for your needs. You'll need the BT address as well as an RFCOMM channel (comparable to TCP port numbers) to connect. > 4) Can all of this be done with a normal application installed via the AI on > a > stock 770? (not requiring the user to reflash from the sales sw version) Currently unfortunately not. I have gotten requests for implementing a D-BUS interface in btcond for enabling inquiry scan (so root privileges wouldn't be required), however that will be available earliest sometime next year in an official firmware update. If you have any more Bluetooth or BlueZ specific questions I'd recommend using the bluez-users and bluez-devel mailing lists since they have probably much more knowledgeable subcribers in this area. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] flasher utility - new versions for MacOS X and PowerPCs running LInux
On Thu, Oct 27, 2005, Sjoerd Simons wrote: > It crashes on my powerbook running Debian sid: > > # ./flasher.linux_ppc --query-rd-mode > Suitable USB device not found, waiting > *** glibc detected *** corrupted double-linked list: 0x10093568 *** > zsh: 32458 abort ./flasher.linux_ppc --query-rd-mode I've bumped to that bug also a couple of times. One solution is to turn on the 770 at the right moment so that the flasher doesn't go into the loop of waiting for the device to be found (i.e. turn on 770 and almost immediately afterwards run the flasher tool). Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Success: Network using PC BT Network Access Point
On Thu, Oct 27, 2005, Ilkka Urtamo wrote: > PS. Anyone already working on the NAP support for gwconnect? If not, I > could take a look. AFAIK, no. However, I'm not so sure it even makes sense since there's already pand on the system. If you want to have a D-BUS interface for PAN the effort would be best directed at the new D-BUS daemon that will be included as a standard part of bluez (see bluez-devel mailing list for more info). I think PAN is also one of the first priorities of the INdT guys who are working on it. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Network using PC BT Network Access Point
On Wed, Oct 26, 2005, Ilkka Urtamo wrote: > First tries with DUN was unsuccessfull, for some reason device refuses > to see my DUN in the PC and complains that "phone does not have > services". What does "sdp-query -s DUN " from a x-terminal on the 770 show? What about "sdptool search --bdaddr DUN"? > My question is, how does the osso system (or dbus or what ever is > responcible) determines when net connection is available? http://maemo.org/maemowiki/DummyIAP > PS. It seems normaly connections are made by btcond and I would modify > that but I cant find source code for btcond anywhere. http://repository.maemo.org/pool/maemo/ossw/source/o/osso-gwconnect/ Though that version is *very* old. Hopefully a new package will be uploaded by the SDK team soon. However, btcond only supports creating RFCOMM connections to some specific services (such as DUN, SPP, OPP, FTP), so it probably won't be of much use if your intention is to use PAN. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] N770 slow/Bluetooth discovery
On Thu, Jun 30, 2005, Timo Steuerwald wrote: > What's about the question related to bluetooth? By default, the 770 will have both page scan and inquiry scan disabled (i.e. be non-connectable and non-discoverable). Enabling those scan modes is just a matter of issuing a simple HCI command. For example using the bluez-utils command line tools you can enable both scans the command "hciconfig hci0 piscan". However, there will be no way to enable the scan modes from the default 770 UI. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] networking questions & requests
Hi Marcel, On Tue, Jun 14, 2005, Marcel Holtmann wrote: > we can discuss these things at the LinuxTag in detail next week and > someone can give me a Nokia 770 for development ;) Unfortunately I'm not attending LinuxTag. But, I promise I'll put a good word in for you for the developer device program* ;-) Johan * http://www.maemo.org/news/25052005.html ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] networking questions & requests
On Tue, Jun 14, 2005, Claudio Takahasi wrote: > Another issue that I would like to suggest to keep the code > in the bluez community in order to make the maintenance > easier. Why D-BUS service was not provided in the > bluez-utils dund? I believe you and Marcel can discuss later. It would probably not have been a bad idea to use dund for DUN connections had it had a D-BUS interface. However, I don't think the current solution where all RFCOMM connections are centralized in btcond is a bad idea either. Nevertheless, I'm pretty open to ideas how to do bluetooth connectivity by having as many SW layers as possible in common with the bluez and desktop linux community. There was even some cooperation discussions with Edd Dumbill (who has developed gnome-bluetooth) in the end of last year, but mainly due to lack of time resources from both parties there hasn't really been any progress on that front. Anyway, the Bluetooth SW architecture is in no way "fixed" with regard to maemo and future products, but for the 770 it's too late to start changing things. > Regarding the implemented daemons, I didn't see integration > with libosso. Is there plans for it or it is not necessary? I don't think it's necessary since they're dealing with pretty low level stuff. AFIAK libosso is meant mainly for applications. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] networking questions & requests
On Tue, Jun 14, 2005, Marcel Holtmann wrote: > I hope you are aware of that the storage format and its location of the > link keys are changed starting with the bluez-utils-2.16 release. Yes, I'm aware of that. We'll just have to start using another tool (or change btlk) when we switch to 2.16. However, it seems most likely that 2.15 will be used in the 770, so that is what the current tools are designed for. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] networking questions & requests
On Mon, Jun 13, 2005, Claudio Takahasi wrote: > Currently, user level applications are not allowed to control > bluetooth connections or search for services. You might be interested in the functionality provided by osso-bttools and osso-gwconnect packages. osso-bttols provides tools for doing e.g. bluetooth pairing and handling of link-keys. osso-gwconnect provides D-BUS interfaces for Bluetooth search (inquiry), SDP and creating RFCOMM connections (such as dialup or file transfer). All of this is accessible by user applications using the system D-BUS (actually the link key editor, btlk, only has a command line interface, but a D-BUS interface could easily be added to it as well). Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] 800x480
On Tue, May 31, 2005, Daniel Monteiro wrote: > any idea if Maemo or the 770 works with Bluetooth keyboards? Currently there's no support for it. However, it should be pretty easy to hack together since BlueZ already supports it. The biggest task would probably be creating a decent UI for it. BT keyboard support is also planed for future versions of maemo and 770 type of devices. Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
