For the slot Permanent policy I think it is fine to allow the bluez
interface access to /dev/ttyAMA0. ofono, ppp, et al are in similar
situations.
That said, if I understand this bug correctly, the most correct solution
would seem to be for the pi gadget snap to declare the serial-port
interface, eg:
slots:
pi-bluetooth:
interface: serial-port
path: /dev/ttyAMA0
such that the bluez snap would do:
apps:
bluez:
daemon: simple
plugs:
- serial-port
The question of which to do is I think dependent on how often this situation
occurs. If there are many gadgets that have different /dev entries, then having
gadget yaml expose this seems the right choice-- the bluez snap need only
'plugs: serial-port' on any device that has a gadget that exposes it and it is
connected (in this way there are no snapd changes required for new
devices/etc-- gadgets are updated to expose the correct device and bluez picks
them up as it gains support for the device).
If the pi is the only gadget out there that does this, then I think it
also makes sense to go the gadget route.
Adding to the permanent slot policy probably only makes sense if
/dev/ttyAMA0 specifically is a common access across a wide variety of
devices. Even then it could be argued the gadget route is the way to go,
but in this particular case putting it in the permanent slot policy
could remove a small stumbling block for gadget developers.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1674509
Title:
Unable to find bluetooth device on RPi3 running Ubuntu Core 16
To manage notifications about this bug go to:
https://bugs.launchpad.net/snappy/+bug/1674509/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
