On Tue, Dec 8, 2009 at 9:06 PM, Marcel Holtmann <span dir="ltr">&lt;<a href="mailto:marcel@holtmann.org" target="_blank">marcel@holtmann.org</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Hi Nick,<br>
<div><br>
&gt; Right now Bluez always requests flushable ACL packets (but does not<br>
&gt; set a flush timeout, so effectively they are non-flushable):<br>
&gt;<br>
&gt; However it is desirable to use an ACL flush timeout on A2DP packets so<br>
&gt; that if the ACL packets block for some reason then the LM can flush<br>
&gt; them to make room for newer packets.<br>
&gt;<br>
&gt; Is it reasonable for Bluez to use the 0x00 ACL packet boundary flag by<br>
&gt; default (non-flushable packet), and let userspace request flushable<br>
&gt; packets on A2DP L2CAP sockets with the socket option<br>
&gt; L2CAP_LM_RELIABLE.<br>
<br>
</div>the reliable option has a different meaning. It comes back from the old<br>
Bluetooth 1.1 qualification days where we had to tests on L2CAP that had<br>
to confirm that we can detect malformed packets and report them. These<br>
days it is just fine to drop them.<br></blockquote><div><br></div><div>Ok, how about introducing</div><div><br></div><div>#define L2CAP_LM_FLUSHABLE 0x0040</div><div><br></div><div>struct l2cap_pinfo {</div><div>   ...</div>


<div>   __u8 flushable;</div><div>}</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
You can not just blindly use ACL_START_FLUSHABLE without proper version<br>
checking. This feature has been introduced later and will not work with<br>
all stacks out there. Please go through the different spec. versions to<br>
see the difference.<br></blockquote><div><br></div><div>Will do.</div><div> </div><div>Nick</div></div><br>