Wayland libdecor interoperability between FLTK and GLFW

[Gonzalo Garramuño]

I am giving a go once again to Wayland.  I currently use FLTK 1.4 with
GLFW which used to work fine, but now I am finding a conflict with
libdecor.  FLTK is run first and later on GLFW it is inited with its
context set to Wayland.

The error line that fails in GLFW is:

842            _glfw.wl.libdecor.context =
libdecor_new(_glfw.wl.display, &libdecorInterface);
(gdb) n
error marshalling arguments for (null) (signature done): null value
passed for arg 0
Error marshalling request: Invalid argument

I am guessing that:

1) FLTK uses its own libdecor.
2) GLFW, OTOH, uses and expects the system libdecor.

This is creating a conflict.  Is there a way to have FLTK use the system
libdecor?  I've tried:

-DFLTK_USE_SYSTEM_LIBDECOR=1
-DUSE_SYSTEM_LIBDECOR=1

with no avail.  FLTK always reports it is using the built-in libdecor.

--
Gonzalo Garramuño
ggar...@gmail.com

[Gonzalo Garramuño]

On 12/4/24 12:44, Gonzalo Garramuño wrote:
>
> This is creating a conflict.  Is there a way to have FLTK use the
> system libdecor?  I've tried:
>
> -DFLTK_USE_SYSTEM_LIBDECOR=1
> -DUSE_SYSTEM_LIBDECOR=1
>
> with no avail.  FLTK always reports it is using the built-in libdecor.

Oh... I just saw this configure warning:


Warning: system libdecor doesn't satisfy version > 0.2.2,
          using bundled libdecor library instead.

I guess Ubuntu 22.04.4 LTS is not new enough for FLTK 1.4.

--
Gonzalo Garramuño
ggar...@gmail.com

[Greg Ercolano]

On 4/12/24 08:51, Gonzalo Garramuño wrote:

I guess Ubuntu 22.04.4 LTS is not new enough for FLTK 1.4.

    I'd say it's still experimental, mainly for developers to test on
    the most stable Wayland environment so far, I suppose.

    I tried using it as a desktop for a few weeks but it kept getting
    in the way of productivity. As a build system it's fine, but as a
    day-to-day workstation, too much missing/broken stuff related
    to wayland's particulars, (such as missing screenshot features
    in gimp, which I need all the time, and the separate snapshot tool
    that does work is to work with)  and window manager limitations
    that need better solutions.

    Not too bad for a new from-the-ground-up windowing system,
    and a completely different paradigm from X11.

    Heck, for many many years X11 for Linux was buggy as hell,
    and went through a few different iterations before it settled
    on which implementation it is now. (Remember XFree86? %^/ )

[Gonzalo Garramuño]

On 4/12/2024 3:08 PM, Greg Ercolano wrote:

On 4/12/24 08:51, Gonzalo Garramuño wrote:

I guess Ubuntu 22.04.4 LTS is not new enough for FLTK 1.4.

    I'd say it's still experimental, mainly for developers to test on
    the most stable Wayland environment so far, I suppose.

    Heck, for many many years X11 for Linux was buggy as hell,
    and went through a few different iterations before it settled
    on which implementation it is now. (Remember XFree86? %^/ )

