Seeing the above question about integrating Wayland I think it would be good time to explain how some things fit together:
@Leppa said in Ubuntu on Huawei devices?:
the chinese government can ask for whatever data they, want, and get it
This is hardly unique (c.f. https://www.govinfo.gov/content/pkg/PLAW-107publ56/html/PLAW-107publ56.htm), and is not the regulatory obstacle to shipping Ubuntu Touch in China.
But, regardless of regulatory concerns, the commercial reality is that Huawei can continue to use the open parts of Android and already have replacements for Google services they could roll out worldwide. For them that is far less risky than switching to something that is far less mature, and unproven in any commercial market.
An oft asked question has arisen on the Telegram channel once again and I thought I'd post an answer here for posterity:
Is there any plan to replace Mir? Since it's completely abandoned, it may take too much effort to maintain it, and it may better to switch to Wayland, if it's possible, since it has way more support. - so manpower could be used somewhere else (PWA maybe?)
"I can understand perfectly how the report of my illness got about, I have even heard on good authority that I was dead. [A cousin] was ill in London two or three weeks ago, but is well now. The report of my illness great out of his illness,. The report of my death was an exaggeration." - Mark Twain
Like the reports of Mark Twain's death, Mir's abandonment is based on a misconception.
There's a lot of confusion about this because "the internet" has confused toolkits supporting the mirclient API with servers using the Mir libraries. These are two different stories.
The mirclient API is a way for application toolkits (and other client-side libraries) to use Mir. This API is abandoned: it is no longer under development and the Mir developers have deprecated it and will remove it "someday". I think UBports is the only remaining project to use it (the Mir support in Kodi, SDL2, gtk3, etc has been dropped).
UBports do need to switch from using the mirclient API to using Wayland before "someday" becomes "today". That is a multi-step process described here: The Way to Wayland (for Unity8)
Mir was the core of Canonical's effort to enable "Convergence". [See: https://forums.ubports.com/post/18392 for my take on "Convergence"]. These libraries are still supported and developed by Canonical and there are a number of projects using them or planning to use them. Canonical has IoT projects, some experimental "desktop" work (including with MATE).
There is no reason for UBports to switch from using the Mir server libraries, they are the foundation on which Unity8 (and some other, less visible, components) are built. Even with the issues presented by the switch to using Wayland for applications the support for "Convergence" is unique to Mir and core to UBports.
@guru said in xev like tool to see key_press (...) events:
Is the OSK used to route the chars to the terminal-app when the key-events (and mouse events) come from a Bluetooth device?
No.
At least the OSK is not visible in this case on the screen.
Exactly.
Where I could check the sources for the OSK?
They'll be on github or gitlab (UBports are migrating projects from one to the other).
I suspect you are misunderstanding me: OSK is not the solution you asked for, but it is the only process that does anything even vaguely like what you want. So, if you figure out how it is able to do that, you might be able to use that knowledge to create something new to remap input.
I suggest that writing a new terminal app (or enhancing the existing one) with the ability to remap input would be far simpler.
@guru said in xev like tool to see key_press (...) events:
In plain old X11 there is a tool xev to read and understand what the Xserver gets as key-pressed, key-release etc. events and one can map these with another command xmodmap to characters the application receives.
How I could do this within UT? Is there some app to read native from the keyboard? Or some undocumented logging?
Mir (and therefore Unity8) takes the view that applications should not be able to "spy" on the input to other applications. So, in UT applications don't have access to input devices and only get key events that Unity8 routes to them.
As you may suspect, there's a special dispensation for the OSK to synthesise keyboard events and pass them (via Unity8) to the app. I don't know enough about how that works to know if it could help your scenario.
@kugiigi said in Qt Creator for Unity8 developing?:
It's created with Qt so it also works on mir, right?
Yes, if you use the Wayland backend: QT_QPA_PLATFORM=wayland. (Warning: that's pretty flaky with the Qt version in the 16.04 archives.)
On 16.04, it probably works with the mirclient backend : QT_QPA_PLATFORM=ubuntumirclient.
I remember trying it out on my Nexus 5 and the main issue is the scaling.
That was probably using the X11 backend: QT_QPA_PLATFORM=xcb and Xmir. (Which is also flaky.)
I don't know what source you have for "Qt Creator has Wayland support", so you may know something I don't. But I imagine that this means it runs on the Qt "wayland" backend.
That isn't exactly new, I've been using it as a test program for Mir's Wayland support for a couple of years. There's a glimpse of it on the egmde snap store page:
@fossMan said in 2019: Time to make Unity8 great again?:
I would like to look at these issues but can't spare the focus time until start of June.
I imagine there will still be issues left for you when you have the time. 
@fossMan said in 2019: Time to make Unity8 great again?:
What exactly is the "mirclient API", is that an abstraction or a specific set of files? Could you give a small example e.g a line of code showing dependence on that API, and perhaps how a Wayland extension could replace it?
The mirclient API is the API provided by libmirclient.so. It is the API through which Mir proposed to support "Convergent" application toolkits. There are various bits of UBports relying on this API that need rework to Wayland (so learning to do that will remain useful after this exercise).
Here's some mirclient API code:
Surface surface{mir_connection_create_render_surface_sync(DecorationProvider::connection, width, height)};
auto const buffer_stream =
mir_render_surface_get_buffer_stream(surface, width, height, mir_pixel_format_xrgb_8888);
auto window = WindowSpec::for_gloss(DecorationProvider::connection, width, height)
.set_fullscreen_on_output(output_id)
.set_event_handler(&handle_event_for_background, this)
.add_surface(surface, width, height, 0, 0)
.set_name(wallpaper_name).create_window();
and some equivalent Wayland code:
ctx.surface = wl_compositor_create_surface(globals.compositor);
...
ctx.shell_surface = wl_shell_get_shell_surface(globals.shell, ctx.surface);
wl_shell_surface_set_fullscreen(
ctx.shell_surface,
WL_SHELL_SURFACE_FULLSCREEN_METHOD_DEFAULT,
0,
ctx.output.output);
...
auto const shm_pool = make_scoped(
make_shm_pool(globals.shm, stride * height, &ctx.content_area),
&wl_shm_pool_destroy);
ctx.buffer = wl_shm_pool_create_buffer(
shm_pool.get(),
0,
width, height, stride,
WL_SHM_FORMAT_ARGB8888);
https://github.com/MirServer/mir/pull/669/files#diff-ea35a63c157fb0d09e5713c6ee0b1dbe
@fossMan said in 2019: Time to make Unity8 great again?:
@alan_g said in 2019: Time to make Unity8 great again?:
Once Mir has a Mir-on-Wayland platform it will be possible to retain that architecture and use Wayland instead of the mirclient API.
Naive question alert, sorry:
is it possible to estimate/ quantify the amount of work for that task in any way? E.g, how many skilled developers will need to work on this problem fulltime in order to have a solution in one year? 50, 100, 4...?
Almost all the code concerned is here:
$ wc -l src/server/graphics/nested/*
253 src/server/graphics/nested/buffer.cpp
64 src/server/graphics/nested/buffer.h
20 src/server/graphics/nested/CMakeLists.txt
54 src/server/graphics/nested/cursor.cpp
51 src/server/graphics/nested/cursor.h
225 src/server/graphics/nested/display_buffer.cpp
105 src/server/graphics/nested/display_buffer.h
442 src/server/graphics/nested/display.cpp
178 src/server/graphics/nested/display.h
183 src/server/graphics/nested/host_buffer.cpp
73 src/server/graphics/nested/host_buffer.h
54 src/server/graphics/nested/host_chain.h
95 src/server/graphics/nested/host_connection.h
50 src/server/graphics/nested/host_stream.h
52 src/server/graphics/nested/host_surface.h
49 src/server/graphics/nested/host_surface_spec.h
528 src/server/graphics/nested/input_platform.cpp
84 src/server/graphics/nested/input_platform.h
92 src/server/graphics/nested/ipc_operations.cpp
48 src/server/graphics/nested/ipc_operations.h
825 src/server/graphics/nested/mir_client_host_connection.cpp
134 src/server/graphics/nested/mir_client_host_connection.h
74 src/server/graphics/nested/native_buffer.h
234 src/server/graphics/nested/nested_display_configuration.cpp
78 src/server/graphics/nested/nested_display_configuration.h
35 src/server/graphics/nested/passthrough_option.h
227 src/server/graphics/nested/platform.cpp
117 src/server/graphics/nested/platform.h
4424 total
That needs re-implementing to use Wayland protocol extensions instead of the mirclient API.
It isn't a lot of code, and not a lot of work. But it does need someone that can read mirclient code and write Wayland code. I've done that a few times (for the "internal" clients in the example shells) and the concepts correspond well.
There are few other parts of the system that would need touching (e.g. the configuration to set it up) but that is less of a problem.
I think it would take me a couple of days (but the unexpected could happen). However, that's probably the fastest it could be: there are not many that know the Mir codebase as well as I do.
tl;dr: Depending on the developer's background, anywhere from a few days to a month.
Convergence is mostly a software thing. There are two parts to this:
flexibility: the software including shell and application GUI adapts to the capabilities of the hardware it runs on.
This means that the same software, with the same features, works well on a desktop, a phone or a toaster.
agility: the software including shell and application GUI adapts to changes to the capabilities of the hardware is running on.
This means that connecting a display, keyboard, dock etc. will enable user interactions optimized for these.
Most existing software is not designed for either of these goals. The Ubuntu Touch experience of using "desktop" apps in Libertine speaks to this, it is possible to use these applications, but the interaction is poor because these apps do not adapt to the hardware. This can change but, like any change, there will be costs, pain and resistance until suddenly it will be done and everyone wonders why it was ever any different.
But the software is only a part of what is being alluded to here. Real use-cases are not about using a specific piece of software, they are about accomplishing goals: publishing something, learning something, meeting someone. That needs a combination of user data, software and access to hardware.
I've had a long career in software development and seen computing shift from centralized "mainframe" computers that hold the data and programs for multiple users to "personal" computers that hold a users data and programs and back to centralized "clouds" that hold all the data. That change has been driven by economics: changes in the costs of computers and of connecting them.
While there are legitimate privacy and security concerns the economic drivers are currently pushing towards centralization and connections. Many apps are little more than optimized front-ends for data and computational services elsewhere on the internet. I think this trend will continue before a readjustment back towards "personal" computation.
In this context, any "one device" we might carry is more about having the keys (or passwords) we need to accomplish our daily tasks than carrying all the software and data we use. If both my laptop and phone can support all my daily tasks interchangably, browsing the web, emailing, Telegram, IRC, software development, video calling, phone calls, SMS, etc. then I need only take the one best suited to the occasion. Having the same software and keys on both is what would make them interchangable. (And yes, phone calls are best on a phone while software development is best on a laptop, but making both possible gives me control.)
@domubpkm the image you posted shows the dark theme, what do you think is wrong? (Remember, the theme affects the app, not the website you're viewing.)
I'm just curious (I'm content to let updates come when they arrive) but...
Why does sudo system-image-cli -v -p 0 --progress dots have to run via adb? Can't it work from the terminal?
@mic_ said in Observations on battery life - please share your experiences:
After 9 hours in standby (without turning on) the phone dicharged from 100% to 63%. In the same time my BQ E5 discharges from 100% to 98%.
Actually everything else on my Nexus 5 is really working very fine and I love this phone. But it is still loosing so much energy power while I am not using it that this is still a knock-out argument for this beautiful phone / ubuntu system combination! What the hell it is doing all the time while laying around?
I've seen it do that too. But, more often, I've seen it hold charge better and be around 90% after the night. (Still not great I agree, but tolerable.) On these occasions I've not seen anything suspicious running top, but that doesn't really tell what was happening when the screen was off.
I have a long running suspicion that the radio hardware is not always in the state the software believes it to be in. In this case, that "off" shown by the software isn't actually "off". This could explain both battery life problems, and also the flakiness of hotspot. (I'm not sure how to go about proving that idea.)
@sander-klootwijk @arubislander
I too am in The Netherlands, specifically Baarn "close to Amersfoort".
(Long term I'm in the UK, but not for a few more weeks.)
I'm interested in the progress updating to Mir 1.x (no surprise there):
[Update]
I now realize that the answer to "Is the phone graphics stack migrating to Wayland in the first iteration?" has to be "no":
( These considerations will also impact the Unity8 Desktop to a lesser extent.)
@doniks said in 2019: Time to make Unity8 great again?:
Wouldn't it then be more logical to have a greeter that is a wayland client? Or maybe the login managers from some other desktop environment could be used.
Curious what you think.
The Canonical design was for unity-system-compositor [USC] to be a system wide Mir server that supported both the greeter and login session based shells. Only USC would interact with the hardware, it would see the greeter and session shells as Mir clients. The session shells would use the mirclient API (a.k.a. "Mir-on-Mir") but that requires "Mir EGL" and is no longer possible.
This architecture has a number of desirable features: only one system-wide task has to negotiate access to the hardware, and that task also controls transitions between user sessions, login screens and lock screens.
Once Mir has a Mir-on-Wayland platform it will be possible to retain that architecture and use Wayland instead of the mirclient API.
One of the big changes has been to the Mesa graphics drivers: Ubuntu used to carry a "Mir EGL" distro patch that enabled EGL clients to use the "mirclient API". Because Mesa changed in ways that broke that patch badly it was dropped in Ubuntu 18.04. I'll discuss this further below under "Going Wayland".
...
Unity8 is based on Mir and @mariogrip had done the work needed for Unity8 to run on Ubuntu 18.04 without "Mir EGL" by using Wayland instead of the "mirclient API" (which is supported by recent versions of Mir).
In the OP I neglected to mention one very useful side-effect of these changes: Because Unity8 can now run without the "Mir EGL" distro patch it is no longer restricted to running on Ubuntu.
As recently mentioned on the Mir forum Mir works on the following distros:
On most of these distros developers have also got Unity8 running.
I've noticed a few discussions recently regarding developers getting involved in developing Unity8. I don't know all the answers myself, and don't have the free time to find them, but I think I can start a constructive discussion.
The Unity8 shell comprises a lot of inter-related projects and dependencies. These have to be coordinated and installed together, this worked best in Ubuntu 17.04 at which point it was possible to install a usable Unity8 desktop from the archive with a single command.
When Canonical withdrew from the project they understandably stopped maintaining these projects and dropped them and a number of the dependencies from the archives. There have also been some incompatible changes to some of the dependencies.
One of the big changes has been to the Mesa graphics drivers: Ubuntu used to carry a "Mir EGL" distro patch that enabled EGL clients to use the "mirclient API". Because Mesa changed in ways that broke that patch badly it was dropped in Ubuntu 18.04. I'll discuss this further below under "Going Wayland".
The UBports team has done its best to maintain the projects and dependencies in the UBports repo, but this hasn't been the most urgent thing to work on and they have not dealt with everything that has changed.
I've never built the majority of Unity8 components from source, not am I sure which branches are canon in the UBports source repositories. I'm sure developers could figure this out, but it would save everyone time if there were a blogpost.
The bits I do know:
echo "deb http://repo.ubports.com/ $UBUNTU_CODENAME main" | sudo tee /etc/apt/sources.list.d/ubports.listwget http://repo.ubports.com/keyring.gpg -O - | sudo apt-key add -This is the bit I understand best (because I work on Mir). It is also, I think the biggest cause of deterioration since 17.04.
Unity8 was originally built using the "mirclient API" which was designed for convergence. But for "mirclient API" to be useful this needs support in client toolkits and even with Canonical pushing it this was never great. Since then, it has been dropped from GTK+ and SDL2.
Unity8 is based on Mir and @mariogrip had done the work needed for Unity8 to run on Ubuntu 18.04 without "Mir EGL" by using Wayland instead of the "mirclient API" (which is supported by recent versions of Mir).
However, Wayland is not a "drop-in" replacement for the "mirclient API" and there are some limitations apparent on Unity8 desktop:
I am biassed by my involvement in Mir, but these are issues that an interested developer could tackle to make a significant improvement to the Unity8 desktop. In addition, they are easier to work on than Unity8 as the Mir project has significantly fewer dependencies (all of which are in the Ubuntu archives).
Another effect of the loss of "Mir EGL" in Mesa and the consequent switch to Wayland ls that the "Mir-on-Mir" support needed to use the Unity greeter is no longer available. Some work has been done on providing a "Mir-on-Wayland" graphics platform in Mir, but that needs significant rework (it is on my list of things I want to get to, but if you fancy taking it on get in touch).
Note: There are additional limitations to using Wayland on the phone that need to be addressed, but I'm keeping this discussion to Unity8 desktop.
Unity8 was not finished in 17.04, and quite a few of the things that were "done" need to be updated. I'm not an expert on this so I'll leave detailing a list to others.
What I do know:
I hope this provides a bit of impetus to developers interested in contributing to Unity8 to progress further. Even if this post is simply a place for potential developers to declare their interest and meet each other it will have served a purpose.