From: Lars Grunewaldt <lgw@dark-reality.de>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] BlueZ and the ALSA support
Date: Sun, 21 Nov 2004 21:13:40 +0100 [thread overview]
Message-ID: <41A0F6F4.6070707@dark-reality.de> (raw)
In-Reply-To: <1101061573.7250.68.camel@pegasus>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marcel Holtmann wrote:
| Hi Lars,
|
|
|>| Do anyone mind if we start using the kernel coding style? It will make
|>| later integration into the kernel or BlueZ so much easier.
|>
|>I definitly won't mind, we'll have to migrate anyway, and sooner is
|>better than later.
|
|
| this is correct, but I won't integrate the current idea of the btsco
| kernel module. In the end it must work without the SCO socket in between
| for sending and receiving the SCO data packets from the HCI. And I like
| to have the eSCO support also. However even I don't have the right test
| hardware for that.
Yes, you already mentioned that before. Depending on the time I'll have
to implement it, it won't be much of a problem to do a complete redesign
of the stuff. As soon as I understand what we'll need... ;)
|>My problem how to change the usb_hci endpoint without killing the n.y.t.
|>urbs is still pending, did you have any new ideas on this?
|
|
| My problem is that I haven't written all of the hci_usb driver code and
| some parts are still so messy that I think a complete rewrite is the
| best that we can do.
I see, did not know that.
| But what I will do is to add a module parameter for
| choosing the alternate setting that can be changed at runtime. To bring
| up a device with a new alternate setting you only have to unplug and
| then plug it in again. This is not the solution we should have, but it
| will help us with testing the SCO stuff without recompiling the kernel
| every time.
Yes, that would be a first step.
I hope I can have a look at the way how usb_hci works, so that I can
understand when an asynchronus/delayed change of the endpoint selection
could happen - or how we could get rid of not-send urbs. *sigh* just
need more time...
don't you think it should be possible to
a) block the submit of new urbs when a change notify has arrived
b) queue until the queue is empty
c) change the endpoint setting and release the block
I don't know to which bad runs or locks this could lead...
cu,
~ Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBoPbzQWC6DTWkDAoRAhDvAJ9OiAlvi1fjivMFchnmb4ehBe53hwCfey+1
UEARQw9ddXYRhewZvKFf014=
=kTD6
-----END PGP SIGNATURE-----
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2004-11-21 20:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-21 0:01 [Bluez-devel] BlueZ and the ALSA support Marcel Holtmann
2004-11-21 2:10 ` Lars Grunewaldt
2004-11-21 5:29 ` Brad Midgley
2004-11-21 17:14 ` Marcel Holtmann
2004-11-21 17:41 ` Lars Grunewaldt
2004-11-21 18:26 ` Marcel Holtmann
2004-11-21 20:13 ` Lars Grunewaldt [this message]
2004-11-21 20:39 ` Marcel Holtmann
2004-11-21 22:11 ` Lars Grunewaldt
2004-11-21 22:45 ` Marcel Holtmann
2004-11-21 22:59 ` Lars Grunewaldt
2004-11-21 20:12 ` Brad Midgley
2004-11-21 20:25 ` Marcel Holtmann
2004-11-22 4:09 ` Brad Midgley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41A0F6F4.6070707@dark-reality.de \
--to=lgw@dark-reality.de \
--cc=bluez-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.