@rvan said in will ubuntu touch ever be upgraded past ubuntu 16.10:

One of these is currently listed as 'inactive' so I want to refrain from residing in this category if possible.

In addition to what @AppLee wrote, another thing to keep in mind is that most device maintainers are volunteers and might stop contributing all of a sudden (for example, if they break or sell their device) or, on the contrary, a new maintainer might pick up an abandoned port. So, unless you pick a device officially supported by the Foundation, the situation will always be volatile.

In general, if you have a device in your hands that is no longer supported, one option is to find a volunteer and buy them a used device to work on

@applee said in New kernel builds: call for testing:

@josevidal
If I'm not mistaken if you switch channel and go back you should trigger a complete flashing of your device.
But I can be wrong...

I'm not sure if switching channels is enough (I guess it is, but I'm also not sure), but for sure reflashing the device with the installer will do it.

Update: I've created a PPA with the installer:
https://launchpad.net/~mardy/+archive/ubuntu/ubports-tools

Now I'll slowly add more devices

@josevidal said in New kernel builds: call for testing:

During the time I have been using the new kernel it seems to me that when I have internet data enabled the battery consumption is higher. When I have the data connection disabled I have not detected any difference in battery consumption.

Linux ubuntu-phablet 3.4.67 #1 SMP PREEMPT Tue Jan 11 22:54:05 MSK 2022 1.2.1_20140721-1138- armv7l armv7l armv7l GNU/Linux with BQ E4.5

Thanks Jose! It would be valuable if you could run a test where you use the data connection for about 1 hour (or at least half hour) with and without this new kernel, to see if it really makes a sensible difference. Better if both tests start from the same level of charge; in other words, it's better if initially the battery is at 100% level. Maybe you can just leave the device idle, but connected to the internet, and see how the battery is like after 1 hour.

Hi there!
In the last few days I've been working on a command-line installer for Ubuntu Touch. The goal is not to replace the current graphical installer, but to have a piece of software written in a language (shell scripting) that is familiar to more developers, and that hopefully would be easier to modify.

I've tried to write it in such a way that it should not be hard to embed it into a graphical application; it's not fully ready for that yet, but if someone familiar with the graphical installer source code wants to try embedding the command-line installer, I can support him

At the moment, this is in very early stages:

