Signal UT: Signal-Desktop for Ubuntu Touch

Moem

@pparent Amazing improvements, thank you very much!

klh

@pparent your store description is a bit misleading

The application is somewhat slugish because it is not GPU-accelerated (because apparmor prevents the app from accessing the GPU)

It's sluggish because you run it under Xorg - which is your choice, not a system limitation.

It is not possible to copy and paste text from other applications (should be solved with Mir 2.0)

It won't be solved by Mir 2 because you are running it under Xorg, and the difference with Mir 2 is that it supports the Wayland clipboard protocol.

If you are going to support ContentHub at some point, clipboard is easy and handled by the same service.

pparent

@klh said in Signal UT: Signal-Desktop for Ubuntu Touch:

It's sluggish because you run it under Xorg - which is your choice, not a system limitation.

Please if you have a better way to do things, show us how to improve the app, I'm more that open to contributions and help, and it's clear that the app is 3 weeks old, and is currently not in it's optimal state, far from it, and it is supposed to evolve rapidly.

The only "choice" of my part, is trying to make it work, as soon as possible, and as good as possible, with the infos that I have at hand, and in that regard I just copied the way uWolf is working (And by the way the snap version of signal-desktop also starts with X11). In the code of uWolf ( that is the most famous port of a desktop app in the store and one of the only one), it says explicitly "# Explicitly force X11 backend for GTK applications like LibreWolf (will remove when mir2.x comes out)". Which led me to belive it's not possible to have a GTK app working properly with Wayland until the release of Mir2.x, and I did plan to switch to Wayland then, so I don't see why copy and paste would not work then. If you have any example of a GTK app working properly (including keyboard) in Wayland mode with Mir1.2, please share!

What I can say is that in my initial tests, if I run the app unconfined I can get it hardware accelerated even with X, so it seems the apparmor does prevents the app from accessing the GPU at least in an X11 context and without specific configuration. You can try it I do publish the unconfined version in github releases. So my statement is just a mere observation. Maybe if the app can be started with wayland the GPU would be accessible even in a confined context, but I still haven't found how to do it, despite my attempts.

Please if you have solutions to make it work better than it currently does, then show them to make things go forward! It's not helping to suggest that I make on purpose bad choices so that it does not work properly, while I'm spending a lot of my time contributing an app that somehow nobody has made until now, despite being an important need for many Ubuntu Touch users.

Ps: by the way I've also asked general questions about electron apps with Wayland In Ubuntu Touch, in the context of upcoming Mir2.0 realease, more than one month ago, before starting this app, without seemingly a consensus about what was possible or not, so I'm just experimenting. https://forums.ubports.com/topic/4507/electron-apps-on-ubuntu-touch/4

pparent

Anyway I can tell that there will be significant performance improvement in next release!

domubpkm

@pparent Personally, I don't use signal (only telegram) but congratulations for your investment in porting this desktop app for UT, which will be of great service to many.

fredldotme

@pparent a technical explanation as to why this app will always be slow with Xwayland:

X11 historically uses GLX for passing buffers from the client to the server, and GLX inherently is tied to Desktop OpenGL. Desktop OpenGL and OpenGL ES as used on Ubuntu Touch devices are different. The only way forward would be EGL and that would require changes to Xwayland to handle the Android driver's/libhybris EGL implementation.

I tried bringing hardware acceleration to Xwayland once and it resulted in only one device (the JingPad) being remotely capable of doing it, with render artifacts. Since then we run Xwayland in shm mode which guarantees software rendering in all cases. So whatever you perceived as hardware accelerated before must have been a placebo.

pparent

@fredldotme

Ok thank you!

But maybe chromium engine can make use of GPU for tasks that are not directly related to compositing? Because here it's an electron app with a chromium engine.

Just to make things clear I would like to switch to wayland if/when it is feasible. If someone has informations about how to run a GTK wayland app, with keyboard support, either with Mir1.2 or Mir2.0, please share as it would be extremely usefull!