Well, the reason I am now on Wayland again is that the most recent unattended Ubuntu update broke Xorg and Gnome (they now suffer from slowdowns, particularly with my application's FLTK Tree widget linked to a Wizard).  It works fine on Xfce and XWayland thou.

-- 
Gonzalo Garramuño
ggar...@gmail.com

[GOUY MANOLO]

Fltk-Wayland is compatible with Ubuntu 20.0 and above. A recent ABI change in libdecor made Fltk incompatible with libdecor 0.2.2 as packaged, but compatible with the built-in libdecor. I will see if that can be improved.



> Le 12 avr. 2024 à 17:51, Gonzalo Garramuño <ggarra13@gmail..com> a écrit :
>
> 

> --
> You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/37bd249c-1b34-419a-a271-866c5a0717ea%40gmail.com.
>

[Manolo]

With FLTK commit e6957fc you should be able to use the system version of libdecor

both in FLTK and GLFW. This should fix the incompatibility you report.

[Gonzalo Garramuño]

It did not work.  I think you misunderstood.  I am on Ubuntu 22.04.4 LTS
which does not have a libdecor >= 0.2.0.

Also, I tried 15d9a350bf715357dec12810dcfe51ba8defbd5d and it choked
with a cmake error:

CMake Error at
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/install/share/fltk/FLTK-Targets.cmake:60
(set_target_properties):
  The link interface of target "fltk::fltk" contains:

    PkgConfig::PANGOCAIRO

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Call Stack (most recent call first):
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/install/share/fltk/FLTKConfig.cmake:39
(include)
  CMakeLists.txt:36 (find_package)


CMake Error at
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/install/share/fltk/FLTK-Targets.cmake:91
(set_target_properties):
  The link interface of target "fltk::fltk-shared" contains:

    PkgConfig::PANGOCAIRO

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Call Stack (most recent call first):
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/install/share/fltk/FLTKConfig.cmake:39
(include)
  CMakeLists.txt:36 (find_package)


--
Gonzalo Garramuño
ggar...@gmail.com

[Manolo]

Le jeudi 18 avril 2024 à 22:15:53 UTC+2, ggar...@gmail.com a écrit :

On 18/4/24 14:40, Manolo wrote:
> With FLTK commit e6957fc you should be able to use the system version
> of libdecor
> both in FLTK and GLFW. This should fix the incompatibility you report.
>
It did not work.  I think you misunderstood.  I am on Ubuntu 22.04.4 LTS
which does not have a libdecor >= 0.2.0.

OK. I had tried with Ubuntu 23.10 and its libdecor version 0.2.0.

FLTK is also compatible with libdecor 0.1.x. But this version does not contain the GTK libdecor plugin,

so I'm reluctent to make FLTK work with this early, outdated, system version of libdecor.

This would decorate all FLTK windows with a black titlebar, making FLTK windows

seem aliens on the desktop.

Would you have the possibility to install from source the last version of libdecor that

would land in /usr/local and bring with it the GTK plugin?

Also, I tried 15d9a350bf715357dec12810dcfe51ba8defbd5d and it choked
with a cmake error:

CMake Error at
/home/gga/code/applications/mrv2/BUILD-Linux-amd64/Release/install/share/fltk/FLTK-Targets.cmake:60
(set_target_properties):
  The link interface of target "fltk::fltk" contains:

    PkgConfig::PANGOCAIRO

  but the target was not found.  

I see this too when building a client program with CMake. This was broken by commit 5417ea5.
I have posted a comment asking for this to be repaired.

[Albrecht Schlosser]

This should be fixed by commit a9d3d3e3fbefc80278392a88c0a81a5bbb97eb51.

Thanks for reporting it, and sorry for the inconveniencies.

[Gonzalo Garramuño]

On 19/4/24 05:05, Manolo wrote:

Le jeudi 18 avril 2024 à 22:15:53 UTC+2, ggar...@gmail.com a écrit :

On 18/4/24 14:40, Manolo wrote:
> With FLTK commit e6957fc you should be able to use the system version
> of libdecor
> both in FLTK and GLFW. This should fix the incompatibility you report.
>
It did not work.  I think you misunderstood.  I am on Ubuntu 22.04.4 LTS
which does not have a libdecor >= 0.2.0.

OK. I had tried with Ubuntu 23.10 and its libdecor version 0.2.0.

FLTK is also compatible with libdecor 0.1.x. But this version does not contain the GTK libdecor plugin,

so I'm reluctent to make FLTK work with this early, outdated, system version of libdecor.

Would you have the possibility to install from source the last version of libdecor that

would land in /usr/local and bring with it the GTK plugin?

I compiled the latest libdecor and recompiled the latest branch of FLTK that Albrecht mentioned on this thread.
No warnings issued.  Not sure what's the the GTK plugin.

Note that the path to libdecor was not printed out (sorry to be a pain, Albrecht), but it said it was using the system one, so I expect it to be okay.

I have /usr/local/lib in my LD_LIBRARY_PATH.  Instead of a crash, my program started.

Note that glfw3 creates its wayland support on the fly with wayland-scanner (not sure how that works, thou), so maybe it is still picking the one in /usr/lib/x86_64-linux-gnu.

This would decorate all FLTK windows with a black titlebar, making FLTK windows

seem aliens on the desktop.

My program run, but I got something similar to that.  

       [app] Running on: Ubuntu 22.04.4 LTS
       [app] Desktop: ubuntu-wayland

FLTK's OpenGL window was messed up.  It would display white (and would slowly fade to it and display ghosting).   It would also not respect the matrix transformation it seemed, as I tried to pan around the main GL window.  The bottom window (the thumbnail timeline), which is created with GLFW would work okay, thou.

I am attaching a .png which I hope will go through.  Anyway, this was a test to see where I stand.  I will try again once the next Ubuntu LTS is released, but if you have ideas on how to fix it now, I am all ears.

-- 
Gonzalo Garramuño
ggar...@gmail.com

[Gonzalo Garramulo]

El 19/4/24 a las 15:51, 'Albrecht Schlosser' via fltk.coredev escribió:

>
> This should be fixed by commit a9d3d3e3fbefc80278392a88c0a81a5bbb97eb51.
>
> Thanks for reporting it, and sorry for the inconveniencies.

There's still a problem on Windows, with MSVC 2022 building a shared
build.  I get:

-- Looking for glXGetProcAddressARB - not found
CMake Error at src/CMakeLists.txt:933 (target_include_directories):
  Cannot specify include directories for target "fltk_gl-shared" which
is not
  built by this project.

-- Configuration Summary for FLTK 1.4.0 generated by CMake 3.29.0 --

--
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 4/20/24 01:08 Gonzalo Garramulo wrote:
> There's still a problem on Windows, with MSVC 2022 building a shared
> build.  I get:
>
> -- Looking for glXGetProcAddressARB - not found
> CMake Error at src/CMakeLists.txt:933 (target_include_directories):
>   Cannot specify include directories for target "fltk_gl-shared" which
> is not
>   built by this project.

Thanks for testing and reporting this, fixed by commit
d2bd3c62408945227bb13133ad6ce270851b4872.

It was very likely a copy-paste bug. I added the shared libs to
Windows/Visual Studio builds on GitHub CI so we should notice such bugs
earlier in the future.

[Gonzalo Garramulo]

El 19/4/24 a las 20:53, 'Albrecht Schlosser' via fltk.coredev escribió:

>
> Thanks for testing and reporting this, fixed by commit
> d2bd3c62408945227bb13133ad6ce270851b4872.
>
> It was very likely a copy-paste bug. I added the shared libs to
> Windows/Visual Studio builds on GitHub CI so we should notice such bugs
> earlier in the future.

Thanks, Albrecht.  You sleep less than I do!  Go to sleep my good man!

--
Gonzalo Garramuño
ggar...@gmail.com

[Manolo]

Le vendredi 19 avril 2024 à 22:50:25 UTC+2, ggar...@gmail.com a écrit :

I compiled the latest libdecor and recompiled the latest branch of FLTK that Albrecht mentioned on this thread.
No warnings issued.  Not sure what's the the GTK plugin.

Note that the path to libdecor was not printed out (sorry to be a pain, Albrecht), but it said it was using the system one, so I expect it to be okay.

I have /usr/local/lib in my LD_LIBRARY_PATH.  Instead of a crash, my program started.

Note that glfw3 creates its wayland support on the fly with wayland-scanner (not sure how that works, thou), so maybe it is still picking the one in /usr/lib/x86_64-linux-gnu.

You should be able to see what version of libdecor.so is used by your exe with command ldd.

 

This would decorate all FLTK windows with a black titlebar, making FLTK windows

seem aliens on the desktop.

My program run, but I got something similar to that.  

       [app] Running on: Ubuntu 22.04.4 LTS
       [app] Desktop: ubuntu-wayland

FLTK's OpenGL window was messed up.  It would display white (and would slowly fade to it and display ghosting).   It would also not respect the matrix transformation it seemed, as I tried to pan around the main GL window.  The bottom window (the thumbnail timeline), which is created with GLFW would work okay, thou.

I see no way that libdecor can mess up OpenGL drawing. Are you mixing headers and shared libs of distinct builds?

 

I am attaching a .png which I hope will go through.  Anyway, this was a test to see where I stand.  I will try again once the next Ubuntu LTS is released, but if you have ideas on how to fix it now, I am all ears.

libdecor is useful to create window titlebars, mostly with CSD wayland compositors, but also with SSD compositors because it does the negotiation with the compositor to ask it to draw titlebars.

Your png shows no titlebar. Is libdecor really working at all in your setup? How many top-level windows are there?

What wayland compositor do you use? If that's Ubuntu's default one, it's gnome's compositor called Mutter.

Or do you use the KDE desktop? In that case, titlebars are drawn by the compositor, not by libdecor because it's a SSD compositor.

This is what the GTK plugin produces:

This is what the cairo plugin, the only one available before version 0.2 of libdecor, produces:

[Manolo]

Commit 7ec6f96 has FLTK use its bundled copy of libdecor with symbols

prefixed by "fl_". With this, you should be able to mix FLTK and GLFW without

problem caused by libdecor.

[Gonzalo Garramuño]

On 4/20/2024 7:46 AM, Manolo wrote:

 

This would decorate all FLTK windows with a black titlebar, making FLTK windows

seem aliens on the desktop.

My program run, but I got something similar to that.  

       [app] Running on: Ubuntu 22.04.4 LTS
       [app] Desktop: ubuntu-wayland

FLTK's OpenGL window was messed up.  It would display white (and would slowly fade to it and display ghosting).   It would also not respect the matrix transformation it seemed, as I tried to pan around the main GL window.  The bottom window (the thumbnail timeline), which is created with GLFW would work okay, thou.

I see no way that libdecor can mess up OpenGL drawing. Are you mixing headers and shared libs of distinct builds?

 

I think it is an issue with FLTK's Wayland OpenGL implementation.  I clear the window, but don't set the alpha channel to 1 when I clear it.  I think that makes Wayland not clear the output.  I'll try a test later todat.

I am attaching a .png which I hope will go through.  Anyway, this was a test to see where I stand.  I will try again once the next Ubuntu LTS is released, but if you have ideas on how to fix it now, I am all ears.

libdecor is useful to create window titlebars, mostly with CSD wayland compositors, but also with SSD compositors because it does the negotiation with the compositor to ask it to draw titlebars.

Your png shows no titlebar. Is libdecor really working at all in your setup? How many top-level windows are there?

What wayland compositor do you use? If that's Ubuntu's default one, it's gnome's compositor called Mutter.

Sorry.  I used the default Ubuntu Wayland setup.  It showed a titlebar but the Ubuntu screen grabber did not save the title bar.  I had not checked the image.

I was getting the equivalent of the cairo titlebar, with a *BIG* font.

-- 
Gonzalo Garramuño
ggar...@gmail.com

[imm]

On Sat, 20 Apr 2024, 13:12 Gonzalo Garramuño wrote:

Sorry.  I used the default Ubuntu Wayland setup.  It showed a titlebar but the Ubuntu screen grabber did not save the title bar.  I had not checked the image.

Yeah, I think Wayland's security aspects can make screen shots challenging...

I was getting the equivalent of the cairo titlebar, with a *BIG* font.

OK, so that doesn't sound like the system decorator at all, that sounds like the fallback.

FWIW, the fallback Cairo decorator that's built-in to libdecor used to have (and possibly still does; TBH I haven't checked) a bug in how it was scaling the font it used, e.g. for the title bar.

