Question: How to use Dayon! Snap with Wayland ?

[eheintzmann]

I tried Dayon! Snap on Ubuntu 24.04 at the assisted side without success.

According to #20 OracleJDK or OpenJDK 21 should be used on Wayland.
But current Dayon! Snap uses OpenJDK 11…

Since Wayland is the default graphics environment on Noble, is it possible for users to overrides JDK used in Dayon Snap ? If yes, how ?

Thanks

[RetGal]

Hi, unfortunately simply switch the JRE inside the snap wouldn't solve the Wayland issue.

At the moment the only workaround is to change the desktop session of the assisted from "Ubuntu" to "Ubuntu on Xorg" at the login screen.

The Ubuntu core for snap apps is still based on Ubuntu 22.04..

I'll have to look into this further, but for the moment I can't see any other solution.

[eheintzmann]

Hi,

Hi, unfortunately simply switch the JRE inside the snap wouldn't solve the Wayland issue.

Why ? Is it a strict confinement issue with interfaces ?

The Ubuntu core for snap apps is still based on Ubuntu 22.04..

I can see a core24 at https://snapcraft.io/core24
But I'm not familiar with snap development. Maybe it isn't ready yet ?

Thanks

[RetGal]

Hello,
no, it's not a confinement issue. I have built a experimental Dayon! snap with JRE 21 but the screencapturing still doesn't work with Wayland: Could not load native libraries for ScreencastHelper.

Even without the snap, i.e. if the dayon.jar is run direcly with a JRE 21, it has some issues, it captures exactly once and then:

'this->recurse > 0' failed at ../src/pipewire/thread-loop.c:63 do_unlock()
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:426 pw_thread_loop_wait()
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:426 pw_thread_loop_wait()
...

So I guess the current Wayland support of Java is still quite fragile..

And yes, core24 is currently in an experimental state and not production ready at all.

So I'm afraid that at the moment the mentioned workaround is the only way to use the assisted part of Dayon! with Ubuntu 24.04.

[eheintzmann]

Hi,

'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:426 pw_thread_loop_wait()
It seems this error is related to pipewire :

• https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2835
• https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2242#note_2021553

Kagukara has it on one screen but not on another ones.

I'm afraid that we have to wait for a fix from pipewire / OpenJDK

Thanks

[RetGal]

Hi,

Thanks for the research!
Even when pipewire is fixed, there will still be a bunch of serious bugs in Javas Wayland support:
https://wiki.openjdk.org/display/wakefield/Known+problems+and+solutions

I don't know why it's taking them so long - Wayland has been around for a while and is becoming more and more popular.

[eheintzmann]

Hi,

Thanks for the link !
According to this wiki, there are 2 goals:

• a short to medium term solution for JDK running on Wayland in X11 compatibility mode
• a medium to long term solution for JDK running as a native Wayland client.

Maybe it is possible to test Dayon! with Wayland in X11compatillity mode ?
If I can find time next week, I will try to build and run Dayon! on Arch Linux with openjdk wakefield AUR packages.
https://aur.archlinux.org/packages/jdk-openjdk-wakefield

[RetGal]

Hi,
This would be great, as things are behaving a bit weird:

• On Ubuntu 24.04 (Noble) with openjdk 21.0.3 2024-04-16 and pipewire 1.0.5-1 a dialog to allow capture the screen appears once after the assisted is connected to the assistant, but right after that:
  this->recurse > 0' failed at ../src/pipewire/thread-loop.c:63 do_unlock() (The assistant screen remains grey)

• On Debian 12.4 (Bookworm) with almost the same openjdk 21.0.3 2024-04-16 LTS (Azul Zulu) but a much older pipewire 0.3.65-3, Could not load native libraries for ScreencastHelper gets logged right after the assistant accepts the assisted connection. (The assistant screen gets black)

The behavior on Debian is very similar to the snap with core22 using openjdk 21.0.2 2024-01-16 and an unknown, but very likely an even older pipewire version.

For this tests I compiled Dayon! with maven.compiler.target 21, but it doesn't seem to make any difference whether the target is 11 or 21.

[eheintzmann]

HI,

I've done some testing.

• On Assistant side, an Ubuntu Noble 24.04, with Dayon from stable Snap
• On Assisted side, an Arch Linux with latest Dayon, from git, built with the jdk-openjdk-wakefield from AUR and the maven.compiler options set to 21 (I had to pass -DskipTests to maven because tests fail).

When connecting, gnome-shell propose to choose the screen to share. But all I see on the Assistant is

• a gray screen
• or a black screen with the assisted mouse pointer
• or the assisted screen, but fixed (it is never updated)

Also, I never can take control on the Assited.

As messages, I obtain lines like

[       CaptureEngine] [ WARN] (07:45:28.657) Skipping capture (10) 21,25s

So I can't say it is working

Let me know if you need others tests.

[RetGal]

Hi,

First of all: thanks for your testing and feedback!

The warning about skipping a capture is logged, if the screen capture could not be created in time - so it is skipped to catch up and sync with the next "tick". This can happen because of high CPU load or a huge screen resolution on the Assisted side.
It usually can be mitigated by lowering the capture interval i.e. by increasing the "tick".

But as you mentioned, we will definitely have to wait for some improvements from Piperwire and openJDK before Dayon! can be used to assist PCs using Wayland.

[eheintzmann]

Hi,

I increased the "tick" and redid the same tests with different JDK :

• jdk-openjdk-wakefield 21.0.1.0.r184.ge338a16-5 AUR package
• jdk21-openjdk 21.0.3.u9-1
• jdk-openjdk 22.0.1.u0-1

Thanks to the new "tick", messages about skipping capture have disappeared, but still I can't see the assisted screen.

I hope that improvements from Piperwire and openJDK will not be long

Thanks for your support

---

About the unit test failure :

org.opentest4j.AssertionFailedError: expected: <300 (66.7%)> but was: <300 (66,7%)>

A percentage with a dot is expected, but there is a comma instead.
I think it is just a localization issue.

[eheintzmann]

Hi,

This would be great, as things are behaving a bit weird:
...
The behavior on Debian is very similar to the snap with core22

I've just seen this new:
https://9to5linux.com/pipewire-1-2-release-candidate-adds-explicit-sync-and-snap-support

It seems they will add Snap support in pipewire.
If I understand well, it means there is no support for Snap in current Pipewire.
It would explain why things are behaving a bit weird.

---

About the failed unit test.
Well done, the test passes now !

[RetGal]

Hi,

Thank you for your research! I have added this information to the thread I recently opened on the Snapcraft forum:
https://forum.snapcraft.io/t/pipewire-doesnt-work-in-snaps/40235
However, as it has turned out to be a rather tricky problem, I don't expect there to be a solution in the very near future!