Call for testing: Ubuntu Touch 24.04-1.3

sixwheeledbeast

Signal strength isn't the issue, I wouldn't expect them all to be the same.
I know the signal strength is displayed much lower on 1.3 for 5G and 4G compared with 1.2 is the point

domubpkm

@gpatel-fr I switch from RC to stable. H-2 again. I did the command line and i confirm it solved the problem : good clock.

gpatel-fr

@domubpkm

interesting. Now this behaviour is a bit surprising since the service is supposed to be activated on-demand, so it's pretty normal it's stopped.

I did not check where and how in the code it's tested that the service is stopped but it's astonishing that such a check is even done.

Nonetheless, if starting the service actually fixes the clock it's an indication that this hypothesis deserves further research..

domubpkm

@gpatel-fr I seemed to see that at the end of booting the smartphone (before I entered the pin code) when switching to stable, the screen showed the correct time (H) and very quickly went to H-2.

kristatos

@gpatel-fr I've searched a bit and there is aleady a bugreport for that (it was already filled some days ago for the daily channel).
I've linked the thread to this bugreport.

sixwheeledbeast

Possible issue found in 1.3, maybe this could be checked it's not only myself?
Bluetooth can't be disabled or enabled from the battery menu. The toggle moves but it doesn't work and stays in the same state.
I use this regularly as a quick way to achieve some power savings from one place, part of discussions on usage here
Disabling from there own respective pull down works correctly.

d4f0

@sixwheeledbeast said:

Possible issue found in 1.3, maybe this could be checked it's not only myself?
Bluetooth can't be disabled or enabled from the battery menu. The toggle moves but it doesn't work and stays in the same state.
I use this regularly as a quick way to achieve some power savings from one place, part of discussions on usage here
Disabling from there own respective pull down works correctly.

It also happens on my FP4 with 1.3

projectmoon

@d4f0 said:

@sixwheeledbeast said:

Possible issue found in 1.3, maybe this could be checked it's not only myself?
Bluetooth can't be disabled or enabled from the battery menu. The toggle moves but it doesn't work and stays in the same state.
I use this regularly as a quick way to achieve some power savings from one place, part of discussions on usage here
Disabling from there own respective pull down works correctly.

It also happens on my FP4 with 1.3

Seems to be a bug, yes. Happens to me on a Volla Quintus with stable 1.3.

messayisto

@projectmoon can't confirm on volla quintus, 24.04-1.3 rc

gpatel-fr

@sixwheeledbeast said:

Bluetooth can't be disabled or enabled from the battery menu. The toggle moves but it doesn't work and stays in the same state.

Yes I see that on my FP5.
I searched a bit and I think that the problem is not in the settings, it's in the Bluetooth stack itself.
Rationale: launching bluetoothctl, I can see that when activating the switch, there is this message:

[bluetooth]# hci0 new_settings: connectable bondable ssp br/edr le secure-conn

the interface is made 'connectable' and 'bondable'.
When activating the bluetooth in the bluetooth page, these messages are displayed:

[bluetooth]# hci0 new_settings: powered connectable bondable ssp br/edr le secure-conn

that is, in one case the interface is powered while it's not in the second case. The switch is changed but after a few seconds when the system realizes the discrepancy between the real state of the bluetooth interface and the switch, it switches back the indicator statute.
When going from the battery page to the bluetooth page, the state is checked immediately and the switch is going back to enabled almost instantly.

While it's the same action in both case ('bluetooth-enabled') it has 2 different effects!,
I'd need to check what are the messages passing at the Dbus level in both cases.

For now it's a bit late for me, logging off.