I reported it a while back and exchanged a few messages with the Dev at the time, but I'm not sure if it's actually fixed in later releases; I never really followed it up... It's fixed in the libdecor I use, but that doesn't help in this case.

I don't even remember if it's fixed in fltk's libdecor.

--
Ian
From my Fairphone FP3
   

[Gonzalo Garramuño]

On 20/4/24 07:46, Manolo wrote:
> I see no way that libdecor can mess up OpenGL drawing. Are you mixing
> headers and shared libs of distinct builds?

No.  It is a bug, but not with libdecor.  The screen should be cleared,
but currently it isn't.

In my program, I call:

        float r = 0.F, g = 0.F, b = 0.F, a = 0.F;
        glViewport(0, 0, pixel_w(), pixel_h());
        glClearStencil(0);
        glClearColor(r, g, b, a);
        glClear(GL_COLOR_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);

The alpha channel is intentionally set as 0, so that transparency can be
grabbed properly.  On Wayland, under FLTK at least, this messes it up,
as it lets the background go through.  Setting the alpha to 1 fixes it,
but that screws up capturing the OpenGL transparency with a
glReadPixel() and similar.  Not sure if it is an FLTK problem or a
Wayland problem.  But it is a bug.


--
Gonzalo Garramuño
ggar...@gmail.com

