AGPS has been an aspiration for the project since the initial Canonical effort. Does the sunsetting of https://location.services.mozilla.com/ affect the feasibility of this feature?
Posts made by alan_g
-
RE: Ubuntu Touch Q&A 136 Call For Questions
-
RE: Ubuntu 16.04 BQ Aquaris M10 Mir app dev issues.
@zezba9000 you are asking questions about a stack that people moved on from. Four years ago:
- The mirclient API your client uses was dropped in favour of Wayland; and,
- Unity8 was renamed Lomiri
The error you are seeing is because Unity8 used to scan the client's command line to identify the .desktop file. (I forget what it actually looked for, but if you peek at the .desktop files for apps that do work, it will be obvious.)
But while I applaud using Mir, targeting a long obsolete version from an obsolete OS release seems like a bad idea. Even legacy systems ought to be running an OS that is supported.
-
RE: How to detect Ubuntu Touch using system variables in shell script?
@GermanAizek they wouldn't be empty run from the Terminal app. You might think it obvious you wanted to use
adb shell
but you didn't tell us.How about checking
${USER}
for "phablet"? -
RE: Ubuntu Touch Q&A 124 call for questions.
What is the state of the Lomiri desktop environment for the upcoming release of Ubuntu 23.10?
-
Mir has landed support for maliit-keyboard
Support for the Wayland extensions (
zwp_input_method_v1
andzwp_input_panel_v1
) needed bymaliit-keyboard
(as used by Lomiri) have landed upstream in Mir. They are not in the Mir 2.15 release currently being tested, but will be available in subsequent releases.As this was requested for Lomiri (by @dobey) I hope this of interest here. There will be some Lomiri work needed to use this in Lomiri so I hope the following will include enough information to guilde this.
Using Mir's support for maliit-keyboard
The easiest way to test this support is to install Miriway from edge and configure it to support
maliit-keyboard
:sudo snap install miriway --classic --edge sudo apt install maliit-keyboard cat /etc/xdg/xdg-miriway/miriway-shell.config/ > ~/.config/miriway-shell.config cat <<EOT >> ~/.config/miriway-shell.config shell-add-wayland-extension=zwp_input_method_v1 shell-add-wayland-extension=zwp_input_panel_v1 shell-add-wayland-extension=zwp_primary_selection_device_manager_v1 # it isn't obvious why maliit-keyboard needs this shell-component=miriway-unsnap maliit-keyboard EOT
You can then log out and log back in into Miriway from the greeter.
maliit-keyboard
will show when input is on a text field*.[*] The client needs to support one of the
text-input-v{1,2,3}
Wayland extensions.Please report any issues on Mir's github: https://github.com/MirServer/mir/issues
-
RE: Possibility of basing on ubuntu core?
@extraymond said in Possibility of basing on ubuntu core?:
run lomiri as it is on mir which I assume is possible with ubuntu core
If by "on mir" you mean using the mirclient IPC, then no. That won't work on Ubuntu Core.
Helpfully , that leaves you with just one option:
learn about confined-shell and mirway and see if I can get lomiri running as a standalone snap on a ubuntu core device.
Here's the code for these:
https://github.com/MirServer/confined-shell-wip
https://github.com/Miriway/Miriway -
RE: Possibility of basing on ubuntu core?
@extraymond I'd love to see this happen, but are you volunteering to work on it? Or hoping someone else does?
I've some knowledge of both Ubuntu Touch and Snaps and am willing to advise.
For anyone interested, the POC described would be a huge amount of work. Probably less than the 20.04 transition but certainly more than a few months:
-
Ubuntu Touch uses a custom kernel for each phone so a kernel snap would need to be maintained for each phone. I also suspect that work would be needed to have hallium "play nice" with snapd.
Anyone tackling this has a huge learning curve to surmount: You likely have as much knowledge as anyone else here about getting hallium working in a kernel snap -
The base doesn't really matter for this, but I'd suggest core20 to match the 20.04 base of other UBports projects
-
Lomiri (the shell used by the project) is not designed to work with snap confinement, so this would involve more than "just packaging".
And "just packaging" as a snap isn't trivial for shells - I speak as one that has done it! (See below) -
The only snap interface between Lomiri and "an snap" would have to be
wayland
(There is no Snap interface for the legacy mirclient-based IPC).
The client bit is simple, there are loads of snaps available that consume thewayland
slot. However, work on transitioning Lomiri to Wayland is incomplete (it has been in progress for several years)
If you're on Ubuntu desktop, you can experiment with a couple of relevant snaps of another Mir based shell (Miriway) that I've packaged: you can install both of these on your system:
- confined-shell is a strictly confined snap which is what is needed to install on Ubuntu Core; and,
- miriway an unconfined snap that doesn't have to deal with the limitations imposed by strict confinement
Probably the most tractable part of this POC would be to package Lomiri as a snap. This could also be useful for Lomiri's desktop ambitions. You could get an idea of what's involved by starting with a "classic" snap modelled on miriway.
-
-
RE: Forum migration
I too can't find any settings to change the horrible colour scheme. But I found the colours are OK (unchanged?) on an iPhone. Time to switch?
-
RE: Ubuntu Touch Night Light Feature
A better discussion of implementing this feature is:
The tl;dr: it needs to be implemented (in Mir) and someone who thinks it important needs to their spend time doing that.
-
RE: Ubuntu Pro
@arubislander said in Ubuntu Pro:
Only ESM support does not include ARM packages, so it turns out.
That's true for 14.04 and 16.04 but has changed since:
-
RE: Ubuntu Touch Q&A 121 Saturday 19th November at 19:00 UTC
Can you tell us how the integration of extended support for Ubuntu 16.04 went and what it means for both developers and users of Ubuntu Touch?
-
RE: Ubuntu Pro
@rugby the developers (I think @Flohack is driving it) have been liaising with Canonical to get security updates from them. And, once this is in place, these will be incorporated in the OTA updates.
-
The Mir team is recruiting
Mir is a core part of the what makes Lomiri and Ubuntu Touch possible and the Mir team (of which I'm a member) is recruiting:
-
RE: Phoronix: Mir 2.9 w/XDG-Shell; Add'l Extensions: Any Impact on UBPorts?
@eirikr1848 I'm the team lead on Mir and can reassure you that there's open communication between the UBports devs and the Mir team, so this isn't news to them.
There are several pieces of work needed before Mir 2.9 could be integrated into Ubuntu Touch:
- The UT ecosystem (apps, toolkits, indicators, etc) needs to migrate from the mirclient API to Wayland;
- To do this, some functionality gaps need plugging that mirclient API provided and require new Wayland extension protocols; and,
- Ubuntu Touch's QtMir needs to migrate to using Mir's libmiroil API
Some exploratory work has been done on all of these task and it is mostly a matter of someone finding time for them.
However, unless someone else steps up and volunteers, most of this work needs to be completed by the UBports devs and they are currently busy with the migration from 16.04 to 20.04.
-
RE: Ubuntu Touch Q&A 120 This Saturday 30th July At 19:00 UTC
@psingh said in Ubuntu Touch Q&A 120 This Saturday 30th July At 19:00 UTC:
I recall though how when Canonical maintained the OS they had a "pages" feature
I think this was called "scopes".
-
RE: Vulkan and USC 0.9.0 (Mir)
@duncancragg said in Vulkan and USC 0.9.0 (Mir):
do you mean there was work done inside /Mesa/ to support mirclient's Vulkan buffers
Vulkan, like GL and GLES, is an API.
Mesa is an implementation of graphics API specifications like GL, GLES and Vulkan.
For each API work is needed to support mirclient.
-
RE: Vulkan and USC 0.9.0 (Mir)
Sorry, your phone has a niche graphics stack based on libhybris and android hardware drivers. The only folks that understand that are working on Ubuntu Touch (or other Halium based phone OSs).
I have no direct knowledge of the current status of Wayland (or Vulkan) support over this graphics stack. Better to ask someone that works on it.
-
RE: Vulkan and USC 0.9.0 (Mir)
@duncancragg firstly, the mirclient API has been deprecated for five years and I've done nothing with it in that time. So you will be very much on your own in attempting this.
Next, by way of context, Vulkan, GL, GLE, GLES, etc are ways for a client to form graphical content ("buffers") to pass to the server. (Yes, "the server" would be Lomiri, etc.)
For GL* there were changes to Mesa to submit the buffers using mirclient.
When Canonical dropped Unity8 and related projects there had been some initial work done for using mirclient via Vulkan, but it was never merged.
At a minimum, you'd need to update and complete the mirclient support in the Vulkan driver. But I don't know if that would be enough.
What you may have seen elsewhere, is that Vulkan applications using Wayland work with Mir. That doesn't help you with getting Vulkan working on mirclient. (And I suspect that is a lot more work than you hoped for.)
-
RE: Looking for Wayland experts
To some extent it depends on the actual goal. Is this intended as a test harness for an app in a controlled environment? Or as a means of automation on a desktop?
Faking udev ought to work across different compositors. The virtual keyboard extensions might work for some compositors but different compositors support different protocol extensions. (E.g. Mir supports
virtual_keyboard_unstable_v1
but notorg_kde_kwin_fake_input
.)If this is just for an application test harness, then it should be possible to test against a specific, even a bespoke, compositor.
This could be complicated for most people I know as they have employers, and work (especially paid) outside that raises contract concerns.
Maybe ask on the wayland-devel mailing list?