• it supports only the BQ devices cooler, frieza, krilling and vegetahd
• localization (translations) support needs to be implemented
• need to find a way to package it (I'll most likely create a snap myself, but all contributions for other packaging formats will be welcome)
• need to write a README file explaining how to write device config files

I would appreciate if interested people would try it and report back, but for the time being this is for advanced users only. You need to clone the repository and execute the flasher script from there:

$ ./flasher -h
Usage: flasher [options] [command]

If no command is given, the 'flash' command will be executed by default.

Options:
 -b, --bootstrap          Also flash the vendor firmware (this option is needed
                          if the device is currently running a different OS)
 -c, --channel <channel>  Uses the given channel (default is 'stable')
 -d, --device <dev-id>    Specifies the connected device (default: autodetect)
 -h, --help               Show this help screen
 -q, --quiet              Reduce verbosity level
 -v, --verbose            Increase verbosity level
     --wipe               Erase all user data on the device

If you don't own a BQ device but would still like to try it, the existing files under the device_configs/ directory could serve you as an example; the fact that these files are bash scripts, make it possible for the device maintainer to execute almost any type of operation in there (and it is possible to override the default actions). If you manage to write a working config file for your device, please make sure to submit it with a merge request!

@arubislander said in New kernel builds: call for testing:

@sk @mardy Did you get a chance to compile a new kernel for the M10 FHD? If not could you maybe share what steps are needed? I have compiled my own desktop kernel in the past, so I should be OK following instructions. Point me to a more suitable discussion platform is needed.

Not yet, sorry! I've been busy with something else

If you feel like trying, please have a look at the README I added in https://gitlab.com/ubports-legacy-devices/cooler/kernel_bq_m10, because I expect that the steps will be quite similar.

Hi @ungeskriptet, could you please give a try to the fm-radio-service package at https://ci.ubports.com/blue/organizations/jenkins/UBportsCore%2FFM radio service/detail/MR-4/1/artifacts?

Please write your feedback as a comment to https://gitlab.com/ubports/core/fm-radio-service/-/merge_requests/4

Hi all!
I've recently spent some time to rebuild the kernels for a handful of BQ devices; while my initial goal was to just enable the FM radio on them, I made an unhappy discovery along the way: just building the kernel sources that we have in github does not produce the same kernel that we are currently running in our devices — a few options are different.

So, I spent some time finding what the differences are, and tried to change the kernel configurations so that they would match what we are currently running (and yes, in the process I also enabled the FM radio on them ). Now it's time to give them a week or two of testing, and then we can decide whether to push these kernels to all users.

Call for testing

Please download the kernel for your device:

• BQ E4.5: install the kernel from this release.
• BQ E5: install the kernel from this release.
• BQ M10 HD: install the kernel from this build.
• BQ M10 FHD: I don't have this device, please attach the file /proc/config.gz to this thread and I'll make a build for it.

Then, reboot your device to the fastboot mode (POWER + VOL UP, then select "Reboot to bootloader") and run

# Adjust the path as needed
fastboot flash boot /path/to/the/downloaded/boot.img && fastboot reboot

It does not matter what channel you are running on your device.

What to pay attention to

Ideally, you should see no changes. If you observe a degradation of the power consumption, or if something stops working, please report it here.

Why test this?

Because this is the first step we need to take in order to hope to move these devices to 20.04; I'm not saying that if these kernels work we are all happy and ready to go, but this is a prerequisite. So, please, if you have one of these devices, give it a try, and report back (maybe after a week or two).

Thanks in advance

@ungeskriptet said in FM radio: testing instructions and feedback:

@mardy Found it. It's called vendor.qcom.bluetooth.soc on my device.

phablet@ubuntu-phablet:~$ getprop|grep cherokee
[vendor.qcom.bluetooth.soc]: [cherokee]

OK, I'll update the service to check that property too.

@ungeskriptet said in FM radio: testing instructions and feedback:

Hey @mardy, I modified the vendor partition like on Redmi Note 9 Pro for my Poco X3 NFC, which I ported myself and noticed that the FM radio only works after setting vendor.bluetooth.soc to cherokee (It's empty on my device) manually. I could create an overlay for my port which sets that property, but I don't know if it's the best idea or is there something wrong with the FM service?

Wow, good work!! The fm-radio service explicitly checks for that property to be set to cherokee, but that's just because I saw that the qualcomm FM radio app does the same. You could try to run a getprop on the device and see if there's some other property which can be used to identify the bluetooth/radio chipset, and then I could add it to the fm-radio-service. Or, indeed, setting that property in the vendor partition would be a solution.

@dpitti said in FM radio: testing instructions and feedback:

@mardy I have the Redmi Note 9 Pro since yesterday. Since I have to go back from Android 11 to Android 10 anyway, I will download this global version V12.0.3.0.QJZMIXM. Everything else that has to do with the radio I will do at a later date. I tried to get the Redmi Note 7 Pro but no chance.

The Redmi Note 9 Pro works as well, but you need to get a couple of binaries into your vendor partition. I created a script to do it, but it's for advanced users only

https://gitlab.com/mardy/xiaomi-miatoll/-/tree/fm-radio/tools

@hsce1 said in FM radio: testing instructions and feedback:

@mardy
Wow! FM radio on Ubports would be a dream!

It is for sure not one of the priority devices but could fm radio potentially also work on the S3Neo?
zcat /proc/config.gz | grep -n RADIO_IRIS gives:

2587:CONFIG_RADIO_IRIS=y
2588:CONFIG_RADIO_IRIS_TRANSPORT=y

https://forums.ubports.com/topic/3652/call-for-testing-samsung-s3-neo-s3ve3g-owners/91

Nice! Please follow the instructions from the comment just above this one

@eichenbast said in FM radio: testing instructions and feedback:

What should be the next for the Xperia X?

The syslog (/var/log/syslog) captured while trying the FM radio would be helpful

Edit: ah, sorry, now I see, that this device exposes with the /dev/radio0 device. That's currently not supported, but I'm working on that too.
Can you please download the fmbin program from here (for 64bit devices) or here (for 32 bit devices), then copy it to the device, make it executable, and run it?

Once it starts, type:

init
enable

and paste here the syslog.

Hi, I've now updated the repository with newly-built packages, please try.
I'm not using these changes myself; I was hoping that they could get merged quickly, but people raised concerns that this change effectively means that all websites would now continue working in the background if one website is using the location, which is not desirable. But unfortunately I don't have enough time (and motivation) to fix that, so I'm afraid this won't be merged soon.

I've had a similar discussion with Dalton in Telegram, because I'm working on the FM radio service and getting it to work on the BQ devices requires a new kernel for them, and this led to a discussion about what we can do for them.

I'm certainly willing to spend some of my time to keep these devices up, but that might not be enough: from the UBports Foundation point of view, supporting a device means (and here I might even not be aware of all the implications!) having all the CI machinery to generate the images for the updates, not to mention the time spent by humans for bug triaging.

I guess that if we could reduce the involvement of the UBports Foundation to "just" produce a unified armhf rootfs for all these devices, that would be much easier for them, and we could probably expect a relatively high level of quality. But that means that the device maintainer would have to take care of producing the OTA images and diffs, and provide storage for them. GitLab CI can certainly help, but it's clear that the amount of work that would fall on the shoulders of the device maintainer (at least initially) is huge.

Do we have a team of volunteers, who do understand enough of the OTA machinery to setup a similar project, which might or might not be hosted by the UBports Foundation? I'm certainly willing to help, but it's not something I can drive myself. And I don't think we should ask anyone who's actively working in the Foundation to spend time on this.

If we manage to form a group, and find someone willing (and capable) of leading the project, then there's some hope. Otherwise, well, I guess these devices will have to live with Xenial for how long they can.

@guf said in FM radio: testing instructions and feedback:

@mardy The output of command:

phablet@ubuntu-phablet:~$ sudo ls -l /dev/fm* /dev/radio*
ls: cannot access '/dev/fm*': No such file or directory
crw-rw----+ 1 system system 81, 18 Apr 14  1971 /dev/radio0
phablet@ubuntu-phablet:~$ 

This looks promising! But you will have to play with the udev rules to change the group of the file to android_media, otherwise the phablet user will not be able to open the device.

@guf said in FM radio: testing instructions and feedback:

@mardy I tried on my BQ U Plus (I'm the official porter, even though the device is not officially in the list).

Thanks for trying!

CONFIG_RADIO_IRIS is the module, but it seems to have some issue.
The rootfs.img I actually use is a stable one with some months old. Might it be useful to test with more recent version of edge one for armh?

No, a newer rootfs would not help. The service backend does not implement support for the Iris module, but I can try to add it, since it should be exposed as a standard V4L2 device. What does the following command say?

ls -l /dev/fm* /dev/radio*

Same here. The SIM slots used to work, but they suddenly stopped working a couple of years ago. I'm afraid it's a hardware issue, because I tried reflashing android and it didn't recognize the SIMs either.

Even in the factory mode the SIMs are not working.

@cibersheep said in Lineage 15.1 for Cooler:

happy news, the developer has updated Cooler Lineage image to 15.1, so in theory we could update the kernel (with work)

https://github.com/bq-mtk/ota_releases/releases/tag/lineage-15.1-v3-freezerhd

This is excellent news, thanks for the link!

I recently played a bit with the M10, until I totally broke it (I'm still hoping to see it resurrect once the battery runs out for good, because now it gives no signs of life whatsoever), and I managed to build a working kernel. Here's my pull request.

The BQ github repos actually carry kernel 3.18, a more modern kernel version than the 3.10 we are using, so we could also try those.

But the project you found is extremely interesting, because it looks like it's actually being somehow maintained. An interesting repo I noticed:

• Device tree for the BQ tablets: https://github.com/bq-mtk/android_device_bq_mt8163-common (it even has a branch for LineageOS 16)

That seems to be for freezer, though; I cannot find a device tree for cooler. Unless it's actually the same?

Hi all!
I got to a point where I'm ready to share the work I've been doing on the FM radio service, because it should be testable already. But please note, this is only for the adventurous ones .

Enabling your device

Unfortunately there is only a handful of devices supported at the moment:

• BQ E4.5: install the kernel from this release.
• BQ E5: install the kernel from this release.
• Xiaomi Redmi Note 7 Pro: should work out of the box, but you might need to reflash it from the installer (ticking the "bootstrap" checkbox) if you flashed it long ago
• Xiaomi Redmi Note 9 Pro: follow these instructions.
• Are you a maintainer of another device port which has hardware support for FM radio? Get in touch!

NOTE: the warning sign () means that there is a concrete risk to break your device if something goes wrong while following the operations to enable the FM radio, so it's a procedure recommended for expert users only.

Installing the FM radio service

If your device appears in the list above and you've followed the instructions to enable the FM radio on it, the next step is to install the fm-radio-service in your Ubuntu Touch device:

1. Download the fm-radio-service and fm-radio-tools packages matching your device's architecture from the latest build.
2. Copy them to your device, make the root partition writable and install them:

   adb push fm-radio-*.deb /home/phablet/
   sudo mount -o remount,rw /
   sudo dpkg -i fm-radio-*.deb
   

3. Start the command-line client:

   fm-radio-client.py
   

4. Make sure your wired earphones are connected.
5. Press 2 for "Open tuner", then Enter.
6. Press 7 for "Start playback", then Enter.
7. You can move to the next or previous station with 5 and 6, and you can change the volume with 4 (values are from 0 to 100)
8. Press 1 to quit the program and stop the radio.

Known issues

• On the BQ phones, the volume is not controllable via the hardware keys. It is probably possible to fix this by writing a pulseaudio module, but before spending time to work on this I'd like to understand how many devices would benefit from this. It's an issue that affects Mediatek-based devices only, and probably not all of them.
• On the Xiaomi devices, radio playback consumes about 10% of the CPU. There should be a way to establish a direct path from the FM radio to the audio device, but so far I haven't been able to find it.

Debugging

If things don't work, please do the following:

1. Quit the client application (press 1, then Enter)
2. Run

   FM_RADIO_SERVICE_TIMEOUT=999 fm-radio-service
   

   on one terminal and leave it running while executing the next step
3. Launch the fm-radio-client.py program again, and repeat the commands to open the tuner and start the playback
4. Attach here (or send them privately to me) the output from the fm-radio-service program you started on step 2 and the syslog (/var/log/syslog)

Feedback

Please let me know how it goes. If I get at least some positive feedback, there's a chance we'll see this in one of the next OTAs. I already have a UI application ready -- ugly, but working.