[Gonzalo Garramuño]

I appreciate your effort, but I would probably suggest you revert that
change, or else you'll have to keep maintaining it on every new libdecor
release.

FLTK and GLFW are working fine together.

--
Gonzalo Garramuño
ggar...@gmail.com

[Gonzalo Garramuño]

On 20/4/24 07:46, Manolo wrote:

> You should be able to see what version of libdecor.so is used by your
> exe with command ldd.

It was using the system one.  I missed that meson installed libdecor not
in /usr/local/lib, but in /usr/local/lib/x86_64-linux-gnu.  The font is
smaller now, but still big.

I get this warning when starting my program:

Plugin "GTK3 plugin" uses conflicting symbol "png_free".

I think my PNG build is conflicting also with the one in the GTK3 plugin.

--------------------------

More info on the OpenGL "matrix" issue.  It is not an OpenGL matrix
issue, but an issue with the size of the OpenGL window, when forced to
resize.  I have two GL windows in a Tile, as you know since you had to
debug it on macOS's red flickering screen before.

When I click the "Edit" button, I call resize on the windows. This is
causing the OpenGL window to extend to the size of the Tile, not the
size of what I set it to.  Note: I am not using the latest Fl_Tile, but
a custom one modified that works fine under X11 but does not work fine
neither under XWayland nor Wayland itself.  I am attaching three
screenshots:

