From owner-freebsd-bluetooth@FreeBSD.ORG Mon Apr 24 08:06:48 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 5460816A406 for ; Mon, 24 Apr 2006 08:06:48 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by mx1.FreeBSD.org (Postfix) with SMTP id AD17243D4C for ; Mon, 24 Apr 2006 08:06:45 +0000 (GMT) (envelope-from plunky@rya-online.net) Received: (qmail 81436 messnum 6395197 invoked from network[83.70.176.191/unknown]); 24 Apr 2006 08:06:44 -0000 Received: from unknown (HELO rya-online.net) (83.70.176.191) by mail00.svc.cra.dublin.eircom.net (qp 81436) with SMTP; 24 Apr 2006 08:06:44 -0000 Received: (nullmailer pid 1000 invoked by uid 1000); Sun, 23 Apr 2006 21:28:55 -0000 Date: Sun, 23 Apr 2006 22:28:55 +0100 (BST) To: Maksim Yevmenkin In-Reply-To: <4445206D.4030109@savvis.net> References: <4423D096.2010205@udc.es> <44248823.3040907@savvis.net> <1145275616.851775.858.nullmailer@galant.ukfsn.org> <4445206D.4030109@savvis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1145827735.746600.1441.nullmailer@galant.ukfsn.org> From: Iain Hibbert Cc: freebsd-bluetooth@freebsd.org Subject: Re: USB isoc xfers 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, 24 Apr 2006 08:06:48 -0000 On Tue, 18 Apr 2006, Maksim Yevmenkin wrote: > i have not tried to send sco data. I am trying this now and got more trouble :) I can't get the devices I have here (a csr v2.0 and a belkin v1.2) to send NUM_COMPLETE_PACKETS for SCO handles.. the csr returns 0x11 "unsupported feature" for WRITE_SCO_FLOW_CONTROL even though the READ_LOCAL_COMMANDS says it can do that command (well, turning it off seems to work :), and the belkin says ok but READ_BUFFER_SIZE always returns 0 for num_sco_packets. Did you find any of this yet? I think it will have to be done differently.. I looked at Affix and from what I can understand they seem to have a timer that keeps the queue topped up. I couldnt work out what BlueZ does exactly, and I'm trying to think if there is a better way.. seems that the device could send some notification when it took packets off the outputq which would trigger more to be queued, or even just send the packets back via a different method (so empty packet is message), hm.. regards, iain