@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.

Is there any plan to replace Mir?

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?)

Greatly exaggerated

"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

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)

The Mir server libraries

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 https://mir-server.io/doc/group__mir__toolkit.html

@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.