1) The original video with no Edit.
2) What Wayland (and XWayland) does with Edit, the main OpenGL window is
cropping incorrectly and resizing to the bottom of the tile.
3) What Wayland should be doing (ie. what X11 does).

--
Gonzalo Garramuño
ggar...@gmail.com

[Gonzalo Garramuño]

On 20/4/24 10:15, Gonzalo Garramuño wrote:
>
> On 20/4/24 07:46, Manolo wrote:
>> You should be able to see what version of libdecor.so is used by your
>> exe with command ldd.
>

I don't have a simple test yet for the Tile/Window issue on Wayland, but
you can try this 9min build of my program.

git clone https://github.com/ggarra13/mrv2.git
cd mrv2
git switch beta
./bin/runme_minimal.sh
./BUILD-Linux-amd64-minimal/Release/install/bin/mrv2.sh
tlRender/etc/SampleData/Seq/BART_2021-02-07.0001.jpg

The build on my 16-core machine takes 9 mins.  This will open a sequence
of frames.  Hitting on the Edit button at the top right corner of the
window should trigger the issue.

--
Gonzalo Garramuño
ggar...@gmail.com

[Gonzalo Garramuño]

On 20/4/24 10:46, Gonzalo Garramuño wrote:
>
> On 20/4/24 10:15, Gonzalo Garramuño wrote:
>>
>> On 20/4/24 07:46, Manolo wrote:
>>> You should be able to see what version of libdecor.so is used by
>>> your exe with command ldd.

