Dear Maintainer,

* What led up to the situation?

Upgrading to the new yoshimi version 2.3.4.1-2

* What exactly did you do (or not do) that was effective (or
 ineffective)?

Launching yoshimi gives me an error.

* What was the outcome of this action?
--------------------------
Yay! We're up and running :-)
yoshimi> Failed to load plugin 'libdecor-gtk.so': failed to init
No plugins found, falling back on no decorations
Segment violation
--------------------------

* What outcome did you expect instead?

Launching yoshimi without problems :)

Greets.

Sorry, but this bug seems important, two new yoshimi versions have been
launched later and it continues failing for the same reason. Any clue for
making yoshimi work again in wayland?

Greets.

Hi all,

speaking for the Yoshimi-devs, we became aware of that problem some
days ago through the report of an Ubuntu user. Our investigations
uncovered the following

- it happens when having built against FLTK-1.4 and running
   on Gnome + Wayland. It does not seem to affect KDE Plasma,
   but we'll have to confirm that

- the crash happens at the point where Yoshimi creates and
   shows the main application window.

- the problem is related to FLTK using the wayland backend,
   which is a new feature with v1.4

   Thus, as a workaround, start yoshimi with

   FLTK_BACKEND=x11  yoshimi


It is not related to any specific Yoshimi version.
We have reproduced the crash even with versions from 2021,
before the time we made the Yoshimi UI scalable and themable.
The only condition is to link against FLTK 1.4

The typical stacktrace looks as follows


====== Stacktrace from Yoshimi 2.3.5.1  ========

#0  0x0000557ac9197a27 in ?? ()
#1  0x00007853314c9bfd in Fl_Group::draw_child(Fl_Widget&) const () from
/lib/x86_64-linux-gnu/libfltk.so.1.4
#2  0x00007853314c9e52 in Fl_Group::draw_children() () from
/lib/x86_64-linux-gnu/libfltk.so.1.4
#3  0x00007853314c9bfd in Fl_Group::draw_child(Fl_Widget&) const () from
/lib/x86_64-linux-gnu/libfltk.so.1.4
#4  0x00007853314c9e52 in Fl_Group::draw_children() () from
/lib/x86_64-linux-gnu/libfltk.so.1.4
#5  0x000078533151e20b in Fl_Window::draw() () from
/lib/x86_64-linux-gnu/libfltk.so.1.4
#6  0x00007853315497ee in Fl_Wayland_Window_Driver::flush() () from
/lib/x86_64-linux-gnu/libfltk.so.1.4
#7  0x0000785331547b09 in ?? () from /lib/x86_64-linux-gnu/libfltk.so.1.4
#8  0x000078533038e88c in xdg_surface_configure (user_data=0x78530443d4d0,
xdg_surface=<optimized out>, serial=263) at ../src/libdecor.c:357
#9  0x000078532f981ed6 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#10 0x000078532f97eba6 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#11 0x000078532f9814ae in ffi_call () from /lib/x86_64-linux-gnu/libffi.so.8
#12 0x00007853303a198b in ?? () from /lib/x86_64-linux-gnu/libwayland-client.so.0
#13 0x00007853303a27c9 in ?? () from /lib/x86_64-linux-gnu/libwayland-client.so.0
#14 0x00007853303a2bc3 in wl_display_dispatch_queue_pending () from
/lib/x86_64-linux-gnu/libwayland-client.so.0
#15 0x00007853303a633a in wl_display_dispatch_queue_timeout () from
/lib/x86_64-linux-gnu/libwayland-client.so.0
#16 0x00007853303a640f in wl_display_dispatch_queue () from
/lib/x86_64-linux-gnu/libwayland-client.so.0
#17 0x000078533153fe5b in ?? () from /lib/x86_64-linux-gnu/libfltk.so.1.4
#18 0x000078533153e9d0 in
Fl_Unix_Screen_Driver::poll_or_select_with_delay(double) () from
/lib/x86_64-linux-gnu/libfltk.so.1.4
#19 0x000078533154a9a1 in Fl_Unix_System_Driver::wait(double) () from
/lib/x86_64-linux-gnu/libfltk.so.1.4
#20 0x0000557ac91ad8dc in ?? ()
#21 0x00007853306a3d64 in start_thread (arg=<optimized out>) at
./nptl/pthread_create.c:448
#22 0x00007853307373bc in __GI___clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

====================

This clearly shows that no actual Yoshimi code is directly involved.
Pesumably, it must be a combination of FLTK features we use in some widgets
that indirectly cause the problem.

Currently we are looking into ways how we can strip down the UI of yoshimi,
(which is massively complex) in order to narrow down the search space.

I don't use Gnome, but raw Labwc and Yoshimi fails on my system.

Status Update:

- it is not Gnome, it is Wayland which triggers this problem

- the root cause is that Yoshimi uses lib Cairo for some custom
   drawing in the UI since a long time, and this legacy code
   contacts X-Lib to retrieve a Cairo surface.

- we have worked out a fix, which relies on the FLTK Cairo bridge
   available since FLTK 1.4. This allows us to retrieve the Cairo
   surface directly from FLTK, irrespective of the underlying
   backend.

- However, this requires that FLTK is built with this additional
   feature enabled. In Debian this is the case, so Debian should
   be fine. Some other Distros do not yet enable this feature though.

   The feature we need is marked as "Fl_Cairo_Window support" and
   can be enabled either with
   ./configure --enable-cairo
   or
   cmake -DFLTK_OPTION_CAIRO_WINDOW=true

- we intend to publish a bugfix minor release of Yoshimi soon,
   once all further details have been settled

that FLTK was built with the "Cairo bridge" -- which is the case
in Debian.

However, we still have to resolve some follow-up issue in one
pop-up diagram and to some further testing...

Hi :)

Last yoshimi version seems to fix this bug. Only problem I see is that when you
choose an instrument and virtual keyboard is open, focus doesn't jump to the
keyboard automatically like before. Rest of application seems to work well.

Greets.