From: Alex K. <ak...@se...> - 2005-07-21 18:16:52
|
Hi, I've made a page with the OpenOBEX USB patches, and various bits of information and links; check it out: http://www.sensi.org/~ak/openobex-usb/ If you want the latest USB OBEX patches, you should take them from this page. In other news, I've stumbled across unannounced preview release of obexftp 0.10.8; it fixes the transport connectivity mess in obexftp library, adds USB support and other things: http://triq.net/obexftp/beta-testing/ Cheers, Alexander Homepage: http://www.sensi.org/~ak/ |
From: Christian Z. <za...@tr...> - 2005-07-21 20:21:42
|
Hi, Alex Kanavin wrote: > http://www.sensi.org/~ak/openobex-usb/ No need to make people bugging Marcel. I'd like to see USB in OpenOBEX too, but there is still work to be done -- not people to be convinced. > In other news, I've stumbled across unannounced preview release of > obexftp 0.10.8; it fixes the transport connectivity mess in obexftp > library, adds USB support and other things And most important, it has a new very unstable incompatible API. While you may want to give it a try (especially with obexfs), please don't spread the word. There is no support for preview snapshots. cu, Christian |
From: Alex K. <ak...@se...> - 2005-07-21 20:38:02
|
On Thu, 21 Jul 2005, Christian Zuckschwerdt wrote: >> http://www.sensi.org/~ak/openobex-usb/ > > No need to make people bugging Marcel. I'd like to see USB in OpenOBEX too, > but there is still work to be done -- not people to be convinced. Yeah, that wasn't such a grand idea - I removed the bit :) Alexander Homepage: http://www.sensi.org/~ak/ |
From: Alex K. <ak...@se...> - 2005-07-22 11:22:56
|
On Fri, 22 Jul 2005, Hendrik Sattler wrote: > However, you do something strange, too: > obex_return_val_if_fail(interface != NULL, -1); > in function > int UsbOBEX_TransportConnect(obex_t *self, struct usb_obex_intf* interface) > > You fail without looking for already scanned devices. I'd rather suggest that > if interface == NULL, take the first one from the list and only fail if the > list ist empty. This would make is easier for an application author. Er, no. There can be many USB OBEX interfaces on one device (all Nokia phones I know have two - one for SyncML, another for filetransfers), and the library should not guess which one the application wants. Similarly, Nokias have no less than four Bluetooth OBEX interfaces (Object Push, File Transfer, SyncML and PC Suite Services, which is apparently same as filetransfer, only giving access to the whole phone's filesystem - plain filetransfer only provides access to the inbox folder on the phone), so you can't just pick the first one. > Still, UsbOBEX_GetInterfaces() is exactly what I meant. Somthing that can be > extended to bluetooth and IrDA. I'd do it if noone else wants (the code is > extually already there), if the openobex author actually thinks that this is > the right direction. You need to provide some information about the discovered interfaces, so that the applications can pick the one they want. For Bluetooth I think device, address, port, service class list, profile descriptor list and service name string are good enough. > Why doing all this? My wishlist includes obexftp being able to scan for and > list all possible devices like "obexftp -F" listing IrDA, bluetooth and USB > devices (serial is not detectable) in _one_ command. Splitting interface scans by transport type (obexftp -b, obexftp -U) is quite fine I think. I'll write a patch that adds USB scanning to obexftp, it's really easy. >> That would be really useful I think. The tricky part is how to unite all >> possible transports in one structure - discovery has to return useful >> iinformation about discovered interfaces to use in UI frontends and that >> varies greatly from transport to transport. USB OBEX discovery already >> provides that. > > I did not mean the unification of those function. Currently, openobex scans > for the first IrDA device with OBEX support and not at all for bluetooth. The > program cannot use this scan functionality to choose a device (except for > USB). I agree. I had a look and apparently what happens with irda is that you can either supply an address yourself when making a connect request, or, if you don't do that, the library would do a proximity scan and pick the last device on the list. Which I think isn't clever at all. What if there are several devices around? What if a device has several OBEX services (not sure if it's possible with infrared, but anyway)? Alexander Homepage: http://www.sensi.org/~ak/ |
From: Christian Z. <za...@tr...> - 2005-07-22 13:07:59
|
Hi, Alex Kanavin wrote: >> if interface == NULL, take the first one from the list > > the library should not guess which one the application wants. Actually that would be a nice thing to have. The lib should enumerate all possible connections in a simplyfied format, preferably in some stable order. The application can choose the right one or stick to defaults. I'd like to see just transport, device and port. Perhaps the port could be abstracted into classes with fallbacks. (If the app didn't say Push or SyncML we should try PC Suite then FT then Push). The app could also probe the enumerated ports as long as they all make sense. > You need to provide some information about the discovered interfaces, > so that the applications can pick the one they want. For Bluetooth I > think device, address, port, service class list, profile descriptor > list and service name string are good enough. Far too much info. Whats device compared to address? Does the usb-port matter? Should we pick from service class or profile desc? I think the list of possibilities should be filtered, sorted and presented in a simplified way. (Perhaps we can try to _think_ of stuffing this info into a http style address bt://address_or_name:port_or_class would do.) Alex, do you think this can be done for USB? >> list all possible devices like "obexftp -F" listing IrDA, bluetooth >> and USB >> devices (serial is not detectable) in _one_ command. > Ideally the user could just give the device name and the app would just pick the transport as fit. That way the device can be a user default and the transport wont matter. (My phone backup scripts need to try both IrDA vs BT to see where the phone is today.) >>> The tricky part is how to unite all possible transports in one structure >> That structure (or just string) doesn't have to be precise or useable to do the real connect. It just has to be unambiguous. I'm thinking of what the user would enter or choose in the gui. (like the http example) cu, Christian ps. Is everyone on the list? I don't like recieving every mail twice, perhaps we can keep this discussion just on the list. |
From: Alex K. <ak...@se...> - 2005-07-22 13:35:07
|
On Fri, 22 Jul 2005, Christian Zuckschwerdt wrote: >>> if interface == NULL, take the first one from the list >> >> the library should not guess which one the application wants. > > Actually that would be a nice thing to have. The lib should enumerate all > possible connections in a simplyfied format, preferably in some stable order. > The application can choose the right one or stick to defaults. > I'd like to see just transport, device and port. Perhaps the port could be > abstracted into classes with fallbacks. (If the app didn't say Push or SyncML > we should try PC Suite then FT then Push). > The app could also probe the enumerated ports as long as they all make sense. Device and port isn't enough for USB - you need a whole structure to reliably identify an USB OBEX interface. See my patch (obex_const.h) for details. But I agree that openobex should provide applications with a list of all possible interfaces, list entries could look something like that: struct obex_interface { struct obex_interface *next; struct obex_interface *prev; int transport char* device_name; char* interface_name; int capabilities; struct* usb_obex_interface usb_intf; struct* bluetooth_interface bt_intf; ... // pointers to detailed interface structures for all possible transports } > Far too much info. Whats device compared to address? Does the usb-port > matter? Should we pick from service class or profile desc? Is the above structure simple enough? > I think the list of possibilities should be filtered, sorted and presented in > a simplified way. (Perhaps we can try to _think_ of stuffing this info into a > http style address bt://address_or_name:port_or_class would do.) Alex, do you > think this can be done for USB? No, it can't. I wish it was. > That structure (or just string) doesn't have to be precise or useable to do > the real connect. It just has to be unambiguous. I'm thinking of what the > user would enter or choose in the gui. (like the http example) Again, what do you think about my suggestion for the structure? > ps. Is everyone on the list? I don't like recieving every mail twice, perhaps > we can keep this discussion just on the list. I don't know about Hendrik, but I am. Alexander Homepage: http://www.sensi.org/~ak/ |
From: Christian W. Z. <Christian@Zuckschwerdt.org> - 2005-07-22 15:28:39
|
Hi, Alex Kanavin wrote: > Device and port isn't enough for USB - you need a whole structure to > reliably identify an USB OBEX interface. I still can't see why usb has to be so difficult. I think selecting a device by transport and address is agreed upon. That leaves us just with selecting the class/service/port thing. Can't that be an enumeration or list of possible ports? > Is the above structure simple enough? Can you explain the fields interface_name (is this the port?) and capabilities (is this really needed to identify the connection?). Then what is in those _intf structures? For BT we need nothing more than address (or a nick name/alias) and port (channel). Like Hendrik said, I would go for arrays and unions, too. > think of stuffing this info into a http style address > bt://address_or_name:port_or_class > > No, it can't. I wish it was. Using usb bus and device gives you a unique device and isn't useful at all for the user (replug the device and those numbers change) That leaves us with vendor:product which could be ambiguous. My Siemens gives its IMEI as serial. That gives us vendor:product or the serial to select a usb device. Which in turn just leaves the interface (and that is an int) to be specified, right? This assumes the connection is specified by the user (in a simple format). If the app needs to choose the connection from a list (array) there is need for some additional information. This info on the other hand should not be needed to finally select the connection. What I'm trying to say is that we should keep choosing and selecting a connection as seperate cases. cu, Christian |
From: Alex K. <ak...@se...> - 2005-07-22 16:45:47
|
On Fri, 22 Jul 2005, Christian W. Zuckschwerdt wrote: >> Device and port isn't enough for USB - you need a whole structure to >> reliably identify an USB OBEX interface. > > I still can't see why usb has to be so difficult. I think selecting a device > by transport and address is agreed upon. That leaves us just with selecting > the class/service/port thing. Can't that be an enumeration or list of > possible ports? The problem with USB is that libusb just doesn't support this address:port naming scheme. To connect to a USB OBEX interface you need to supply struct *usb_device pointer (which you first select from a list that libusb provides), configuration number, and control and data interface numbers. I don't think there's a reliable way to map those into an address:port string and vice versa, that also survives between replugs.(see below) > Can you explain the fields interface_name (is this the port?) and > capabilities (is this really needed to identify the connection?). Then what > is in those _intf structures? For BT we need nothing more than address (or a > nick name/alias) and port (channel). interface_name is a user-readable interface name - both Bluetooth and USB provide those. Capabilities is a bit field with interface capabilities (file transfer, syncml and so on). In _intf structures you have detailed information about the interface address, such as address:port for bluetooth, or things I named above for USB, which are needed to establish a connection. You can map those into a URL in your application if you want to, but I don't think we should try it on the library level. > Like Hendrik said, I would go for arrays and unions, too. I agree. >> think of stuffing this info into a http style address >> bt://address_or_name:port_or_class >> >> No, it can't. I wish it was. > > Using usb bus and device gives you a unique device and isn't useful at all > for the user (replug the device and those numbers change) That leaves us with > vendor:product which could be ambiguous. My Siemens gives its IMEI as serial. > That gives us vendor:product or the serial to select a usb device. Which in > turn just leaves the interface (and that is an int) to be specified, right? lsusb says this about my Nokia: iManufacturer 1 Nokia iProduct 2 7610 iSerial 3 0123456789 So in this case also the serial is the same for any phone. Which means there is no way to identify a USB device in a unique way between replugs. Also, to connect you need a configuration number, not just an interface number. Alexander Homepage: http://www.sensi.org/~ak/ |
From: Christian W. Z. <Christian@Zuckschwerdt.org> - 2005-07-22 18:03:32
|
Hi, Alex Kanavin wrote: > I don't think there's a reliable way to map those into an address:port > string and vice versa, that also survives between replugs. Then what is the point in selecting a specific connection? If the user/application can't reliably choose a connection its useless because we'll have to probe every connection, right? The user wants to connect to a given phone (i.e. address, imei, type, nickname) and use a given service (i.e. obex ft, syncml, you name it). If there is no way to do so just enumerate the possible connections and probe them all (pull telecom/devinfo.txt or the xml service list). > interface_name is a user-readable interface name - both Bluetooth and > USB provide those. Capabilities is a bit field with interface > capabilities (file transfer, syncml and so on). So those are for informational purpose only? > map those into a URL in your application if you want to, That URI example was just to illustrate the need for the lib (or app) to handle simple user request to choose a connection. > So in this case [Nokia] the serial is the same for any phone. Which > means there is no way to identify a USB device in a unique way between > replugs. Like I said above. The lib should take care of the icky bits especially if we can't choose the right device. Just select them in turn and probe for the IMEI or something. > Also, to connect you need a configuration number, not just an > interface number. I see. Thats two numbers. Not a big deal to either expand the port scheme, fold them into one or just enumerate all possible pairs. cu, Christian |
From: Hendrik S. <po...@he...> - 2005-07-22 14:30:09
|
Am Freitag, 22. Juli 2005 15:07 schrieb Christian Zuckschwerdt: > ps. Is everyone on the list? I don't like recieving every mail twice, > perhaps we can keep this discussion just on the list. No, I am not subscribed, yet. Since I move next week and I am not sure abou= t=20 an internet connection after that, I'd rather do not subscribe. Hendrik =2D-=20 Mein GPG-Key ist auf meiner Homepage verf=C3=BCgbar: http://www.hendrik-sat= tler.de oder =C3=BCber pgp.net PingoS - Linux-User helfen Schulen: http://www.pingos.org |
From: Alex K. <ak...@se...> - 2005-07-22 13:17:56
|
On Fri, 22 Jul 2005, Hendrik Sattler wrote: > Can this list of possible OBEX usages be put into a obex_service enum or flags > that the application can reference? My problem is that the application has to > know too many OBEX internals. Maybe it only wants to know: I want to use the > push service to send the file to the phone, give me a list of devices that > support this. > Like > #define OBEX_SERVICE_PUSH 0x0001 > #define OBEX_SERVICE_FTP 0x0002 > #define OBEX_SERVICE_SYNCML 0x0004 > .... > Then let the functions accept an int (and let the list have the proper field > to compare). For IrDA, all those bits are set for ObEx capable device (we > don't know better). > And suddenly the lib knows what the application wants, easy, isn't is? This isn't as easy as it may seem. In theory, every standard-compliant obex interface must support object pushing and capability query ("GET x-object/capability" request) but in practice neither of these may work, so you'd have to resort to heuristics based on other information, such as a non-standardized interface/service name ("PC Suite Services"? huh?). Even then, capability query gives you a rather complex XML file which you need to parse. (real-life example from my Nokia 7610: http://www.sensi.org/~ak/openobex-usb/capability.txt ) >> You need to provide some information about the discovered interfaces, >> so that the applications can pick the one they want. For Bluetooth I >> think device, address, port, service class list, profile descriptor >> list and service name string are good enough. > See, the last three _may_ be interesting to the application but are > actually too much. An abreviated way like mentioned above may be easier > to handle. What if there are several services of same kind on one device? How do you distinguish between them? So I suggest that for now we should just provide applications with full information about all discovered obex interfaces, so the apps can pick what they want themselves, and add capability functionality later. > My main goal is to lower the necessary knowledge on the application author's > side. Not many develop OBEX applications (or run on top of current programs). > In short: I want to make the usage of libopenobex as easy as possible. > Reducing code duplication (e.g. device search) is one thing to achieve that > goal. Good - I want the same. Alexander Homepage: http://www.sensi.org/~ak/ |
From: Hendrik S. <po...@he...> - 2005-07-22 16:26:29
|
Am Freitag, 22. Juli 2005 15:17 schrieb Alex Kanavin: > On Fri, 22 Jul 2005, Hendrik Sattler wrote: > > Can this list of possible OBEX usages be put into a obex_service enum or > > flags that the application can reference? My problem is that the > > application has to know too many OBEX internals. Maybe it only wants to > > know: I want to use the push service to send the file to the phone, give > > me a list of devices that support this. > > Like > > #define OBEX_SERVICE_PUSH 0x0001 > > #define OBEX_SERVICE_FTP 0x0002 > > #define OBEX_SERVICE_SYNCML 0x0004 > > .... > > Then let the functions accept an int (and let the list have the proper > > field to compare). For IrDA, all those bits are set for ObEx capable > > device (we don't know better). > > And suddenly the lib knows what the application wants, easy, isn't is? > > This isn't as easy as it may seem. In theory, every standard-compliant > obex interface must support object pushing and capability query ("GET > x-object/capability" request) but in practice neither of these may work, > so you'd have to resort to heuristics based on other information, such as > a non-standardized interface/service name ("PC Suite Services"? huh?). > Even then, capability query gives you a rather complex XML file which you > need to parse. (real-life example from my Nokia 7610: > http://www.sensi.org/~ak/openobex-usb/capability.txt ) Hmm, parsing should be possible, I know at least two usable XML libs ;) Then maybe the Java way of "magic strings" is a better approach? However, I agree that this might be hard to put into a few parameters. Hendrik =2D-=20 Mein GPG-Key ist auf meiner Homepage verf=C3=BCgbar: http://www.hendrik-sat= tler.de oder =C3=BCber pgp.net PingoS - Linux-User helfen Schulen: http://www.pingos.org |
From: Hendrik S. <po...@he...> - 2005-07-22 14:38:37
|
Am Freitag, 22. Juli 2005 15:34 schrieben Sie: > struct obex_interface { > struct obex_interface *next; > struct obex_interface *prev; Do we really need a double-linked list? Since we do not add/(re)move someth= ing=20 in there often, I suggest a struct obex_interface** instead, last element=20 being NULL (so an array instead of a list). Just minor thing, this is. If you want a list, I suggest to copy list.h from the linux-2.4: very nice= =20 _generic_ double-linked list. > char* device_name; > char* interface_name; > int capabilities; > int transport > struct* usb_obex_interface usb_intf; > struct* bluetooth_interface bt_intf; put those two into a union like int transport; union { struct obex_bt_if* bt; struct obex_usb_if* usb; } interface;=20 So from transport you know if you have to select interface.bt or interface.= usb > ... > // pointers to detailed interface structures for all possible transports No, those should be in the union struct above, to have a stable interface: = the=20 pointer union stays the same size. Hendrik =2D-=20 Mein GPG-Key ist auf meiner Homepage verf=C3=BCgbar: http://www.hendrik-sat= tler.de oder =C3=BCber pgp.net PingoS - Linux-User helfen Schulen: http://www.pingos.org |
From: Alex K. <ak...@se...> - 2005-07-22 15:39:33
|
On Fri, 22 Jul 2005, Hendrik Sattler wrote: >> struct obex_interface { >> struct obex_interface *next; >> struct obex_interface *prev; > > Do we really need a double-linked list? Since we do not add/(re)move something > in there often, I suggest a struct obex_interface** instead, last element > being NULL (so an array instead of a list). Just minor thing, this is. > If you want a list, I suggest to copy list.h from the linux-2.4: very nice > _generic_ double-linked list. A double-linked list is easier to create if we don't know the number of entries in advance (and in our case, we don't). For an array, we'd have to go through the pains of memory (re)allocation. That's why I went with the linked list for USB interfaces. But an array is better, because you might want random access to entries in your application. >> // pointers to detailed interface structures for all possible transports > > No, those should be in the union struct above, to have a stable interface: the > pointer union stays the same size. Oh, certainly. So my plan is to rewrite UsbOBEX_GetInterfaces() into a generic OBEX_GetInterfaces(), and replace the nasty "struct usb_obex_interface" in obex_const.h with a more elegant "struct obex_interface", and also add OBEX_InterfaceConnect which takes that struct as a parameter. Marcel, is that ok? Alexander Homepage: http://www.sensi.org/~ak/ |
From: Alex K. <ak...@se...> - 2005-07-22 18:46:03
|
On Fri, 22 Jul 2005, Christian W. Zuckschwerdt wrote: >> interface_name is a user-readable interface name - both Bluetooth and USB >> provide those. Capabilities is a bit field with interface capabilities >> (file transfer, syncml and so on). > > So those are for informational purpose only? For choosing the interface to connect to, yep. The actual ids, addresses and numbers are hidden in intf_ pointers, which the application doesn't need to access. >> So in this case [Nokia] the serial is the same for any phone. Which means >> there is no way to identify a USB device in a unique way between replugs. > > Like I said above. The lib should take care of the icky bits especially if we > can't choose the right device. Just select them in turn and probe for the > IMEI or something. But we can :) Devices and interfaces have readable names (e.g. "Nokia 7610" and "OBEX Object Push") and there's also capability information, so you can either present a list of those triplets to the user, or have an application choose the one it wants automatically. Where's the icky bit here? On the other hand, probing for IMEI, which has nothing to do with OBEX and may or may not be present, definitely doesn't belong in a generic obex protocol library. You should do it on a higher level, if you want to be ultra-sure you're connecting to the right device, but in most cases that's overkill, I think. Alexander Homepage: http://www.sensi.org/~ak/ |
From: Christian W. Z. <Christian@Zuckschwerdt.org> - 2005-07-22 19:18:27
|
Hi, Alex Kanavin wrote: > The actual ids, addresses and numbers are hidden in intf_ pointers, > which the application doesn't need to access. > Devices and interfaces have readable names (e.g. "Nokia 7610" and > "OBEX Object Push") and there's also capability information, so you > can either present a list of those triplets to the user, or have an > application choose the one it wants automatically. Where's the icky > bit here? Seems we are talking the same language after all ;) So if a user requests connection to his 7610 or some Nokia and the application knows it wants Obex FT, all it has to do is get the array, look up the right pair (i.e. "*7610" or "Nokia*" with Obex FT) and voila. I can't think of any other way an application would choose the connection. So hide the _intf parts inside the lib. If the pair/triplet is ambiguous there is nothing the application could possibly do about it. That's my point here. The application won't choose a specific interface/configuration, bus or dev. If it can't identify the connection based on device name and service type it simply has to enumerate and probe all candidates. Now, is there a way to join the interface name and capabilities into a single field? If I take a look at the SDP fields (sorry I don't have a USB capable phone) it seems the interface name is descriptional only. We should stick to the capabilities (SDP has Service Class IDs and Profile Descriptors for this -- e.g. 0x1105 for "OBEX Object Push") The application would then filter the connection list by "Nokia 7610" and 0x1105 and use an opaque identifier (i.e. hidden _intf structure) to connect. > On the other hand, probing for IMEI, which has nothing to do with OBEX > and may or may not be present, definitely doesn't belong in a generic > obex protocol library. You are right. I didn't meant to imply that. Its mostly the scope of obexftp, e.g. cu, Christian |
From: Hendrik S. <po...@he...> - 2005-07-22 19:33:57
|
Am Freitag, 22. Juli 2005 21:18 schrieb Christian W. Zuckschwerdt: > I can't think of any other way an application would choose the > connection. But the obexftp already does. The user gives bluetooth address and optional= =20 channel. That's exactly what this interface pointer contains (for USB it's= =20 just a lot more parameters). An application that uses libopenobex might decide to do scanning on its own= =2E=20 This case should still be supported. HS =2D-=20 Mein GPG-Key ist auf meiner Homepage verf=C3=BCgbar: http://www.hendrik-sat= tler.de oder =C3=BCber pgp.net PingoS - Linux-User helfen Schulen: http://www.pingos.org |
From: Christian W. Z. <Christian@Zuckschwerdt.org> - 2005-07-22 19:54:14
|
Hi, Hendrik Sattler wrote: >Am Freitag, 22. Juli 2005 21:18 schrieb Christian W. Zuckschwerdt: > > >>I can't think of any other way an application would choose the >>connection. >> >> > >But the obexftp already does. The user gives bluetooth address and optional >channel. An application that uses libopenobex might decide to do scanning on its own. > > Thats just a work around until the channel can be autoselected thru the lib by the service type. I'd hoped USB could do the same here, enumerate all possible connections (maybe filtered by a given service type) and the just select one channel, port or interface/configuration. In the BT case the list always has some stable int (the channel) to select the connection by. It would be just to sweet if USB could do the same. Assuming the device is already choosen the questions remaining is: can we list the possible interface/configuration pairs in a canonical way? I know I'm wasting your time being to stubborn to see the difficulties here. Alex could you mail me (off the list) the "lsusb -v" of your Nokia? cu, Christian |
From: Alex K. <ak...@se...> - 2005-07-22 20:44:55
|
On Fri, 22 Jul 2005, Christian W. Zuckschwerdt wrote: > Seems we are talking the same language after all ;) So if a user requests > connection to his 7610 or some Nokia and the application knows it wants Obex > FT, all it has to do is get the array, look up the right pair (i.e. "*7610" > or "Nokia*" with Obex FT) and voila. Yes, exactly. > I can't think of any other way an application would choose the connection. So > hide the _intf parts inside the lib. If the pair/triplet is ambiguous there > is nothing the application could possibly do about it. That's my point here. > The application won't choose a specific interface/configuration, bus or dev. > If it can't identify the connection based on device name and service type it > simply has to enumerate and probe all candidates. Yep. > Now, is there a way to join the interface name and capabilities into a single > field? If I take a look at the SDP fields (sorry I don't have a USB capable > phone) it seems the interface name is descriptional only. > We should stick to the capabilities (SDP has Service Class IDs and Profile > Descriptors for this -- e.g. 0x1105 for "OBEX Object Push") Well, it would be helpful to have the interface names anyway, for three reasons: 0) Diagnostics. 1) On USB, there is no equivalent to Service Class IDs and Profile Descriptors - only the interface names. You can see that in lsusb output I've sent you off-list. We could perhaps map those interface names to some capability constants of our own, but that has to be done each time hardware vendors come up with some new name for an interface. 2) Not all Bluetooth OBEX services may have standardized Service Class IDs. For example Nokia 7610 has a vendor-specific Bluetooth OBEX service, which looks like this: Service Name: Nokia OBEX PC Suite Services Service RecHandle: 0x10007 Service Class ID List: "Error: This is UUID-128" (0x00005005-0000-1000-8000-0002ee000001) Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 12 "OBEX" (0x0008) Language Base Attr List: code_ISO639: 0x454e encoding: 0x6a base_offset: 0x100 Profile Descriptor List: "Error: This is UUID-128" (0x00005005-0000-1000-8000-0002ee000001) Version: 0x0100 I have no idea where that UUID128 is coming from. Probably made up by Nokia. Alexander Homepage: http://www.sensi.org/~ak/ |