From owner-freebsd-bluetooth@FreeBSD.ORG Sun Jun 11 11:32:53 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D7CC16A418 for ; Sun, 11 Jun 2006 11:32:53 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB3FB43D48 for ; Sun, 11 Jun 2006 11:32:51 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: from rya-online.net (du213-130-142-15.as15444.net [213.130.142.15]) by mail.ukfsn.org (Postfix) with SMTP id F2AA4E6FD8 for ; Sun, 11 Jun 2006 12:23:07 +0100 (BST) Received: (nullmailer pid 1648 invoked by uid 1000); Sun, 11 Jun 2006 10:52:13 -0000 Date: Sun, 11 Jun 2006 11:52:13 +0100 (BST) To: freebsd-bluetooth@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1150023133.421908.1633.nullmailer@galant.ukfsn.org> From: Iain Hibbert Subject: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 11:32:53 -0000 Hi, in part of my work in Bluetooth for NetBSD* I just took the SDP implementation from FreeBSD direct to get a leg up and didnt look at it very much at first though I did make some changes, which basically comprised: 1. whitespace space-tab, whitespace at EOL, and empty line at EOF 2. lint errors and compiler warnings mostly warnings about casting and const which may not be errors in reality. I managed to remove all these though and now compile at WARNS=4 (for GCC3) 3. NetBSD does not have LOCAL_PEERCRED socket options, so I converted sdpd to use LOCAL_CREDS 4. I added something for Headset/Headset Audio Gateway profile. so what I have is still compatible at source level with FreeBSD. However, in adding the headset support I took a better look and I'm not sure I like the API exactly. I havent especially looked at the competing implementations, took a glance at the BlueZ one but they dont seem strong on documentation (and I didnt see any) and I'm hesitant to change the API as what we really dont need is yet another incompatible implementation. Some things I am uneasy with then: 1. sdp_open[_local]() may return a handle even though there is an error. Really, this is terrible! If there is an error in open, it should just return NULL and set errno accordingly. sdp_error() should not be necessary.. 2. to register a profile with the sdp daemon, the daemon itself must already know about the profile, even though its just a string of binary. It would be nice if a client program could just prepare this array and send it. 3. parsing results of an sdp query is annoyingly ugly, it would be nice if there was some lib function that could be used to extract values from the result in a generic way. So well, I'm not so sure if anybody else besides Max has done any work in this arena, but any input is good.. iain *latest archive is http://homepages.rya-online.net/plunky/netbt.32.tar.gz From owner-freebsd-bluetooth@FreeBSD.ORG Mon Jun 12 18:19:15 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D832C16A473 for ; Mon, 12 Jun 2006 18:19:15 +0000 (UTC) (envelope-from maksim.yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B0C143D46 for ; Mon, 12 Jun 2006 18:19:15 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 41AAA3C149; Mon, 12 Jun 2006 13:19:14 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27065-01-11; Mon, 12 Jun 2006 13:19:14 -0500 (CDT) Received: from [10.254.186.111] (sntc04ep01.savvis.net [64.14.1.106]) by mailgate1b.savvis.net (Postfix) with ESMTP id C56C63BEE5; Mon, 12 Jun 2006 13:19:13 -0500 (CDT) Message-ID: <448DB020.2010409@savvis.net> Date: Mon, 12 Jun 2006 11:19:12 -0700 From: Maksim Yevmenkin User-Agent: Thunderbird 1.5.0.2 (X11/20060603) MIME-Version: 1.0 To: Iain Hibbert References: <1150023133.421908.1633.nullmailer@galant.ukfsn.org> In-Reply-To: <1150023133.421908.1633.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at savvis.net Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2006 18:19:16 -0000 Iain, > in part of my work in Bluetooth for NetBSD* I just took the SDP > implementation from FreeBSD direct to get a leg up and didnt look at it > very much at first though I did make some changes, which basically > comprised: [...] sounds good > so what I have is still compatible at source level with FreeBSD. However, > in adding the headset support I took a better look and I'm not sure I like > the API exactly. I havent especially looked at the competing > implementations, took a glance at the BlueZ one but they dont seem strong > on documentation (and I didnt see any) and I'm hesitant to change the API > as what we really dont need is yet another incompatible implementation. > > Some things I am uneasy with then: > > 1. sdp_open[_local]() may return a handle even though there is an error. > Really, this is terrible! If there is an error in open, it should just > return NULL and set errno accordingly. sdp_error() should not be > necessary.. well, its just the personal taste, imo :) personally, i do not like when libraries (ab)use errno. while "errno-style" seems to be de-facto standard in unix world, sometimes, there is a need to have more sophisticated error reporting. in my personal experience, sometimes, i cannot find an adequate "errno" error to describe the nature of error. the existing sdp(3), imo, is a middle ground. > 2. to register a profile with the sdp daemon, the daemon itself must > already know about the profile, even though its just a string of binary. > It would be nice if a client program could just prepare this array and > send it. correct. the idea was to make sure that advertised sdp records are somewhat consistent (and correct), and, to make life a little bit easier for clients. i guess, we could add sdp_register_raw() what would simply use the data from the client (after running some consistency checks). > 3. parsing results of an sdp query is annoyingly ugly, it would be nice if > there was some lib function that could be used to extract values from the > result in a generic way. ahem... there *were* supposed to be helper functions, a-la sdp_get_next_whatever() to simply advance pointers and copy data from them. i just never got around to write them :( > So well, I'm not so sure if anybody else besides Max has done any work in > this arena, but any input is good.. your comments are very good. thanks a lot. > *latest archive is http://homepages.rya-online.net/plunky/netbt.32.tar.gz i took a brief look at this. it looks really good. i think we should start and integrate our headers, i.e. make them the same and move them into some reasonable please, say, /usr/include/bluetooth it certainly would be possible to get rid of NG_ prefix in freebsd include files and do other tweaks as well. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Tue Jun 13 22:14:40 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C35316A47B for ; Tue, 13 Jun 2006 22:14:40 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8025243D45 for ; Tue, 13 Jun 2006 22:14:38 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: from rya-online.net (du213-130-141-11.as15444.net [213.130.141.11]) by mail.ukfsn.org (Postfix) with SMTP id C07CFE6F04; Tue, 13 Jun 2006 23:04:34 +0100 (BST) Received: (nullmailer pid 237 invoked by uid 1000); Tue, 13 Jun 2006 12:05:07 -0000 Date: Tue, 13 Jun 2006 13:05:07 +0100 (BST) To: Maksim Yevmenkin MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1150200307.649295.228.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2006 22:14:40 -0000 On Mon, 12 Jun 2006, Maksim Yevmenkin wrote: > > 1. sdp_open[_local]() may return a handle even though there is an error. > > well, its just the personal taste, imo :) personally, i do not like when > libraries (ab)use errno. while "errno-style" seems to be de-facto standard in > unix world, sometimes, (there is another world? :) > there is a need to have more sophisticated error > reporting. in my personal experience, sometimes, i cannot find an adequate > "errno" error to describe the nature of error. the existing sdp(3), imo, is a > middle ground. I thought there was some generic 'unknown error' errno but I dont see it now - I guess for something protocol specific then EPROTO could be used. Actually, I'm not so sure that is some kind of fixed standard, if an error exists that is not covered then there are still unallocated numbers.. I would say though, that setting errno is exactly what a library is supposed to do - it conveys extra information rather than 'failed' and its not really abusing it to set it when an operation fails.. so far as I can see, its not just for (eg) libc. > > 2. to register a profile with the sdp daemon, the daemon itself must > > already know about the profile, even though its just a string of binary. > > It would be nice if a client program could just prepare this array and > > send it. > > correct. the idea was to make sure that advertised sdp records are somewhat > consistent (and correct), and, to make life a little bit easier for clients. i > guess, we could add sdp_register_raw() what would simply use the data from the > client (after running some consistency checks). Yeah, I thought that was probably the case - my thought was that the daemon would at least validate the array before publishing it which at least covers 'consistent', and since registering a profile is privileged then the 'correct' is up to the sysadmin (or, whoever wrote the client) > > 3. parsing results of an sdp query is annoyingly ugly, it would be nice if > > there was some lib function that could be used to extract values from the > > result in a generic way. > > ahem... there *were* supposed to be helper functions, a-la > sdp_get_next_whatever() to simply advance pointers and copy data from them. i > just never got around to write them :( I might look at it again, just trying to finish something else now (and, my time has been limited for a few weeks) though I have to say, the SDP specification is not clear at all. I thought of some way, possibly extending the attrlist that you used for sdp_search() to specify values that could be automatically extracted and leaving all the parsing inside the library. > i took a brief look at this. it looks really good. i think we should start and > integrate our headers, i.e. make them the same and move them into some > reasonable please, say, /usr/include/bluetooth > > it certainly would be possible to get rid of NG_ prefix in freebsd include > files and do other tweaks as well. I chose /usr/include/netbt just to match with the other protocol family directories (and BTPROTO_ aswell) - not sure what FreeBSD does, I guess netgraph complicates things but actually, exact location is not so important because mostly I think should be enough. I did think to move all the kernel stuff into xxxvar.h so that the files hci.h, l2cap.h, rfcomm.h etc would only contain the 'bluetooth' spec stuff though interdependencies get a bit confusing when you split the files up. I think, that it might go in as-is for now, as they are close to branching for 4.0 and it would be nice to be in for that, even if that means the API will change slightly later. regards, iain From owner-freebsd-bluetooth@FreeBSD.ORG Wed Jun 14 17:41:54 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D12C16A41A for ; Wed, 14 Jun 2006 17:41:54 +0000 (UTC) (envelope-from maksim.yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE17743D45 for ; Wed, 14 Jun 2006 17:41:53 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 41EC53BE5A; Wed, 14 Jun 2006 12:41:53 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16830-02-30; Wed, 14 Jun 2006 12:41:53 -0500 (CDT) Received: from [10.254.186.111] (sntc04ep01.savvis.net [64.14.1.106]) by mailgate1b.savvis.net (Postfix) with ESMTP id A96C53BE58; Wed, 14 Jun 2006 12:41:52 -0500 (CDT) Message-ID: <44904A60.6080105@savvis.net> Date: Wed, 14 Jun 2006 10:41:52 -0700 From: Maksim Yevmenkin User-Agent: Thunderbird 1.5.0.2 (X11/20060603) MIME-Version: 1.0 To: Iain Hibbert References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> In-Reply-To: <1150200307.649295.228.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at savvis.net Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 17:41:54 -0000 Iain Hibbert wrote: > On Mon, 12 Jun 2006, Maksim Yevmenkin wrote: > >>> 1. sdp_open[_local]() may return a handle even though there is an error. >> well, its just the personal taste, imo :) personally, i do not like when >> libraries (ab)use errno. while "errno-style" seems to be de-facto standard in >> unix world, sometimes, > > (there is another world? :) ouch :) >> there is a need to have more sophisticated error >> reporting. in my personal experience, sometimes, i cannot find an adequate >> "errno" error to describe the nature of error. the existing sdp(3), imo, is a >> middle ground. > > I thought there was some generic 'unknown error' errno but I dont see it > now - I guess for something protocol specific then EPROTO could be used. > Actually, I'm not so sure that is some kind of fixed standard, > if an error exists that is not covered then there are still unallocated > numbers.. 'unknown error' is (imo) what modern strerror() implementations return on error code they do not understand, i.e. 0, -1 etc. it used to be that strerror() just crashed on such error codes. > I would say though, that setting errno is exactly what a library is > supposed to do - it conveys extra information rather than 'failed' and its > not really abusing it to set it when an operation fails.. so far as I can > see, its not just for (eg) libc. when this comes up, i always refer people for openssl's err(3) http://www.openssl.org/docs/crypto/err.html and specifically to http://www.openssl.org/docs/ssl/SSL_get_error.html# imo, this is both good and bad. good because one can know exactly what is going on, what failed and why. bad because api is not so easy do digest. first, one needs to look at openssl(3) error and then possibly at errno, etc. sdp(3), of course, is nowhere as complex as openssl(3). i tired to do a reasonable thing here. if syscall failed, sdp(3) will copy errno into session error. if something else went wrong, i.e. bad parameters, messages etc. sdp(3) tried to use appropriate errno value and put it into session error. there is, of course, little problem. because the errno values are reused, in some cases, it is not possible to say if syscall has failed or something inside library has failed. instead of implementing full scale error reporting, i simply left it as it is. should it be required to have more sophisticated error reporting in sdp(3) in would be easy to add it without breaking existing api (much). >>> 2. to register a profile with the sdp daemon, the daemon itself must >>> already know about the profile, even though its just a string of binary. >>> It would be nice if a client program could just prepare this array and >>> send it. >> correct. the idea was to make sure that advertised sdp records are somewhat >> consistent (and correct), and, to make life a little bit easier for clients. i >> guess, we could add sdp_register_raw() what would simply use the data from the >> client (after running some consistency checks). > > Yeah, I thought that was probably the case - my thought was that the > daemon would at least validate the array before publishing it which at > least covers 'consistent', and since registering a profile is privileged > then the 'correct' is up to the sysadmin (or, whoever wrote the client) like i said, i have nothing against sdp_register_raw() or something like that. we both agree that the only thing sdpd(8) can verify is "well-formed"ness of the data. sdpd(8) cannot do a full check on the data if it does not know about the profile. >>> 3. parsing results of an sdp query is annoyingly ugly, it would be nice if >>> there was some lib function that could be used to extract values from the >>> result in a generic way. >> ahem... there *were* supposed to be helper functions, a-la >> sdp_get_next_whatever() to simply advance pointers and copy data from them. i >> just never got around to write them :( > > I might look at it again, just trying to finish something else now (and, > my time has been limited for a few weeks) though I have to say, the SDP > specification is not clear at all. I thought of some way, possibly > extending the attrlist that you used for sdp_search() to specify values > that could be automatically extracted and leaving all the parsing inside > the library. well, here is what i think. sdp(3) client knows *exactly* what it is looking for. usually it is only required to get a few (less than 3) attributes to get all the information. sdp(3) client knows *exactly* what the format of the attributes should be. so, sdp(3) library should provide simple api to locate given element of given type in raw data and extract data from it. imo, more intelligent parsing could require sdp(3) to actually know about the profile client is trying use. i realize, that what i did/want for sdp(3) library is completely the opposite to what i did/want for sdpd(8) :) thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Wed Jun 14 21:53:46 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67E1B16A41A for ; Wed, 14 Jun 2006 21:53:46 +0000 (UTC) (envelope-from steven@403forbidden.net) Received: from mxsf03.cluster1.charter.net (mxsf03.cluster1.charter.net [209.225.28.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BFD543D45 for ; Wed, 14 Jun 2006 21:53:45 +0000 (GMT) (envelope-from steven@403forbidden.net) Received: from mxip30a.cluster1.charter.net (mxip30a.cluster1.charter.net [209.225.28.189]) by mxsf03.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id k5ELri0q009600 for ; Wed, 14 Jun 2006 17:53:44 -0400 Received: from 24-196-227-163.dhcp.gwnt.ga.charter.com (HELO services.403forbidden.net) ([24.196.227.163]) by mxip30a.cluster1.charter.net with ESMTP; 14 Jun 2006 17:53:44 -0400 X-IronPort-AV: i="4.06,133,1149480000"; d="scan'208"; a="1240279154:sNHT16724170" Received: from atlantis.403forbidden.net (atlantis.403forbidden.net [10.0.0.10]) by services.403forbidden.net (8.13.1/8.13.1) with ESMTP id k5ELrq1c001939 for ; Wed, 14 Jun 2006 17:53:52 -0400 (EDT) (envelope-from steven@403forbidden.net) Date: Wed, 14 Jun 2006 17:53:44 -0400 (EDT) From: "Steven S." To: freebsd-bluetooth@freebsd.org Message-ID: <20060614174828.G741@atlantis.403forbidden.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: logitech mx5000 + 5.5 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 21:53:46 -0000 First time caller, long time listener. I've got a bluetooth logitech mx5000 keyboard/mouse combo. Works fine in Windows 2k/XP, Xubuntu and FBSD 6.x but not 5.5-Stable. Seems to be something with netgraph. Plug in the dongle and it seems to get detected properly by usb uhub5: Logitech Logitech BT Mini-Receiver, class 9/0, rev 2.00/40.01, addr 3 uhub5: 3 ports with 1 removable, bus powered ukbd0: Logitech Logitech BT Mini-Receiver, rev 2.00/40.01, addr 4, iclass 3/1 kbd1 at ukbd0 ums0: Logitech Logitech BT Mini-Receiver, rev 2.00/40.01, addr 5, iclass 3/1 ums0: 7 buttons and Z dir. but i have no ubt0 device detected. all the kernel drivers are loaded 1 23 0xc0400000 3947a0 kernel 2 3 0xc0795000 1b36c linux.ko 3 2 0xc07b1000 1d4fc sound.ko 4 1 0xc07cf000 7494 snd_emu10k1.ko 5 1 0xc07d7000 4ada88 nvidia.ko 6 1 0xc0c85000 86c0 ng_ubt.ko 7 7 0xc0c8e000 dcac netgraph.ko 8 1 0xc0c9c000 58034 acpi.ko 9 1 0xc2a8f000 6000 linprocfs.ko 10 4 0xc32b4000 2000 ng_bluetooth.ko 11 1 0xc32b6000 d000 ng_hci.ko 12 1 0xc32cc000 f000 ng_l2cap.ko 13 1 0xc32db000 18000 ng_btsocket.ko 14 1 0xc32f3000 4000 ng_socket.ko 15 1 0xc3d06000 5000 ng_bt3c.ko various combo's of loading/unloading hasnt improved matters and ngctl li shows this There are 4 total nodes: Name: ngctl1450 Type: socket ID: 00000021 Num hooks: 0 Name: btsock_l2c Type: btsock_l2c ID: 00000003 Num hooks: 0 Name: btsock_l2c_raw Type: btsock_l2c_raw ID: 00000002 Num hooks: 0 Name: btsock_hci_raw Type: btsock_hci_raw ID: 00000001 Num hooks: 0 moused is running root 10133 0.0 0.1 1240 760 ?? Is 5:46PM 0:00.00 /usr/sbin/moused -p /dev/ums0 -I /var/run/moused.ums0.pid but moving mouse does nothing. I had a friend boot his 6.x laptop, we plugged the stuff in and it worked right off the bat with no fiddling. Known issues with 5.x? From owner-freebsd-bluetooth@FreeBSD.ORG Wed Jun 14 22:40:19 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 483F016A515 for ; Wed, 14 Jun 2006 22:40:19 +0000 (UTC) (envelope-from darren.pilgrim@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59E5F43D5A for ; Wed, 14 Jun 2006 22:40:12 +0000 (GMT) (envelope-from darren.pilgrim@bitfreak.org) Received: from [10.242.169.24] (c-67-171-135-169.hsd1.or.comcast.net [67.171.135.169]) by mail.bitfreak.org (Postfix) with ESMTP id 1CBAC17594; Wed, 14 Jun 2006 15:40:10 -0700 (PDT) Message-ID: <44909049.8030800@bitfreak.org> Date: Wed, 14 Jun 2006 15:40:09 -0700 From: Darren Pilgrim User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Steven S." References: <20060614174828.G741@atlantis.403forbidden.net> In-Reply-To: <20060614174828.G741@atlantis.403forbidden.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: logitech mx5000 + 5.5 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 22:40:19 -0000 Steven S. wrote: > I've got a bluetooth logitech mx5000 keyboard/mouse combo. > Works fine in Windows 2k/XP, Xubuntu and FBSD 6.x but not 5.5-Stable. > Seems to be something with netgraph. Plug in the dongle and it seems to > get detected properly by usb > > uhub5: Logitech Logitech BT Mini-Receiver, class 9/0, rev 2.00/40.01, > addr 3 > uhub5: 3 ports with 1 removable, bus powered > ukbd0: Logitech Logitech BT Mini-Receiver, rev 2.00/40.01, addr 4, > iclass 3/1 > kbd1 at ukbd0 > ums0: Logitech Logitech BT Mini-Receiver, rev 2.00/40.01, addr 5, iclass > 3/1 > ums0: 7 buttons and Z dir. > > but i have no ubt0 device detected. The Logitech receiver is a self-contained Bluetooth host. All the host computer ever sees is a USB hub, mouse and keyboard. -- Darren Pilgrim From owner-freebsd-bluetooth@FreeBSD.ORG Thu Jun 15 00:43:39 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BA8D16A41A for ; Thu, 15 Jun 2006 00:43:39 +0000 (UTC) (envelope-from steven@403forbidden.net) Received: from mxsf42.cluster1.charter.net (mxsf42.cluster1.charter.net [209.225.28.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB52543D48 for ; Thu, 15 Jun 2006 00:43:38 +0000 (GMT) (envelope-from steven@403forbidden.net) Received: from mxip17a.cluster1.charter.net (mxip17a.cluster1.charter.net [209.225.28.147]) by mxsf42.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id k5F0hb4G019283 for ; Wed, 14 Jun 2006 20:43:37 -0400 Received: from 24-196-227-163.dhcp.gwnt.ga.charter.com (HELO services.403forbidden.net) ([24.196.227.163]) by mxip17a.cluster1.charter.net with ESMTP; 14 Jun 2006 20:43:37 -0400 X-IronPort-AV: i="4.06,133,1149480000"; d="scan'208"; a="446977704:sNHT23927204" Received: from atlantis.403forbidden.net (atlantis.403forbidden.net [10.0.0.10]) by services.403forbidden.net (8.13.1/8.13.1) with ESMTP id k5F0hlTa002657 for ; Wed, 14 Jun 2006 20:43:47 -0400 (EDT) (envelope-from steven@403forbidden.net) Date: Wed, 14 Jun 2006 20:43:36 -0400 (EDT) From: "Steven S." To: freebsd-bluetooth@freebsd.org In-Reply-To: <44909049.8030800@bitfreak.org> Message-ID: <20060614203449.R773@atlantis.403forbidden.net> References: <20060614174828.G741@atlantis.403forbidden.net> <44909049.8030800@bitfreak.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: logitech mx5000 + 5.5 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 00:43:39 -0000 thats an logical answer yet. I take a usb mouse, a tiny portable unit from my laptop, plug it in and blammo it works. Try the dongle. nada. ums0: Logitech Logitech BT Mini-Receiver, rev 2.00/40.01, addr 4, iclass 3/1 ums0: 7 buttons and Z dir. ums1: KYE Genius USB Wheel Mouse, rev 1.00/0.00, addr 3, iclass 3/1 ums1: 3 buttons and Z dir. so is it the usb driver that does all the work from the dongle to moused? if i take moused and do not background it (-f) i get nada when I truss the moused process (with -f flag) kldnext(1) = 2 (0x2) sigprocmask(0x1,0x0,0x80508bc) = 0 (0x0) sigaction(SIGHUP,{ 0x804a7d4 0x0|ONSTACK|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t },{ SIG_DFL 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t }) = 0 (0x0) sigaction(SIGINT,{ 0x804a7e8 0x0|ONSTACK|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t },{ SIG_DFL 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t }) = 0 (0x0) sigaction(SIGQUIT,{ 0x804a7e8 0x0|ONSTACK|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t },{ SIG_DFL 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t }) = 0 (0x0) sigaction(SIGTERM,{ 0x804a7e8 0x0|ONSTACK|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t },{ SIG_DFL 0x0|ONSTACK|RESTART|RESETHAND|NOCLDSTOP|NODEFER|NOCLDWAIT|SIGINFO ss_t }) = 0 (0x0) open("/dev/ums0",0x6,027757765770) = 3 (0x3) ioctl(3,MOUSE_SETLEVEL,0x804f3ec) = 0 (0x0) ioctl(3,MOUSE_GETLEVEL,0xbfbfea8c) = 0 (0x0) ioctl(3,MOUSE_GETHWINFO,0x804f428) = 0 (0x0) ioctl(3,MOUSE_GETMODE,0x804f43c) = 0 (0x0) ioctl(3,MOUSE_SETMODE,0x804f43c) = 0 (0x0) open("/dev/consolectl",0x2,00) = 4 (0x4) gettimeofday({1150332081 352444},0x0) = 0 (0x0) ioctl(4,CONS_MOUSECTL,0xbfbfeb90) = 0 (0x0) and nothing ever again.. so I can only assume that there isnt any communication going on somewhere in the usb subsystem. or am I missing something simple here? On Wed, 14 Jun 2006, Darren Pilgrim wrote: > Steven S. wrote: >> I've got a bluetooth logitech mx5000 keyboard/mouse combo. >> Works fine in Windows 2k/XP, Xubuntu and FBSD 6.x but not 5.5-Stable. >> Seems to be something with netgraph. Plug in the dongle and it seems to >> get detected properly by usb >> >> uhub5: Logitech Logitech BT Mini-Receiver, class 9/0, rev 2.00/40.01, addr >> 3 >> uhub5: 3 ports with 1 removable, bus powered >> ukbd0: Logitech Logitech BT Mini-Receiver, rev 2.00/40.01, addr 4, iclass >> 3/1 >> kbd1 at ukbd0 >> ums0: Logitech Logitech BT Mini-Receiver, rev 2.00/40.01, addr 5, iclass >> 3/1 >> ums0: 7 buttons and Z dir. >> >> but i have no ubt0 device detected. > > The Logitech receiver is a self-contained Bluetooth host. All the host > computer ever sees is a USB hub, mouse and keyboard. > > -- > Darren Pilgrim > > From owner-freebsd-bluetooth@FreeBSD.ORG Thu Jun 15 18:03:22 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03CC716A41A for ; Thu, 15 Jun 2006 18:03:22 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68B8343D45 for ; Thu, 15 Jun 2006 18:03:20 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: from rya-online.net (du213-130-141-106.as15444.net [213.130.141.106]) by mail.ukfsn.org (Postfix) with SMTP id D1D6EE70A5; Thu, 15 Jun 2006 18:53:07 +0100 (BST) Received: (nullmailer pid 549 invoked by uid 1000); Wed, 14 Jun 2006 21:59:41 -0000 Date: Wed, 14 Jun 2006 22:59:41 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: <44904A60.6080105@savvis.net> References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> <44904A60.6080105@savvis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1150322381.757072.1713.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2006 18:03:22 -0000 On Wed, 14 Jun 2006, Maksim Yevmenkin wrote: > when this comes up, i always refer people for openssl's err(3) Well, I looked at that and I'm not sure what the point of all that is.. seems very complex for what it is, but maybe some complexity is warranted when you have a threaded application. When I write code, my ideal would preferably be 'simplicity and elegance' and I think in this case, you went too far and it just got complicated for no great reason.. > there is, of course, little problem. because the errno values are reused, in > some cases, it is not possible to say if syscall has failed or something > inside library has failed. there does not (imo) need to be any such distinction in reality - the application program gets a notice of failure on a specific function (by a bad return code), and what the failure is. It doesnt matter where the error was. eg if sdp_open() returns ENOMEM then you know there was some memory failure. It is not important if it was sdp_open() that failed to allocate the handle structure, or if it was the kernel that failed to allocate the PCB. Of course, you as the library author are responsible to make sure that you dont have bugs that cause error returns with valid application arguments. > > specification is not clear at all. I thought of some way, possibly > > extending the attrlist that you used for sdp_search() to specify values > > that could be automatically extracted and leaving all the parsing inside > > the library. > > well, here is what i think. sdp(3) client knows *exactly* what it is looking > for. usually it is only required to get a few (less than 3) attributes to get > all the information. btw, I wonder why you made the attrlist take a range instead of an attribute? It leaves us with this kind of thing.. /* List of the attributes we are looking for */ static uint32_t attrs[] = { SDP_ATTR_RANGE( SDP_ATTR_SERVICE_RECORD_HANDLE, SDP_ATTR_SERVICE_RECORD_HANDLE), SDP_ATTR_RANGE( SDP_ATTR_SERVICE_CLASS_ID_LIST, SDP_ATTR_SERVICE_CLASS_ID_LIST), SDP_ATTR_RANGE( SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST, SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST), SDP_ATTR_RANGE( SDP_ATTR_BLUETOOTH_PROFILE_DESCRIPTOR_LIST, SDP_ATTR_BLUETOOTH_PROFILE_DESCRIPTOR_LIST) }; .. though I'm not sure how often how often a range of attributes could be desireable .. in fact, this could be cleared with another macro like: #define SDP_ATTR(attr) SDP_ATTR_RANGE(attr, attr) [later] actually, I'm guessing this is related to the spec somehow - looking at the BlueZ sdp_lib.h include file which seems to be the documentation, they look to use the same concept. > sdp(3) client knows *exactly* what the format of the > attributes should be. so, sdp(3) library should provide simple api to locate > given element of given type in raw data and extract data from it. imo, more > intelligent parsing could require sdp(3) to actually know about the profile > client is trying use. Yes was thinking along those lines.. the client would provide a structure detailing how to parse the required attributes where to put the values. I'm looking at the BlueZ include file now, they have a lot of functions I'm not exactly clear as to the use of, will have to see if I can find some example code to see if it looks any simpler in use. iain From owner-freebsd-bluetooth@FreeBSD.ORG Fri Jun 16 17:27:25 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4253316A47D for ; Fri, 16 Jun 2006 17:27:25 +0000 (UTC) (envelope-from maksim.yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 639BF43D49 for ; Fri, 16 Jun 2006 17:27:24 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 4ECF43BEBF; Fri, 16 Jun 2006 12:27:23 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08261-02-17; Fri, 16 Jun 2006 12:27:23 -0500 (CDT) Received: from [10.254.186.111] (sntc04ep01.savvis.net [64.14.1.106]) by mailgate1b.savvis.net (Postfix) with ESMTP id B12483BEB1; Fri, 16 Jun 2006 12:27:22 -0500 (CDT) Message-ID: <4492E9FA.2030708@savvis.net> Date: Fri, 16 Jun 2006 10:27:22 -0700 From: Maksim Yevmenkin User-Agent: Thunderbird 1.5.0.2 (X11/20060603) MIME-Version: 1.0 To: Iain Hibbert References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> <44904A60.6080105@savvis.net> <1150322381.757072.1713.nullmailer@galant.ukfsn.org> In-Reply-To: <1150322381.757072.1713.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at savvis.net Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 17:27:25 -0000 Iain, >> when this comes up, i always refer people for openssl's err(3) > > Well, I looked at that and I'm not sure what the point of all that is.. > seems very complex for what it is, but maybe some complexity is warranted > when you have a threaded application. what i'm trying to say is 1) mixing errno-style and custom style error reporting is, imo, a bad idea. doing so usually result in complicated and confusing, imo, code. for this reason, i usually choose one style for a particular piece of code and stick with it. 2) given a choice between errno-style and custom style error reporting, i usually choose custom style *with* reusing errno values for error codes. this way custom error reporting is equivalent to "glorified errno", but in the same time i have the flexibility to completely replace errno values with something else if needed. this approach is something learned from personal experience and it worked for me many times. 3) i believe that data encapsulation and reentrant, thread-safe api design are good things. for this reason session-based api is used in libsdp(3). i choose to save error codes inside the session because it fits this model. i'm not saying that is the only right way to do things. i'm just trying to explain how i came to write this code. > When I write code, my ideal would preferably be 'simplicity and elegance' > and I think in this case, you went too far and it just got complicated for > no great reason.. perhaps. sdp protocol and data structures are flexible. it is possible to slice and dice the data any way one wants. since bluetooth specification is a living thing and keeps changing, i opt out for more complicated design. >> there is, of course, little problem. because the errno values are reused, in >> some cases, it is not possible to say if syscall has failed or something >> inside library has failed. > > there does not (imo) need to be any such distinction in reality - the > application program gets a notice of failure on a specific function (by a > bad return code), and what the failure is. It doesnt matter where the > error was. eg if sdp_open() returns ENOMEM then you know there was some > memory failure. It is not important if it was sdp_open() that failed to > allocate the handle structure, or if it was the kernel that failed to > allocate the PCB. Of course, you as the library author are responsible to > make sure that you dont have bugs that cause error returns with valid > application arguments. i disagree with you here. in order to troubleshoot any problem one needs to know what went wrong and why. it just saves lots of time down the road (imo). i appreciate your comments and respect your position. so, lets just agree to disagree here :) whether you choose to use libsdp(3) or not, i personally will respect and support your choice. i'm sure others will do the same. both implementations already have quite a few differences, so adding one more should not be a big issue :) i think, you do have a point about sdpd(8) profile registration and libsdp(3) attribute parsing. i will try to address these (and if anyone wants to help please feel free to jump in). and, of course, please feel free to continue to ask questions, submit patches etc. its all good stuff :) >>> specification is not clear at all. I thought of some way, possibly >>> extending the attrlist that you used for sdp_search() to specify values >>> that could be automatically extracted and leaving all the parsing inside >>> the library. >> well, here is what i think. sdp(3) client knows *exactly* what it is looking >> for. usually it is only required to get a few (less than 3) attributes to get >> all the information. > > btw, I wonder why you made the attrlist take a range instead of an > attribute? It leaves us with this kind of thing.. > > /* List of the attributes we are looking for */ > static uint32_t attrs[] = > { > SDP_ATTR_RANGE( SDP_ATTR_SERVICE_RECORD_HANDLE, > SDP_ATTR_SERVICE_RECORD_HANDLE), > SDP_ATTR_RANGE( SDP_ATTR_SERVICE_CLASS_ID_LIST, > SDP_ATTR_SERVICE_CLASS_ID_LIST), > SDP_ATTR_RANGE( SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST, > SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST), > SDP_ATTR_RANGE( SDP_ATTR_BLUETOOTH_PROFILE_DESCRIPTOR_LIST, > SDP_ATTR_BLUETOOTH_PROFILE_DESCRIPTOR_LIST) > }; > > .. though I'm not sure how often how often a range of attributes could be > desireable .. in fact, this could be cleared with another macro like: > > #define SDP_ATTR(attr) SDP_ATTR_RANGE(attr, attr) > > [later] actually, I'm guessing this is related to the spec somehow - > looking at the BlueZ sdp_lib.h include file which seems to be the > documentation, they look to use the same concept. yes. attributes can be request in two ways 1) as individual uint16_t attribute id 2) as uint32_t attribute range (lo, hi) in order to simplify the code i decided to always use ranges even if one attribute is requested. this creates slightly bigger sdp pdu's but (imo) makes api simpler. the SDP_ATTR(attr) you suggesting is fine with me. >> sdp(3) client knows *exactly* what the format of the >> attributes should be. so, sdp(3) library should provide simple api to locate >> given element of given type in raw data and extract data from it. imo, more >> intelligent parsing could require sdp(3) to actually know about the profile >> client is trying use. > > Yes was thinking along those lines.. the client would provide a structure > detailing how to parse the required attributes where to put the values. may be. so far i have not seen a need for that. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Fri Jun 16 20:15:06 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C34A16A47A for ; Fri, 16 Jun 2006 20:15:06 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC7C543D49 for ; Fri, 16 Jun 2006 20:15:05 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: from rya-online.net (du213-130-141-8.as15444.net [213.130.141.8]) by mail.ukfsn.org (Postfix) with SMTP id CEB92E6AA7; Fri, 16 Jun 2006 21:04:40 +0100 (BST) Received: (nullmailer pid 22778 invoked by uid 1000); Fri, 16 Jun 2006 19:43:10 -0000 Date: Fri, 16 Jun 2006 20:43:10 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: <4492E9FA.2030708@savvis.net> References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> <44904A60.6080105@savvis.net> <1150322381.757072.1713.nullmailer@galant.ukfsn.org> <4492E9FA.2030708@savvis.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1397750121-1150486990=:22008" Message-Id: <1150486990.380039.25644.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 20:15:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1397750121-1150486990=:22008 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 16 Jun 2006, Maksim Yevmenkin wrote: > > > sdp(3) client knows *exactly* what the format of the > > > attributes should be. so, sdp(3) library should provide simple api to > > > locate > > > given element of given type in raw data and extract data from it. imo, > > > more > > > intelligent parsing could require sdp(3) to actually know about the > > > profile > > > client is trying use. > > > > Yes was thinking along those lines.. the client would provide a structure > > detailing how to parse the required attributes where to put the values. > > may be. so far i have not seen a need for that. I looked at the BlueZ implementation and for the sdp query function, they parse the flat results and return a linked list then have a bunch of extra functions that extract specific values. See attached file for example in use to find SPP (ie RFCOMM channel) It does look neater, but I'm not sure I like the exact concept. iain --0-1397750121-1150486990=:22008 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=sdp.c Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: cups/sdp.c Content-Disposition: attachment; filename=sdp.c LyoNCiAqDQogKiAgQmx1ZVogLSBCbHVldG9vdGggcHJvdG9jb2wgc3RhY2sg Zm9yIExpbnV4DQogKg0KICogIENvcHlyaWdodCAoQykgMjAwMy0yMDA0ICBN YXJjZWwgSG9sdG1hbm4gPG1hcmNlbEBob2x0bWFubi5vcmc+DQogKg0KICoN CiAqICBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiBy ZWRpc3RyaWJ1dGUgaXQgYW5kL29yIG1vZGlmeQ0KICogIGl0IHVuZGVyIHRo ZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgdmVy c2lvbiAyIGFzDQogKiAgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJl IEZvdW5kYXRpb247DQogKg0KICogIFRIRSBTT0ZUV0FSRSBJUyBQUk9WSURF RCAiQVMgSVMiLCBXSVRIT1VUIFdBUlJBTlRZIE9GIEFOWSBLSU5ELCBFWFBS RVNTDQogKiAgT1IgSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRF RCBUTyBUSEUgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFksDQogKiAg RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UgQU5EIE5PTklORlJJ TkdFTUVOVCBPRiBUSElSRCBQQVJUWSBSSUdIVFMuDQogKiAgSU4gTk8gRVZF TlQgU0hBTEwgVEhFIENPUFlSSUdIVCBIT0xERVIoUykgQU5EIEFVVEhPUihT KSBCRSBMSUFCTEUgRk9SIEFOWQ0KICogIENMQUlNLCBPUiBBTlkgU1BFQ0lB TCBJTkRJUkVDVCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMsIE9SIEFOWSBE QU1BR0VTIA0KICogIFdIQVRTT0VWRVIgUkVTVUxUSU5HIEZST00gTE9TUyBP RiBVU0UsIERBVEEgT1IgUFJPRklUUywgV0hFVEhFUiBJTiBBTiANCiAqICBB Q1RJT04gT0YgQ09OVFJBQ1QsIE5FR0xJR0VOQ0UgT1IgT1RIRVIgVE9SVElP VVMgQUNUSU9OLCBBUklTSU5HIE9VVCBPRiANCiAqICBPUiBJTiBDT05ORUNU SU9OIFdJVEggVEhFIFVTRSBPUiBQRVJGT1JNQU5DRSBPRiBUSElTIFNPRlRX QVJFLg0KICoNCiAqICBBTEwgTElBQklMSVRZLCBJTkNMVURJTkcgTElBQklM SVRZIEZPUiBJTkZSSU5HRU1FTlQgT0YgQU5ZIFBBVEVOVFMsIA0KICogIENP UFlSSUdIVFMsIFRSQURFTUFSS1MgT1IgT1RIRVIgUklHSFRTLCBSRUxBVElO RyBUTyBVU0UgT0YgVEhJUyANCiAqICBTT0ZUV0FSRSBJUyBESVNDTEFJTUVE Lg0KICoNCiAqDQogKiAgJElkOiBzZHAuYyx2IDEuMyAyMDA0LzA1LzAyIDIx OjU1OjM2IGhvbHRtYW5uIEV4cCAkDQogKi8NCg0KI2lmZGVmIEhBVkVfQ09O RklHX0gNCiNpbmNsdWRlIDxjb25maWcuaD4NCiNlbmRpZg0KDQojaW5jbHVk ZSA8c3RkaW8uaD4NCiNpbmNsdWRlIDxlcnJuby5oPg0KI2luY2x1ZGUgPHVu aXN0ZC5oPg0KI2luY2x1ZGUgPHNpZ25hbC5oPg0KI2luY2x1ZGUgPHN5cy9z b2NrZXQuaD4NCg0KI2luY2x1ZGUgPGJsdWV0b290aC9ibHVldG9vdGguaD4N CiNpbmNsdWRlIDxibHVldG9vdGgvc2RwLmg+DQojaW5jbHVkZSA8Ymx1ZXRv b3RoL3NkcF9saWIuaD4NCg0KaW50IHNkcF9zZWFyY2hfaGNycChzZHBfc2Vz c2lvbl90ICpzZHAsIHVuc2lnbmVkIHNob3J0ICpjdHJsX3BzbSwgdW5zaWdu ZWQgc2hvcnQgKmRhdGFfcHNtKQ0Kew0KCXNkcF9saXN0X3QgKnNyY2gsICph dHRycywgKnJzcDsNCgl1dWlkX3Qgc3ZjbGFzczsNCgl1aW50MTZfdCBhdHRy MSwgYXR0cjI7DQoJaW50IGVycjsNCg0KCWlmICghc2RwKQ0KCQlyZXR1cm4g LTE7DQoNCglzZHBfdXVpZDE2X2NyZWF0ZSgmc3ZjbGFzcywgSENSX1BSSU5U X1NWQ0xBU1NfSUQpOw0KCXNyY2ggPSBzZHBfbGlzdF9hcHBlbmQoTlVMTCwg JnN2Y2xhc3MpOw0KDQoJYXR0cjEgPSBTRFBfQVRUUl9QUk9UT19ERVNDX0xJ U1Q7DQoJYXR0cnMgPSBzZHBfbGlzdF9hcHBlbmQoTlVMTCwgJmF0dHIxKTsN CglhdHRyMiA9IFNEUF9BVFRSX0FERF9QUk9UT19ERVNDX0xJU1Q7DQoJYXR0 cnMgPSBzZHBfbGlzdF9hcHBlbmQoYXR0cnMsICZhdHRyMik7DQoNCgllcnIg PSBzZHBfc2VydmljZV9zZWFyY2hfYXR0cl9yZXEoc2RwLCBzcmNoLCBTRFBf QVRUUl9SRVFfSU5ESVZJRFVBTCwgYXR0cnMsICZyc3ApOw0KCWlmIChlcnIp DQoJCXJldHVybiAtMTsNCg0KCWZvciAoOyByc3A7IHJzcCA9IHJzcC0+bmV4 dCkgew0KCQlzZHBfcmVjb3JkX3QgKnJlYyA9IChzZHBfcmVjb3JkX3QgKikg cnNwLT5kYXRhOw0KCQlzZHBfbGlzdF90ICpwcm90b3M7DQoNCgkJaWYgKCFz ZHBfZ2V0X2FjY2Vzc19wcm90b3MocmVjLCAmcHJvdG9zKSkgew0KCQkJdW5z aWduZWQgc2hvcnQgcHNtID0gc2RwX2dldF9wcm90b19wb3J0KHByb3Rvcywg TDJDQVBfVVVJRCk7DQoJCQlpZiAocHNtID4gMCkgew0KCQkJCSpjdHJsX3Bz bSA9IHBzbTsNCgkJCX0NCgkJfQ0KDQoJCWlmICghc2RwX2dldF9hZGRfYWNj ZXNzX3Byb3RvcyhyZWMsICZwcm90b3MpKSB7DQoJCQl1bnNpZ25lZCBzaG9y dCBwc20gPSBzZHBfZ2V0X3Byb3RvX3BvcnQocHJvdG9zLCBMMkNBUF9VVUlE KTsNCgkJCWlmIChwc20gPiAwICYmICpjdHJsX3BzbSA+IDApIHsNCgkJCQkq ZGF0YV9wc20gPSBwc207DQoJCQkJcmV0dXJuIDA7DQoJCQl9DQoJCX0NCgl9 DQoNCglyZXR1cm4gLTE7DQp9DQoNCmludCBzZHBfc2VhcmNoX3NwcChzZHBf c2Vzc2lvbl90ICpzZHAsIHVpbnQ4X3QgKmNoYW5uZWwpDQp7DQoJc2RwX2xp c3RfdCAqc3JjaCwgKmF0dHJzLCAqcnNwOw0KCXV1aWRfdCBzdmNsYXNzOw0K CXVpbnQxNl90IGF0dHI7DQoJaW50IGVycjsNCg0KCWlmICghc2RwKQ0KCQly ZXR1cm4gLTE7DQoNCglzZHBfdXVpZDE2X2NyZWF0ZSgmc3ZjbGFzcywgU0VS SUFMX1BPUlRfU1ZDTEFTU19JRCk7DQoJc3JjaCA9IHNkcF9saXN0X2FwcGVu ZChOVUxMLCAmc3ZjbGFzcyk7DQoNCglhdHRyID0gU0RQX0FUVFJfUFJPVE9f REVTQ19MSVNUOw0KCWF0dHJzID0gc2RwX2xpc3RfYXBwZW5kKE5VTEwsICZh dHRyKTsNCg0KCWVyciA9IHNkcF9zZXJ2aWNlX3NlYXJjaF9hdHRyX3JlcShz ZHAsIHNyY2gsIFNEUF9BVFRSX1JFUV9JTkRJVklEVUFMLCBhdHRycywgJnJz cCk7DQoJaWYgKGVycikNCgkJcmV0dXJuIC0xOw0KDQoJZm9yICg7IHJzcDsg cnNwID0gcnNwLT5uZXh0KSB7DQoJCXNkcF9yZWNvcmRfdCAqcmVjID0gKHNk cF9yZWNvcmRfdCAqKSByc3AtPmRhdGE7DQoJCXNkcF9saXN0X3QgKnByb3Rv czsNCg0KCQlpZiAoIXNkcF9nZXRfYWNjZXNzX3Byb3RvcyhyZWMsICZwcm90 b3MpKSB7DQoJCQl1aW50OF90IGNoID0gc2RwX2dldF9wcm90b19wb3J0KHBy b3RvcywgUkZDT01NX1VVSUQpOw0KCQkJaWYgKGNoID4gMCkgew0KCQkJCSpj aGFubmVsID0gY2g7DQoJCQkJcmV0dXJuIDA7DQoJCQl9DQoJCX0NCgl9DQoN CglyZXR1cm4gLTE7DQp9DQo= --0-1397750121-1150486990=:22008-- From owner-freebsd-bluetooth@FreeBSD.ORG Fri Jun 16 21:01:08 2006 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B817E16A479 for ; Fri, 16 Jun 2006 21:01:08 +0000 (UTC) (envelope-from maksim.yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F3D643D45 for ; Fri, 16 Jun 2006 21:01:08 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 67B1C3BEB4; Fri, 16 Jun 2006 16:01:07 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12990-02-11; Fri, 16 Jun 2006 16:01:07 -0500 (CDT) Received: from [10.254.186.111] (sntc04ep01.savvis.net [64.14.1.106]) by mailgate1b.savvis.net (Postfix) with ESMTP id E51813BE9A; Fri, 16 Jun 2006 16:01:06 -0500 (CDT) Message-ID: <44931C12.7020805@savvis.net> Date: Fri, 16 Jun 2006 14:01:06 -0700 From: Maksim Yevmenkin User-Agent: Thunderbird 1.5.0.2 (X11/20060603) MIME-Version: 1.0 To: Iain Hibbert References: <1150200307.649295.228.nullmailer@galant.ukfsn.org> <44904A60.6080105@savvis.net> <1150322381.757072.1713.nullmailer@galant.ukfsn.org> <4492E9FA.2030708@savvis.net> <1150486990.380039.25644.nullmailer@galant.ukfsn.org> In-Reply-To: <1150486990.380039.25644.nullmailer@galant.ukfsn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at savvis.net Cc: freebsd-bluetooth@freebsd.org Subject: Re: SDP X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2006 21:01:08 -0000 Iain, >>>> sdp(3) client knows *exactly* what the format of the >>>> attributes should be. so, sdp(3) library should provide simple api to >>>> locate >>>> given element of given type in raw data and extract data from it. imo, >>>> more >>>> intelligent parsing could require sdp(3) to actually know about the >>>> profile >>>> client is trying use. >>> Yes was thinking along those lines.. the client would provide a structure >>> detailing how to parse the required attributes where to put the values. >> may be. so far i have not seen a need for that. > > I looked at the BlueZ implementation and for the sdp query function, they > parse the flat results and return a linked list then have a bunch of extra > functions that extract specific values. See attached file for example in > use to find SPP (ie RFCOMM channel) > > It does look neater, but I'm not sure I like the exact concept. sigh... i've seen the bluez sdp code. in fact, i try to keep track of what bluez folks do. it seems like (to me) that current bluez sdp api is, in some form, re-incarnation of the very first original sdpd and sdptool code. i'm not sure why bluez folks so keen on linked list concept for sdp data. here is what i mean: when sdp transaction is complete the client has all the attributes and all attribute values packed into the pdu in "sdp wire" format. it is a perfectly acceptable format to parse. in fact, it is a great format, because it is possible to parse it (and extract the values) in-place without allocating any memory or modifying original data. i'm not sure why is it required to parse all the data and re-pack it into the linked list, just to have another api that would search and extract data from the linked list. i admit that linked list is an easy to understand concept for a human, but for a machine it does not make any difference at all. i had a chance to work with csr bluelab sdk recently and develop the application that actually runs on the csr chip inside the virtual machine and does not require any host stack. this is very resource limited environment. when i looked at what csr sdk api is for sdp, i realized that is somewhat similar to what i've suggested/done in libsdp(3). the idea is the same, get the raw bytes from the remote device and use simple functions that parse it in-place and locate elements of given type to extract their values. in fact, splitting attributes and putting them into separate buffers was probably a bad idea in libsdp(3). i should have just return the whole pdu (minus header) to the client and have it deal with it. like i said, libsdp(3) misses utility functions to parse/extract values, but they are easy to write. by simply passing/using pointers within original buffer one can make these utility functions thread-safe, reentrant and recurse-friendly without any trouble at all. in fact, those functions do not even need a sdp_session object, just a buffer and few pointers. thanks, max