I have a simple test for the inconsistent handling of alpha channel in
OpenGL in Wayland.  Not sure if it is a bug in FLTK or a misfeature of
Wayland.

See FLTK issue #957.

I also found the cause of the incorrect resizing of OpenGL windows. 
Again, another misfeature of Wayland.  It seems to not to resize the
window immediately after a resize like X11 does. Adding an Fl::check
solved it, albeit with some flickering.

--
Gonzalo Garramuño
ggar...@gmail.com

[Manolo]

Le samedi 20 avril 2024 à 15:11:40 UTC+2, ggar...@gmail.com a écrit :

On 20/4/24 08:43, Manolo wrote:
> Commit 7ec6f96 has FLTK use its bundled copy of libdecor with symbols
> prefixed by "fl_". With this, you should be able to mix FLTK and GLFW
> without
> problem caused by libdecor.

I appreciate your effort, but I would probably suggest you revert that
change, or else you'll have to keep maintaining it on every new libdecor
release.

I don't think so. There's no change whatsoever to the libdecor source code.

FLTK and GLFW are working fine together.

They should work together even better with the change.

 

[Gonzalo Garramuño]

On 20/4/24 14:40, Manolo wrote:

FLTK and GLFW are working fine together.

They should work together even better with the change.

 

You are absolutely right!  It removed the Plugin "GTK-whatever" png_free conflict.

Now, if you could take a look at FLTK issue #957, to see if it is an FLTK OpenGL Wayland bug or actual "feature" of Wayland, we would be able to close this issue for good.

-- 
Gonzalo Garramuño
ggar...@gmail.com

[Manolo]

Le dimanche 21 avril 2024 à 01:22:11 UTC+2, ggar...@gmail.com a écrit :

On 20/4/24 14:40, Manolo wrote:

FLTK and GLFW are working fine together.

They should work together even better with the change.

 

You are absolutely right!  It removed the Plugin "GTK-whatever" png_free conflict.

Could you, please, tell me what type of titlebar you get for your FLTK windows

and your GLWF window with the last version of FLTK?

Now, if you could take a look at FLTK issue #957, to see if it is an FLTK OpenGL Wayland bug or actual "feature" of Wayland, we would be able to close this issue for good.

I don't know OpenGL so can't act on this issue.

[Gonzalo Garramuño]

On 21/4/24 08:00, Manolo wrote:

You are absolutely right!  It removed the Plugin "GTK-whatever" png_free conflict.

Could you, please, tell me what type of titlebar you get for your FLTK windows

and your GLWF window with the last version of FLTK?

I am getting the GTK3 Gnome one now that it does not fail on the png error.  Previously, I was getting the fallback with big characters.  Thanks!

Now, if you could take a look at FLTK issue #957, to see if it is an FLTK OpenGL Wayland bug or actual "feature" of Wayland, we would be able to close this issue for good.

I don't know OpenGL so can't act on this issue.

It is not an OpenGL issue.  It is a Wayland issue.  See what Gemini had to say about how to solve it (at least for gnome) in Issue #957.

-- 
Gonzalo Garramuño
ggar...@gmail.com