Comment 10 for bug 1922792

> Thanks for the details. You did address the part about upstreaming the change to Debian. How important is that notification in practice? If feels like we should have bluez preinstall on the raspi images if that's not the case, and if it's pre-install is that really worth the packaging overhead to have to carry a delta over Debian?

Just to give a bit of context here, the bluetooth situation on the pi is somewhat complicated and there's compromises that we make between the desktop and server images:

The bluetooth module on the Pi is controlled via a UART. Two UARTs are available on the Pi (there's more on the Pi 4, but it's the same situation for the bits we're talking about here):

* the PL011 which is full featured (buffers, flow-control, etc.), and

* the mini-UART which is ... not. Furthermore, the mini-UART's baud rate is tied to the GPU's clock, so if that floats then the mini-UART's baud rate floats too

On models of Pi with a bluetooth module (everything except the Pi 2, the CM3/3+ and some models of the CM4), the PL011 is used to talk to the bluetooth module and by default the mini-UART is disabled. This is the configuration we use on the desktop images as we make the assumption a serial console is less important on something which almost certainly has a monitor, and this configuration permits the GPU clock to float (important for something relying upon graphical acceleration).

On the server images, we assume that the serial console *is* important, and so this is enabled by default. We don't *disable* the bluetooth module, but we don't pre-install the packages for it either. This means that the PL011 is tied to the bluetooth module by default (but unused), and the mini-UART to the serial console. Because the mini-UART is in use, the GPU's clock is locked to the base speed. This is a compromise because all the alternatives are nastier in some way for some of the typical use cases:

* If the server image is used without a graphical environment, and without bluetooth, this is fine (this is the default). The GPU's clock doesn't really matter in this scenario and the serial console will still work reliably.

* If the server image is used without a graphical environment, but with bluetooth, all the user needs to do is install pi-bluetooth and reboot (personally I don't think the reboot warning is terribly necessary; like knowing to install pi-bluetooth in the first place, it's fairly widespread knowledge and tends to be part of first-time setup steps anyway). This again leaves the GPU's clock locked (but without a graphical environment that doesn't really matter), the serial console still works, and bluetooth works.

* If the server image is used with a graphical environment, without bluetooth, the user needs to either disable the serial console (if they don't want it, this is a one-line change in the boot configuration), or alternatively add the line "dtoverlay=disable-bt" to the boot configuration which disables the bluetooth module entirely, allowing the serial console to use the "full" PL011 UART. Either option unlocks the GPU's clock.

* If the server image is used with a graphical environment, with bluetooth, that's effectively the same as the desktop setup and we assume that in this scenario the user would disable the serial console (which means the mini-UART is no longer used and the GPU's clock can float again); again, a one-line change in the boot configuration.

So the compromise is to ship an image which, with either zero steps or one step can be moved to one of the scenarios above, with hardware working acceptably for that scenario. We could default to, for example, shipping the server image with both serial console *and* bluetooth enabled, but that complicates moving to a GPU clock unlocked scenario as it involves either disabling the serial console (easy) or removing bluetooth (quite a bit harder, especially if the pi-bluetooth package is now depended on by a meta-package, and also still involves disabling the hardware module with the dtoverlay).

Anyway, for the above reasons I don't foresee that we're likely to ship bluetooth enabled server images anytime soon. As to how necessary a reboot warning is -- I'd consider it "nice to have but by no means critical" (it's not hardware enablement after all). If we want to keep the delta minimal, I've no objections.