For now, if I start with wayland: the window does not display correctly ( wrong scaling or wring size, as --force-device-scale-factor=2.75 make the window very big, it's like it zooms on it but does not reduce its size), it is more slugish than with X11, and it has no keyboard.

pparent

Here would be my current starting script for wayland is there a way to do better to solve some of the problems?
@fredldotme @klh

#!/bin/sh

# Input method (probably does nothing as it is for X11 normaly)
 export GTK_IM_MODULE=Maliit 
 export GTK_IM_MODULE_FILE=lib/aarch64-linux-gnu/gtk-3.0/3.0.0/immodules/immodules.cache 

# Prefer Wayland
export GDK_BACKEND=wayland
export DISABLE_WAYLAND=0
export OZONE_PLATFORM=wayland
export QT_QPA_PLATFORM=wayland
export XDG_SESSION_TYPE=wayland
export WAYLAND_DISPLAY=${WAYLAND_DISPLAY:-wayland-0}

export GTK_USE_PORTAL=1
export DCONF_PROFILE=/nonexistent
export XDG_CONFIG_HOME=/home/phablet/.config/signalut.pparent/
export PATH=$PWD/bin:$PATH

dpioptions="--high-dpi-support=1 --force-device-scale-factor=2.75"
gpuoptions="--use-gl=egl --enable-gpu-rasterization --enable-zero-copy --ignore-gpu-blocklist --enable-features=UseSkiaRenderer,VaapiVideoDecoder,ThreadedAnimation --disable-frame-rate-limit --disable-gpu-vsync --enable-oop-rasterization --enable-threaded-compositing"
sandboxoptions="--no-sandbox --disable-features=WaylandWindowDecorations " 
waylandoptions="--ozone-platform=wayland --enable-features=UseOzonePlatform"

exec ./opt/Signal/Signal $dpioptions $gpuoptions $sandboxoptions $waylandoptions

The main thing for any hope of a usable option with wayland, would be to enable the keyboard for gtk over wayland. (And this I'm a bit afraid of the feasibility in Mir1.2). The other thing is to have a decent scaling factor while keeping the window of the right size, but if it is the only thing it can always be patched within Signal code, which is certainly not ideal but most probably doable.

klh

@pparent iirc my immodules hack won't work for Wayland, and you won't get an onscreen keyboard in Mir 1.8 because it's missing all the IME protocols.

I haven't looked at what electron-only features the signal-desktop app uses, but you could look into packaging Node.js and running the back-end parts there with a shim in WebEngine to communicate with that. Not trivial, but would give you near-perfect integration with the OS.

pparent

@klh said in Signal UT: Signal-Desktop for Ubuntu Touch:

@pparent iirc my immodules hack won't work for Wayland, and you won't get an onscreen keyboard in Mir 1.8 because it's missing all the IME protocols.

I haven't looked at what electron-only features the signal-desktop app uses, but you could look into packaging Node.js and running the back-end parts there with a shim in WebEngine to communicate with that. Not trivial, but would give you near-perfect integration with the OS.

Yes I had thought about this option, but I in reality want to remain as close as possible from original client, and keep a small set of patches. For these reasons:

1°) Because Signal-Desktop needs regular updates, as old versions get outdated fast and are not anymore compatible with the protocol. A version of Signal-Desktop is valid for 3 months. So I don't want heavy hacks that will not port easily from one version to another. I need to be able to recompile newer versions without headaches.
2°) Because I want to minimize the risk of security breach coming from Signal-Desktop customization.
3°) I want to avoid that Signal project may not be happy about our client because of messing too much with their protocol/client.

So If nothing is possible while keeping the binaries as is, I will stay with X until Mir2.x release.

Can you confirm, that the keyboard with Wayland should be better with Mir2.x?

Ps: I'm currently debuging and trying to patch the code of maliit-inputcontext-gtk, to try and solve the bugs we currently have with the keyboard with X.