The two changes aren't really related, but oh well, I don't want to open too many PRs.
Documentation is now built at build-time, using pod2man within Automake instead of a separate build-mans.sh. The built documentation that was committed has been removed, and *.1 added to the .gitignore. The POD files were also moved to a new docs/ directory, to make it easier to find than contrib/man/.
In addition, a bt-audio implementation was added. This should fix #13, however the manual page's description doesn't really tell me what it did. It seems like before it was using BlueZ 4's org.bluez.Audio.Connect, and I think org.bluez.Device1.Connect is the new version; this would explain why the workaround in https://github.com/khvzak/bluez-tools/issues/13#issuecomment-338431323 is so simple. It seems to work, since I can type ./src/bt-audio -c <devicename> and audio from it will start playing on my laptop... is that the correct behaviour?
If it is, then I wonder if it would make sense to remove bt-audio again and merge it into bt-device (maybe with a small wrapper for muscle-memory/scripts). It seems like BlueZ 4 has org.bluez.Input.Connect, and that sounds like something that would've ended up in org.bluez.Device1.Connect, meaning that bt-input would also be served by the common implementation. bt-serial seems a little trickier, having something to do with profiles? I don't have a way to test either of bt-input or bt-serial, so I don't know if what I'm saying makes any sense.
If you don't like anything here (e.g. moving manpages to doc/), let me know and I can probably remove it.
The two changes aren't really related, but oh well, I don't want to open too many PRs.
Documentation is now built at build-time, using pod2man within Automake instead of a separate
build-mans.sh
. The built documentation that was committed has been removed, and*.1
added to the.gitignore
. The POD files were also moved to a new docs/ directory, to make it easier to find than contrib/man/.In addition, a bt-audio implementation was added. This should fix #13, however the manual page's description doesn't really tell me what it did. It seems like before it was using BlueZ 4's org.bluez.Audio.Connect, and I think org.bluez.Device1.Connect is the new version; this would explain why the workaround in https://github.com/khvzak/bluez-tools/issues/13#issuecomment-338431323 is so simple. It seems to work, since I can type
./src/bt-audio -c <devicename>
and audio from it will start playing on my laptop... is that the correct behaviour?If it is, then I wonder if it would make sense to remove bt-audio again and merge it into bt-device (maybe with a small wrapper for muscle-memory/scripts). It seems like BlueZ 4 has org.bluez.Input.Connect, and that sounds like something that would've ended up in org.bluez.Device1.Connect, meaning that bt-input would also be served by the common implementation. bt-serial seems a little trickier, having something to do with profiles? I don't have a way to test either of bt-input or bt-serial, so I don't know if what I'm saying makes any sense.
If you don't like anything here (e.g. moving manpages to doc/), let me know and I can probably remove it.