_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Jose,
Ok, i see this time. I'm gonna see what i can do.
I just don't like the way you trunkated the sockaddr_un and
would be very surprised if it was the 'official' way to solve this issue.
Does anyone here know how 'the others' do ?
Cheers,
Fabien
> Hi Fabien,
>
> Please take a look at file /proc/net/unix.
> It lists all opened sockets. If headsetd is running,
> it's easy to tell because that is the only one that
> has a string of nul characters following the name.
> My patch fixes that.
>
> Jose
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fabien,
Please take a look at file /proc/net/unix.
It lists all opened sockets. If headsetd is running,
it's easy to tell because that is the only one that
has a string of nul characters following the name.
My patch fixes that.
Jose
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Jose,
It took me a while to figure out what was wrong...
Having a look to man 7 unix you will see that :
sun_family always contains AF_UNIX. sun_path contains the
zero-terminated pathname of the socket in the file system.
So no, thank you, i think my code is fine ;-)
If there are displays issues and something needs fixing i think you
should fix your monitoring application instead.
Cheers,
Fabien
> Hi Fabien,
>
> I have a minor suggestion regarding the binding of the unix
> socket in daemon.c. Currently, the socket name registered
> contains nul characters. It would be better to register the
> name without the extra fill for monitoring applications.
>
> Jose
>
> --- daemon.c 2006-05-18 10:30:06.000000000 -0400
> +++ ../../cvs/alsa-plugin-sco/headsetd/new/daemon.c 2006-09-01
> 19:18:04.000000000 -0400
> @@ -73,7 +73,7 @@
> struct sockaddr_un pcm_srv_sock = {
> AF_UNIX, PCM_SERVER_SOCKET
> };
> - if(bind(_appl_srv_sockfd, (struct sockaddr *)&pcm_srv_sock,
> sizeof(pcm_srv_sock)) != 0) {
> + if(bind(_appl_srv_sockfd, (struct sockaddr *)&pcm_srv_sock,
> __SOCKADDR_COMMON_SIZE+sizeof(PCM_SERVER_SOCKET)-1) != 0) {
> syslog(LOG_ERR, "bind(_appl_srv_sockfd): %s", strerror(errno));
> goto error;
> }
> @@ -96,7 +96,7 @@
> struct sockaddr_un ctl_srv_sock = {
> AF_UNIX, CTL_SERVER_SOCKET
> };
> - if(bind(_appl_ctlsrv_sockfd, (struct sockaddr *)&ctl_srv_sock,
> sizeof(ctl_srv_sock)) != 0) {
> + if(bind(_appl_ctlsrv_sockfd, (struct sockaddr *)&ctl_srv_sock,
> __SOCKADDR_COMMON_SIZE+sizeof(CTL_SERVER_SOCKET)-1) != 0) {
> syslog(LOG_ERR, "bind(_appl_ctlsrv_sockfd): %s",
> strerror(errno));
> goto error2;
> }
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fabien,
I have a minor suggestion regarding the binding of the unix
socket in daemon.c. Currently, the socket name registered
contains nul characters. It would be better to register the
name without the extra fill for monitoring applications.
Jose
--- daemon.c 2006-05-18 10:30:06.000000000 -0400
+++ ../../cvs/alsa-plugin-sco/headsetd/new/daemon.c 2006-09-01
19:18:04.000000000 -0400
@@ -73,7 +73,7 @@
struct sockaddr_un pcm_srv_sock = {
AF_UNIX, PCM_SERVER_SOCKET
};
- if(bind(_appl_srv_sockfd, (struct sockaddr *)&pcm_srv_sock,
sizeof(pcm_srv_sock)) != 0) {
+ if(bind(_appl_srv_sockfd, (struct sockaddr *)&pcm_srv_sock,
__SOCKADDR_COMMON_SIZE+sizeof(PCM_SERVER_SOCKET)-1) != 0) {
syslog(LOG_ERR, "bind(_appl_srv_sockfd): %s", strerror(errno));
goto error;
}
@@ -96,7 +96,7 @@
struct sockaddr_un ctl_srv_sock = {
AF_UNIX, CTL_SERVER_SOCKET
};
- if(bind(_appl_ctlsrv_sockfd, (struct sockaddr *)&ctl_srv_sock,
sizeof(ctl_srv_sock)) != 0) {
+ if(bind(_appl_ctlsrv_sockfd, (struct sockaddr *)&ctl_srv_sock,
__SOCKADDR_COMMON_SIZE+sizeof(CTL_SERVER_SOCKET)-1) != 0) {
syslog(LOG_ERR, "bind(_appl_ctlsrv_sockfd): %s",
strerror(errno));
goto error2;
}
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Jose,
> >>> I am not against using flow control, but we must be really careful if it
> >>> supported or not. While for ACL it is mandatory, the SCO channel can be
> >>> used without it. However even the use of flow control on SCO is a job
> >>> for the Bluetooth core and no driver specific one. All Bluetooth drivers
> >>> are transport drivers. They have no intelligence whatsoever and they are
> >>> not interfering the HCI data. If they need to know some specific details
> >>> about changes in the core then the notify() callback is the right place
> >>> and if they need a special setup, then a quirk should be used. Other
> >>> than that, they are plain stupid and only moving HCI packets to the
> >>> hardware and back.
> >>>
> >>> So from my understanding the high resolution timer are a good choice to
> >>> submit SCO packets to the hardware. In addition we can enable the flow
> >>> control for SCO to have more control over the hardware. However please
> >>> keep in mind that the enabling flow control means for traffic on the ACL
> >>> links and so you might see a downgrade in bandwidth. So from my current
> >>> point of view, the flow control stuff must be optional.
> >>>
> >> The problem with using timers is that they are not synchronized
> >> with the bluetooth controller (dongle). This can cause drift after
> >> a while leading to underrun condition on the controller. This will
> >> cause pops or other audio artifacts. So this solution will always
> >> have a design flaw. I don't find this acceptable.
> >>
> >
> > I don't see the synchronization as a problem, because once SCO traffic
> > is on, we get a PCM stream back from the chip we can use this one as a
> > synchronization source.
> >
> >
> I don't see this as an acceptable solution. First, the current
> code makes it very easy for a trivial program to cause Linux
> to panic. Second, using received data to synchronize puts
> the burden at the application layer when this should be a
> driver issue. Third, this will never scale to asymmetric eSCO
> connections.
the Bluetooth HCI core inside the kernel should synchronize. We are not
talking about applications. And actually I meant that it should use the
incoming SCO stream as a hint to re-synchronize its timers. Not as the
only source of synchronization. This is not a one way or the other
thing.
> >> Let me address some of your objections to using the flow control:
> >>
> >> 1. extra bandwith - this is the price to pay for synchronization.
> >> In the case of USB no additional messages are sent and overhead
> >> is part of the USB isosynchronous transport.
> >>
> >
> > Wrong. We always have additional HCI commands and events if SCO flow
> > control has been enabled. This is no difference from the actual
> > transport you use. The only difference for USB is that they are on a
> > different interface of the USB device.
> >
> >
> In the case of USB, the flow control messages are sent to
> the bluetooth hci core by hci_usb; this is done when the
> USB layer has acknowledged the transferred. No additional
> messages are sent by the controller. Whether you take
> advantage of the USB layer or not, the USB overhead is
> always there.
We are now talking about two different flow controls. And this is
exactly what I mean. You are mixing transport specific things with HCI
stuff. The HCI is an abstraction and once you enable SCO flow control,
you have additional HCI traffic on the control and event channel. The
ISOC transfers from USB are transport specific.
> >> 2. some dongles may not support flow control - it's true that flow
> >> control can be turned off for synchronous traffic but it' s not clear
> >> to me that this is optional for controllers that support SCOs.
> >> We're really talking about UART or other interfaces. Can anyone
> >> provide an example where it's NOT supported?
> >>
> >
> > It is optional no matter if it is UART, USB or any other transport. This
> > is has nothing to do with the actual hardware interface.
> >
> It's optional in the sense that an application may not need it.
> A custom profile may be sending non-PCM data and deal with it.
> That's not to say that it's optional for a controller if it supports
> SCO. For USB there's flow control at that layer.
Again. We are talking about SCO flow control from the HCI viewpoint and
not the USB ISOC transfers. You must see the difference here.
> >> 3. Transport drivers are dumb - this is a problem with the existing
> >> drivers that should be addressed. They need to differentiate
> >> between different types of traffic otherwise it's quite easy to
> >> starve the synchronous channel with ACL data. In fact, the
> >> current architecture can't support multiple SCOs reliably because
> >> of this. At the very least, separate queues must be used for
> >> synchronous and other traffic.
> >>
> >
> > I don't see what you are actually talking about. We have separate queues
> > for ACL and SCO data, because the queues are connection specific. What
> > the actual driver is doing is up to the driver. However the Bluetooth
> > hardware drivers are transport drivers and the core has to be fully
> > agnostic from any hardware specific implementation of the transports.
> >
> >
> The scheduling in hci_core.c will send all acl data before
> sco. This prevents the driver from having access to the SCO
> data in a timely manner. Then the hci_usb driver puts the
> packets in one transmit queue.
That needs fixing. I never argued against it. However we have different
queues and the only issue is to get the transmission right.
> Before going too far with technical details, I think it's worth
> understanding what level of Bluetooth compatibility is desired.
> The current state is adequate but not robust (easy to panic).
> Perhaps my expectations are higher that what the community
> wants. Of course, you could argue that other environments or
> solutions aren't much better, and this maybe true. I don't mean
> to cause problems; I just want a better support for SCO/eSCO.
The easy to panic thing is a simple bug that needs fixing. No argument
about that, but for the rest. The Bluetooth core layer must be totally
generic and doesn't need to know about the actual hardware it runs on.
The driver takes care of any hardware specific issues. This separations
is needed and also wanted.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
> Hi Jose,
>
>
>>> I am not against using flow control, but we must be really careful if it
>>> supported or not. While for ACL it is mandatory, the SCO channel can be
>>> used without it. However even the use of flow control on SCO is a job
>>> for the Bluetooth core and no driver specific one. All Bluetooth drivers
>>> are transport drivers. They have no intelligence whatsoever and they are
>>> not interfering the HCI data. If they need to know some specific details
>>> about changes in the core then the notify() callback is the right place
>>> and if they need a special setup, then a quirk should be used. Other
>>> than that, they are plain stupid and only moving HCI packets to the
>>> hardware and back.
>>>
>>> So from my understanding the high resolution timer are a good choice to
>>> submit SCO packets to the hardware. In addition we can enable the flow
>>> control for SCO to have more control over the hardware. However please
>>> keep in mind that the enabling flow control means for traffic on the ACL
>>> links and so you might see a downgrade in bandwidth. So from my current
>>> point of view, the flow control stuff must be optional.
>>>
>> The problem with using timers is that they are not synchronized
>> with the bluetooth controller (dongle). This can cause drift after
>> a while leading to underrun condition on the controller. This will
>> cause pops or other audio artifacts. So this solution will always
>> have a design flaw. I don't find this acceptable.
>>
>
> I don't see the synchronization as a problem, because once SCO traffic
> is on, we get a PCM stream back from the chip we can use this one as a
> synchronization source.
>
>
I don't see this as an acceptable solution. First, the current
code makes it very easy for a trivial program to cause Linux
to panic. Second, using received data to synchronize puts
the burden at the application layer when this should be a
driver issue. Third, this will never scale to asymmetric eSCO
connections.
>> Let me address some of your objections to using the flow control:
>>
>> 1. extra bandwith - this is the price to pay for synchronization.
>> In the case of USB no additional messages are sent and overhead
>> is part of the USB isosynchronous transport.
>>
>
> Wrong. We always have additional HCI commands and events if SCO flow
> control has been enabled. This is no difference from the actual
> transport you use. The only difference for USB is that they are on a
> different interface of the USB device.
>
>
In the case of USB, the flow control messages are sent to
the bluetooth hci core by hci_usb; this is done when the
USB layer has acknowledged the transferred. No additional
messages are sent by the controller. Whether you take
advantage of the USB layer or not, the USB overhead is
always there.
>> 2. some dongles may not support flow control - it's true that flow
>> control can be turned off for synchronous traffic but it' s not clear
>> to me that this is optional for controllers that support SCOs.
>> We're really talking about UART or other interfaces. Can anyone
>> provide an example where it's NOT supported?
>>
>
> It is optional no matter if it is UART, USB or any other transport. This
> is has nothing to do with the actual hardware interface.
>
It's optional in the sense that an application may not need it.
A custom profile may be sending non-PCM data and deal with it.
That's not to say that it's optional for a controller if it supports
SCO. For USB there's flow control at that layer.
>> 3. Transport drivers are dumb - this is a problem with the existing
>> drivers that should be addressed. They need to differentiate
>> between different types of traffic otherwise it's quite easy to
>> starve the synchronous channel with ACL data. In fact, the
>> current architecture can't support multiple SCOs reliably because
>> of this. At the very least, separate queues must be used for
>> synchronous and other traffic.
>>
>
> I don't see what you are actually talking about. We have separate queues
> for ACL and SCO data, because the queues are connection specific. What
> the actual driver is doing is up to the driver. However the Bluetooth
> hardware drivers are transport drivers and the core has to be fully
> agnostic from any hardware specific implementation of the transports.
>
>
The scheduling in hci_core.c will send all acl data before
sco. This prevents the driver from having access to the SCO
data in a timely manner. Then the hci_usb driver puts the
packets in one transmit queue.
Before going too far with technical details, I think it's worth
understanding what level of Bluetooth compatibility is desired.
The current state is adequate but not robust (easy to panic).
Perhaps my expectations are higher that what the community
wants. Of course, you could argue that other environments or
solutions aren't much better, and this maybe true. I don't mean
to cause problems; I just want a better support for SCO/eSCO.
Regards,
Jose
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Jose,
> > I am not against using flow control, but we must be really careful if it
> > supported or not. While for ACL it is mandatory, the SCO channel can be
> > used without it. However even the use of flow control on SCO is a job
> > for the Bluetooth core and no driver specific one. All Bluetooth drivers
> > are transport drivers. They have no intelligence whatsoever and they are
> > not interfering the HCI data. If they need to know some specific details
> > about changes in the core then the notify() callback is the right place
> > and if they need a special setup, then a quirk should be used. Other
> > than that, they are plain stupid and only moving HCI packets to the
> > hardware and back.
> >
> > So from my understanding the high resolution timer are a good choice to
> > submit SCO packets to the hardware. In addition we can enable the flow
> > control for SCO to have more control over the hardware. However please
> > keep in mind that the enabling flow control means for traffic on the ACL
> > links and so you might see a downgrade in bandwidth. So from my current
> > point of view, the flow control stuff must be optional.
>
> The problem with using timers is that they are not synchronized
> with the bluetooth controller (dongle). This can cause drift after
> a while leading to underrun condition on the controller. This will
> cause pops or other audio artifacts. So this solution will always
> have a design flaw. I don't find this acceptable.
I don't see the synchronization as a problem, because once SCO traffic
is on, we get a PCM stream back from the chip we can use this one as a
synchronization source.
> Let me address some of your objections to using the flow control:
>
> 1. extra bandwith - this is the price to pay for synchronization.
> In the case of USB no additional messages are sent and overhead
> is part of the USB isosynchronous transport.
Wrong. We always have additional HCI commands and events if SCO flow
control has been enabled. This is no difference from the actual
transport you use. The only difference for USB is that they are on a
different interface of the USB device.
> 2. some dongles may not support flow control - it's true that flow
> control can be turned off for synchronous traffic but it' s not clear
> to me that this is optional for controllers that support SCOs.
> We're really talking about UART or other interfaces. Can anyone
> provide an example where it's NOT supported?
It is optional no matter if it is UART, USB or any other transport. This
is has nothing to do with the actual hardware interface.
> 3. Transport drivers are dumb - this is a problem with the existing
> drivers that should be addressed. They need to differentiate
> between different types of traffic otherwise it's quite easy to
> starve the synchronous channel with ACL data. In fact, the
> current architecture can't support multiple SCOs reliably because
> of this. At the very least, separate queues must be used for
> synchronous and other traffic.
I don't see what you are actually talking about. We have separate queues
for ACL and SCO data, because the queues are connection specific. What
the actual driver is doing is up to the driver. However the Bluetooth
hardware drivers are transport drivers and the core has to be fully
agnostic from any hardware specific implementation of the transports.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
> Hi Brad,
>
>
>>> Regarding the kernel patches, you know I've taken a different
>>> approach. I believe that what I posted is simpler and more reliable
>>> as it doesn't depend timers. The flow control approach avoids the
>>> possibility of getting out of sync with the dongle.
>>>
>> fyi, I talked to Marcel about this and he likes solving it at a higher
>> level so the transports (usb/uart/sdio) don't have to each have their
>> own solution. Maybe he could articulate it better...
>>
>
> I am not against using flow control, but we must be really careful if it
> supported or not. While for ACL it is mandatory, the SCO channel can be
> used without it. However even the use of flow control on SCO is a job
> for the Bluetooth core and no driver specific one. All Bluetooth drivers
> are transport drivers. They have no intelligence whatsoever and they are
> not interfering the HCI data. If they need to know some specific details
> about changes in the core then the notify() callback is the right place
> and if they need a special setup, then a quirk should be used. Other
> than that, they are plain stupid and only moving HCI packets to the
> hardware and back.
>
> So from my understanding the high resolution timer are a good choice to
> submit SCO packets to the hardware. In addition we can enable the flow
> control for SCO to have more control over the hardware. However please
> keep in mind that the enabling flow control means for traffic on the ACL
> links and so you might see a downgrade in bandwidth. So from my current
> point of view, the flow control stuff must be optional.
>
> Regards
>
> Marcel
>
>
i Marcel,
The problem with using timers is that they are not synchronized
with the bluetooth controller (dongle). This can cause drift after
a while leading to underrun condition on the controller. This will
cause pops or other audio artifacts. So this solution will always
have a design flaw. I don't find this acceptable.
Let me address some of your objections to using the flow control:
1. extra bandwith - this is the price to pay for synchronization.
In the case of USB no additional messages are sent and overhead
is part of the USB isosynchronous transport.
2. some dongles may not support flow control - it's true that flow
control can be turned off for synchronous traffic but it' s not clear
to me that this is optional for controllers that support SCOs.
We're really talking about UART or other interfaces. Can anyone
provide an example where it's NOT supported?
3. Transport drivers are dumb - this is a problem with the existing
drivers that should be addressed. They need to differentiate
between different types of traffic otherwise it's quite easy to
starve the synchronous channel with ACL data. In fact, the
current architecture can't support multiple SCOs reliably because
of this. At the very least, separate queues must be used for
synchronous and other traffic.
Regards,
Jose
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> > Regarding the kernel patches, you know I've taken a different
> > approach. I believe that what I posted is simpler and more reliable
> > as it doesn't depend timers. The flow control approach avoids the
> > possibility of getting out of sync with the dongle.
>
> fyi, I talked to Marcel about this and he likes solving it at a higher
> level so the transports (usb/uart/sdio) don't have to each have their
> own solution. Maybe he could articulate it better...
I am not against using flow control, but we must be really careful if it
supported or not. While for ACL it is mandatory, the SCO channel can be
used without it. However even the use of flow control on SCO is a job
for the Bluetooth core and no driver specific one. All Bluetooth drivers
are transport drivers. They have no intelligence whatsoever and they are
not interfering the HCI data. If they need to know some specific details
about changes in the core then the notify() callback is the right place
and if they need a special setup, then a quirk should be used. Other
than that, they are plain stupid and only moving HCI packets to the
hardware and back.
So from my understanding the high resolution timer are a good choice to
submit SCO packets to the hardware. In addition we can enable the flow
control for SCO to have more control over the hardware. However please
keep in mind that the enabling flow control means for traffic on the ACL
links and so you might see a downgrade in bandwidth. So from my current
point of view, the flow control stuff must be optional.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Jose
> Regarding the kernel patches, you know I've taken a different
> approach. I believe that what I posted is simpler and more reliable
> as it doesn't depend timers. The flow control approach avoids the
> possibility of getting out of sync with the dongle.
fyi, I talked to Marcel about this and he likes solving it at a higher
level so the transports (usb/uart/sdio) don't have to each have their
own solution. Maybe he could articulate it better...
Brad
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fabien,
Looks like things are taking shape. Thank you for the contribution.
Regarding the kernel patches, you know I've taken a different
approach. I believe that what I posted is simpler and more reliable
as it doesn't depend timers. The flow control approach avoids the
possibility of getting out of sync with the dongle.
Jose
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel