On Fri, Nov 13, 2020 at 09:37:34AM -0000, Sebastien Bacher wrote: >@Matthieu, @Dave, thanks for the comments and details. > >I'm not blocking work to land, the 20.10 SRU could be accepted now and I >didn't revert in that serie. >The SRU team tries to ensure the fix is in the new serie so it doesn't get >forgotten/regress when next version is out but I think it's pretty clear we >are going to sort out the review details, that's not a blocker and SRU team >has been happy in the past to let things in with the understand than $newserie >is being sorted out
Ah, my apologies - I had mis-interpreted the reversion as applying to the SRU. I've no issue with a reversion in hirsute, provided it doesn't delay existing users from using their Bluetooth hardware. >> If upstream say "yes" to the patches, without further discussion: that's >> great, but there'd presumably still be some delay before another version >> makes its way down to us, so we'd be applying *some* patch to make it work >> in the interim. > >Again I'm not asking for the patches to be reviewed or accepted upstream >before they are uploaded to Ubuntu, I'm just asking for them to be sent >upstream and the reference to the email/report/merge request to be added >to the patches. It would probably have been less work to just do it >rather than type a long explanation here on why we need to distro patch >in any case (which I never disagreed with) I estimate, as I think several others do judging by various comments, that the patches in their current state don't stand much chance of passing muster upstream, and I have no desire to waste their time with a premature submission. At the very least, some justification needs adding to the 1 second sleep: either a datasheet reference, which I've so far failed to find, or some empirical measurements that it's actually required (which I'm in the process of gathering; I've verified *a* delay is required but not the minimum, or whether it can be combined with the post-load nanosleep), along with evidence it doesn't break any existing platforms (I've found a datasheet reference to back that bit up, but tests are good too). Anyway, sorry I mis-interpreted the release your action applied to; I look forward to seeing the SRU land. In the meantime, rest assured a submission will be made upstream as soon as I think I've got a faint hope of it passing! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1903048 Title: [SRU] Bluetooth won't activate on the pi 400 Status in bluez package in Ubuntu: Triaged Status in bluez source package in Hirsute: Triaged Bug description: [Impact] Without these patches, Bluetooth is inoperable on the recently released Raspberry Pi 400. [Test Case] * Boot the Ubuntu Desktop for Pi image on a Pi 400. * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is not enabled and attempting to activate it fails * sudo add-apt-repository ppa:waveform/pi-bluetooth * sudo apt update * sudo apt install bluez * sudo reboot * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, mobile phones, headphones, etc.) can connect and operate correctly [Regression Potential] Extremely low (on groovy in particular, this has the same version of bluez as hirsute). The only significant risk is to non-Pi platforms or dongles which also use the Broadcom 43xx (or Cypress 305) chips for Bluetooth which might be inadvertently affected by these patches. [Original Description] The new Pi 400 has a slightly different Wifi/BT chip to the Pi4. Whilst wifi works happily, Bluetooth fails to operate. This doesn't appear to be an issue with either the firmware (the latest versions from upstream Raspbian have been tried), or the kernel (a known-good raspi kernel has been tested under Ubuntu), but with Bluez itself. Specifically, tracing the initialization with btmon on Raspbian and Ubuntu, the stack consistently fails when attempting to "Set Default PHY" on the latter. Curiously, under Ubuntu the adapter also appears to lack a MAC address. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1903048/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
