On Sat, 2005-03-12 at 21:49 -0700, Brad Midgley wrote:
> Fredrik,
>
> These are all great ideas and I am hoping to make good use of what
> you've done. I'd rather merge it and fix up coding style etc later.
>
> Are you subscribed to bluez-devel? I'd like to have you join in to
> discuss the patch.
I am now. ;-)
I didn't think that btsco would be discussed on the bluez-devel list, so
I had no idea where to subscribe. Had I known, I would have posted the
patch there in the first place.
I CCed the list now, and I would attach the patch again for the benefit
to anyone on the list that it may benefit, but I don't want to post a 20
kB message to a ML. Instead, I'm putting it on the web at
<http://www.dolda2000.com/~fredrik/patches/btsco.diff>. I hope that is
satisfactory.
Fredrik Tolf
> Thanks for trying to keep the upstream package relevant :)
>
> Brad
>
> Fredrik Tolf wrote:
> > Hi!
> >
> > I've made some modifications to the btsco project that you're involved
> > in. I'm not sure if you're the one I should send patches to, but then
> > again, the project pages didn't really have much info on where to send
> > patches.
> >
> > There are a couple of things I've done:
> > * Instead of (dis)connecting with the headset button, the driver
> > notifies userspace when it is in use, and the userspace program connects
> > accordingly.
> > * I added a getopt parsing to the userspace program and a "verbose
> > flag" for controlling whether the normal operational messages should be
> > printed.
> > * Send SIGUSR1 to the userspace program to make the headset ring.
> > * The userspace program now reads a config file, ~/.btscorc, which
> > contains alternating lines of regexes and shell commands. Everything
> > that the headset sends is matched against these regexes, and if a match
> > if found, the shell command is run (with any back references replaced).
> > This, of course, is primarily intended to "do stuff" with the headset
> > button(s). Send SIGHUP to re-read the config file.
> > * Start the userspace program with -f to make it daemonize after
> > connecting to the headset.
> > * I changed the userspace program main loop to only block on polls,
> > rather than sleeping for 1 second all the time. This makes for snappier
> > performance when, for example, a program opens the DSP so that the SCO
> > channel is connected.
> >
> > I'm also working on a patch for GnomeMeeting to support ringing the
> > headset and getting answered by a headset keypress.
> >
> > On the bad side, the coding is pretty unelegant in its places, and I've
> > completely violated your coding style. Also, backward compatibility for
> > userspace communication is broken since I had to extend the structure
> > for incorporating usage status. I haven't updated the btsco2 program
> > either.
> >
> > So, use the patch if you want to, or just steal ideas, or just discard
> > it if you don't like it for any reason. I'll go on using it either
> > way. ;-)
> >
> > Fredrik Tolf
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fredrik Tolf wrote:
| On Wed, 2005-03-16 at 13:30 +0100, Lars Grunewaldt wrote:
|
|>-----BEGIN PGP SIGNED MESSAGE-----
|>Hash: SHA1
|>
|>Fredrik Tolf wrote:
|>| On Tue, 2005-03-15 at 17:17 -0700, Brad Midgley wrote:
|>| In a perfect world, yes. But the question is: Does the kernel actually
|>| detect wandering out of range, and if so, after how long? If the kernel
|>| can't detect it, is there a way of periodically pinging the headset to
|>| detect it manually?
|>
|>Of course the kernel detects it when a device get's out of range. Not
|>immediatly, but as soon as the lower level BT links break down. Pretty
|>much a protocol feature...
|
|
| Well, I have to admit that I don't really know much about how BT works.
| I just got into the btsco project because I wanted to integrate it
| closer with Gnomemeeting and other VoIP programs, as can be seen from
| the fact that the features I've contributed are pretty
| non-bluetooth-related.
|
| Thanks for enlightening me, though. I would have thought that when the
| device got out of range, the kernel just wouldn't know the status of it
| since it couldn't reach it (and maybe time out after a longer period of
| time). Does anyone have any pointers to good documentation that I can
| use to read up on BT?
As Brad already wrote, dig bluetooth.org. The whole BT thing is set up
as a standard (sort of), from hardware up to the software/driver level.
You can find everything (i.e. AT commands) in the core docs. Maybe you
have to check the older BT specs (1.1) for the headset profile and
especially the sco stuff. And make sure to understand what the different
transport layers do, it helps a lot.
good luck :)
- - Lars
- --
Lars Grunewaldt
* software development
* multimedia design
skills: C/C++/Java/PHP/(X)HTML/Flash/audio/video
web: http://www.dark-reality.de
mail: [email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCOIpRQWC6DTWkDAoRAjOFAJ9I3dRVDKIq2ueykN9KG7t59+H8dQCgti/I
YW48SkCAWRHezHM4rMGmQeg=
=SilZ
-----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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fredrik
> (among which are to advertise the computer as an audio gateway).
Interesting timing. I'm watching Marcel's ongoing discussion with a Hong
Kong user about adding an advertised service.
The standards documents are available at http://www.bluetooth.org but you have
to hunt around a bit. When I was working on a2dp, I used the AVDTP spec
and A2DP spec documents from them but curiously, the latter I found in a
zipfile with a bunch of reference audio files. The other documents I got
from there for bluetooth-alsa work are 6_headset and "HFP spec" but I
don't remember how I found them.
Brad
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Wed, 2005-03-16 at 13:30 +0100, Lars Grunewaldt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Fredrik Tolf wrote:
> | On Tue, 2005-03-15 at 17:17 -0700, Brad Midgley wrote:
> | In a perfect world, yes. But the question is: Does the kernel actually
> | detect wandering out of range, and if so, after how long? If the kernel
> | can't detect it, is there a way of periodically pinging the headset to
> | detect it manually?
>
> Of course the kernel detects it when a device get's out of range. Not
> immediatly, but as soon as the lower level BT links break down. Pretty
> much a protocol feature...
Well, I have to admit that I don't really know much about how BT works.
I just got into the btsco project because I wanted to integrate it
closer with Gnomemeeting and other VoIP programs, as can be seen from
the fact that the features I've contributed are pretty
non-bluetooth-related.
Thanks for enlightening me, though. I would have thought that when the
device got out of range, the kernel just wouldn't know the status of it
since it couldn't reach it (and maybe time out after a longer period of
time). Does anyone have any pointers to good documentation that I can
use to read up on BT? There are a few bluetooth-related features that I
want to add as well, but that I really can't without deeper knowledge
(among which are to advertise the computer as an audio gateway).
Fredrik Tolf
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fredrik Tolf wrote:
| On Tue, 2005-03-15 at 17:17 -0700, Brad Midgley wrote:
| In a perfect world, yes. But the question is: Does the kernel actually
| detect wandering out of range, and if so, after how long? If the kernel
| can't detect it, is there a way of periodically pinging the headset to
| detect it manually?
Of course the kernel detects it when a device get's out of range. Not
immediatly, but as soon as the lower level BT links break down. Pretty
much a protocol feature...
best regards,
~ Lars
- --
Lars Grunewaldt
* software development
* multimedia design
skills: C/C++/Java/PHP/(X)HTML/Flash/audio/video
web: http://www.dark-reality.de
mail: [email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCOCbUQWC6DTWkDAoRAj1VAJ4mDAuD1WmiOul6VsHLCFlPV9RITACgng/1
B89iFNfImuOVEJCUOpZm56Q=
=7kyh
-----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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 2005-03-15 at 17:17 -0700, Brad Midgley wrote:
> Fredrik
>
> > I just saw that sometimes the kernel apparently notices a broken RFCOMM
> > channel and closes the socket. I don't know yet what might trigger it
> > apart from an explicit disconnect.
>
> wandering out of range, powering off the headset, suspending the laptop
> are the ones I would run into.
In a perfect world, yes. But the question is: Does the kernel actually
detect wandering out of range, and if so, after how long? If the kernel
can't detect it, is there a way of periodically pinging the headset to
detect it manually?
Fredrik Tolf
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fredrik
> I just saw that sometimes the kernel apparently notices a broken RFCOMM
> channel and closes the socket. I don't know yet what might trigger it
> apart from an explicit disconnect.
wandering out of range, powering off the headset, suspending the laptop
are the ones I would run into.
> Either way, it made the btsco daemon chew up 100% CPU, so I added a case
> to detect it and exit for now. If it should be handled otherwise, that
> can be fixed when it is figured out what it should do instead.
ok
brad
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, 2005-03-15 at 00:22 -0700, Brad Midgley wrote:
> Fredrik
>
> > Another thing, that I'm not sure is a good idea, is to implement a
> > "fail-safe" mode in the daemon. Running the daemon in fail-safe mode
> > would mean that it doesn't die from not being able to connect to the
> > headset. Instead, it would try to reconnect periodically. Same thing if
> > the connection is lost at some point. The reason I'm not sure if this is
> > a good idea is that one would have to wait for the reconnection attempt
> > to get the headset working after making it accessible. Therefore, it may
> > well be a good idea to just have to run the daemon manually when one
> > knows that the headset is accessible. However, in this case, the daemon
> > should at least terminate if it looses the RFCOMM connection to the
> > headset. I don't know if it's possible to detect if the RFCOMM
> > connection is lost, though. Comments are appreciated.
>
> I don't know about detecting broken rfcomm. I haven't experimented with it.
I just saw that sometimes the kernel apparently notices a broken RFCOMM
channel and closes the socket. I don't know yet what might trigger it
apart from an explicit disconnect.
Either way, it made the btsco daemon chew up 100% CPU, so I added a case
to detect it and exit for now. If it should be handled otherwise, that
can be fixed when it is figured out what it should do instead.
Fredrik Tolf
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fredrik
> Another thing, that I'm not sure is a good idea, is to implement a
> "fail-safe" mode in the daemon. Running the daemon in fail-safe mode
> would mean that it doesn't die from not being able to connect to the
> headset. Instead, it would try to reconnect periodically. Same thing if
> the connection is lost at some point. The reason I'm not sure if this is
> a good idea is that one would have to wait for the reconnection attempt
> to get the headset working after making it accessible. Therefore, it may
> well be a good idea to just have to run the daemon manually when one
> knows that the headset is accessible. However, in this case, the daemon
> should at least terminate if it looses the RFCOMM connection to the
> headset. I don't know if it's possible to detect if the RFCOMM
> connection is lost, though. Comments are appreciated.
I don't know about detecting broken rfcomm. I haven't experimented with it.
The way my cell phone works is the headset "connection" is dropped if
the rfcomm connection is broken. The next call will ring only in the
handset, not the headset.
We *could* have the daemon attempt to reestablish the rfcomm connection
when an audio client tries to send/receive audio on a stale link. That
seems more reasonable than retrying periodically and we might get the
daemon to the point that it can be left running regardless of the
transient availability of the target headset.
Next to consider is the convenience of establishing a connection again
from the headset by advertising audio gateway through sdpd. I think this
is where Florian is illustrating the similarity to hidd in how we'll
operate.
BTW, I updated the bug list at sourceforge today.
Brad
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Florian,
I don't know enough about how hidd works. Does it spin off forked
processes for each device it finds?
Brad
Florian Echtler wrote:
>>Maybe what we're looking for is something to start/stop/restart
>>one-per-headset btsco deamons appropriately. Maybe a daemon itself.
>
> IMHO, the best option (I've been thinking about implementing that
> myself) would be the behaviour of hidd..
>
> Yours, FLorian
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
> Maybe what we're looking for is something to start/stop/restart
> one-per-headset btsco deamons appropriately. Maybe a daemon itself.
IMHO, the best option (I've been thinking about implementing that
myself) would be the behaviour of hidd..
Yours, FLorian
--
Preserve wildlife - pickle a squirrel today!
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fredrik
>>Can you comment on what the implications are for supporting multiple
>>headsets simultaneously with a single btsco daemon? Would the kernel
>>interaction need to be changed again or could it be limited to the daemon?
>
>
> Well, if you ask me, that's just unnecessary. It would add a lot of
> complexity to the btsco daemon, for no obvious purpose. I believe that
> if one wants multiple headsets, one should simply run multiple instances
> of the btsco daemon.
Maybe what we're looking for is something to start/stop/restart
one-per-headset btsco deamons appropriately. Maybe a daemon itself.
I will tag and merge the latest changes tonight. We will need to update
the README (I can do this myself at some point) and Thomas or someone
who uses it should fix btsco2.
I believe everything (with the possible glaring exception of userspace
btsco.c) was indented to "kernel style" using some magical args to
indent. If things work ok, I will do an indent pass again to make the
look consistent.
Brad
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, 2005-03-14 at 14:51 +0100, Fredrik Tolf wrote:
> On Mon, 2005-03-14 at 12:52 +0100, Lars Grunewaldt wrote:
> > Is it possible to have the headset buttons work as they did without the
> > patch, like, switching between both behaviours? there are scenarios for
> > both methods, and even the BT specs cover both of them.
> I'm not sure if the signal interface or config file extension is the
> best, really, so I'd appreciate comments on that.
In fact, I took the time and extended the config file format. Now, the
daemon has a "SCO force" variable, that forces connection or
disconnection. If this variable is set to 0, the SCO channel will not be
connected, if it is 1, it will be connected, and if it is -1 (the
default), the connection status will depend on the driver usage.
Some sample config files:
AT\+CKPD=200
system play ~/sounds/click05.wav
AT\+CHLD=2
system play ~/sounds/click06.wav
AT\+CKPD=200
sco-force on
AT\+CHLD=2
sco-force off
AT\+CKPD=200
sco-toggle on off
AT\+CHLD=2
system play ~/sounds/click06.wav
The arguments to sco-force and sco-toggle can be `on', `off' or `none',
which corresponds to the values 1, 0 and -1 of the force variable,
respectively. The default for sco-toggle is to toggle between on and
none.
The new patch is once again available at
<http://www.dolda2000.com/~fredrik/patches/btsco.diff>
Fredrik Tolf
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, 2005-03-14 at 05:55 -0700, Brad Midgley wrote:
> Fredrik
>
> >>> * Instead of (dis)connecting with the headset button, the driver
> >>>notifies userspace when it is in use, and the userspace program connects
> >>>accordingly.
> >>> * Send SIGUSR1 to the userspace program to make the headset ring.
> >>> * The userspace program now reads a config file, ~/.btscorc, which
> >>>contains alternating lines of regexes and shell commands. Everything
> >>>that the headset sends is matched against these regexes, and if a match
> >>>if found, the shell command is run (with any back references replaced).
> >>>This, of course, is primarily intended to "do stuff" with the headset
> >>>button(s). Send SIGHUP to re-read the config file.
>
> Can you comment on what the implications are for supporting multiple
> headsets simultaneously with a single btsco daemon? Would the kernel
> interaction need to be changed again or could it be limited to the daemon?
Well, if you ask me, that's just unnecessary. It would add a lot of
complexity to the btsco daemon, for no obvious purpose. I believe that
if one wants multiple headsets, one should simply run multiple instances
of the btsco daemon. It's much simpler, for both the programmer and the
user. That's one of the reasons why I didn't update btsco2. ;-)
Handling multiple headsets in one daemon instance also breaks signalling
-- you can't decide which headset to ring by sending a signal to one
daemon handling many headsets, for example. All in all, I don't see the
reason to increase the complexity of the daemon with what I see as
nothing in return.
Also, the kernel driver would have to be changed either way, since it
only supports one single headset right now, whatever you do in
userspace. I'm not sure what to do about the kernel driver. Maybe add a
module parameter that specifies the number of Headset "cards" to
register? I think it's either that, or a miscdevice that can be used to
register another "card" at runtime.
There are, however, other things that should be done with the userspace
daemon. First of all, I'm thinking that if multiple headsets are to be
supported, the config file should be extended to accept "blocks" of
regex/command pairs -- one block for each headset. That would also help
pairing a headset to a name. For example, the config file could look
like this:
hs1 00:01:02:03:04:05
AT\+CKPD=200
... more commands
hs2 06:07:08:09:0a:0b
AT\+CKPD=200
... more commands
Then, the btsco daemon could be called like "btsco -f hs1" and "btsco -f
hs2", hs1 and hs2, of course, representing the names of the headsets.
Also to support multiple headsets, the daemon would need a way of
specifying what "card" to use.
Another thing, that I'm not sure is a good idea, is to implement a
"fail-safe" mode in the daemon. Running the daemon in fail-safe mode
would mean that it doesn't die from not being able to connect to the
headset. Instead, it would try to reconnect periodically. Same thing if
the connection is lost at some point. The reason I'm not sure if this is
a good idea is that one would have to wait for the reconnection attempt
to get the headset working after making it accessible. Therefore, it may
well be a good idea to just have to run the daemon manually when one
knows that the headset is accessible. However, in this case, the daemon
should at least terminate if it looses the RFCOMM connection to the
headset. I don't know if it's possible to detect if the RFCOMM
connection is lost, though. Comments are appreciated.
Fredrik Tolf
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, 2005-03-14 at 12:52 +0100, Lars Grunewaldt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> |>>On the bad side, the coding is pretty unelegant in its places, and I've
> |>>completely violated your coding style. Also, backward compatibility for
> |>>userspace communication is broken since I had to extend the structure
> |>>for incorporating usage status. I haven't updated the btsco2 program
> |>>either.
>
> I really like the changes you made in this patch, but why don't you
> simply follow the coding style and send in a patch that's actually
> usefull to the community? It's not that hard to comply to coding
> style...? *scratchinghishead*
>
> maybe you could fix the coding style and send it in again :)
Well, to be honest, it's because I didn't understand the coding style.
There are lots of linebreaks that I neither see the meaning of nor any
pattern in. So I just didn't know what to do. :)
> Is it possible to have the headset buttons work as they did without the
> patch, like, switching between both behaviours? there are scenarios for
> both methods, and even the BT specs cover both of them.
Well, at first I was thinking that one could simply code a config file
that opens the corresponding DSP or ALSA device with a cat process or
something. I realized later, though, that that would make the next
access block, since the ALSA driver can only handle one open at a time
(since there's just one substream). So right now, I have no obvious
answer to this, except possibly that one could have a signal interface
to the btsco daemon (send SIGUSR1 to connect and SIGUSR2 to disconnect,
for example), but since I used SIGUSR1 to ring the headset, I'm not sure
what signals to use. One could use SIGUSR2 to toggle the connection
status, but that seems so ugly...
Maybe the config file could be changed to run some internal command set
in the daemon instead, like this:
AT\+CKPD=200
sco-toggle
AT\+CHLD=2
system (whatever command to make gnomemeeting pick up, for example)
Or:
AT\+CKPD=200
sco-connect
AT\+CHLD=2
sco-disconnect
I'm not sure if the signal interface or config file extension is the
best, really, so I'd appreciate comments on that.
Fredrik Tolf
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Fredrik
>>> * Instead of (dis)connecting with the headset button, the driver
>>>notifies userspace when it is in use, and the userspace program connects
>>>accordingly.
>>> * Send SIGUSR1 to the userspace program to make the headset ring.
>>> * The userspace program now reads a config file, ~/.btscorc, which
>>>contains alternating lines of regexes and shell commands. Everything
>>>that the headset sends is matched against these regexes, and if a match
>>>if found, the shell command is run (with any back references replaced).
>>>This, of course, is primarily intended to "do stuff" with the headset
>>>button(s). Send SIGHUP to re-read the config file.
Can you comment on what the implications are for supporting multiple
headsets simultaneously with a single btsco daemon? Would the kernel
interaction need to be changed again or could it be limited to the daemon?
Brad
-------------------------------------------------------
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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
|>>On the bad side, the coding is pretty unelegant in its places, and I've
|>>completely violated your coding style. Also, backward compatibility for
|>>userspace communication is broken since I had to extend the structure
|>>for incorporating usage status. I haven't updated the btsco2 program
|>>either.
I really like the changes you made in this patch, but why don't you
simply follow the coding style and send in a patch that's actually
usefull to the community? It's not that hard to comply to coding
style...? *scratchinghishead*
maybe you could fix the coding style and send it in again :)
Is it possible to have the headset buttons work as they did without the
patch, like, switching between both behaviours? there are scenarios for
both methods, and even the BT specs cover both of them.
best regards & thanks for helping out,
~ Lars
- --
Lars Grunewaldt
* software development
* multimedia design
skills: C/C++/Java/PHP/(X)HTML/Flash/audio/video
web: http://www.dark-reality.de
mail: [email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCNXsHQWC6DTWkDAoRAty+AJ9aa55eTNBHLL9A5xgTzwVT6c7lmACfQ5mm
+Nw6fldrnKKJlRGwHV7qLkc=
=nWCb
-----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://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel