bugGNU Octave - Bugs: bug #65251, Octave needs Xwayland for...

 
 

bug #65251: Octave needs Xwayland for launching despite being a native Wayland application

Submitter:  itshog <itshog>
Submitted:  Sun 04 Feb 2024 11:59:32 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  In Progress Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * 8.4.0 Release: 
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  11.1.0 (current default)
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 26 Jun 2025 04:12:49 PM UTC, comment #44: 

All thes exercises in Wayland programming looks completely superficial. The "cdisplay.c" is just a bootstrap, the toolkits can figure out by themselves all the necessary information.
So the minaimal change like that:

diff -r 1e68534278cb libinterp/corefcn/cdisplay.c
--- a/libinterp/corefcn/cdisplay.c      Wed Jun 25 14:31:34 2025 +0200
+++ b/libinterp/corefcn/cdisplay.c      Thu Jun 26 12:01:15 2025 -0400
@@ -35,6 +35,8 @@
 #include <Carbon/Carbon.h>
 #elif defined (HAVE_X_WINDOWS)
 #include <X11/Xlib.h>
+#elif defined (HAVE_WAYLAND_CLIENT)
+#include <wayland-client.h>
 #endif

 #include "cdisplay.h"
@@ -129,6 +131,26 @@
   else
     msg = "no graphical display found";

+#elif defined (HAVE_WAYLAND_CLIENT)
+
+  // Check for Wayland display
+  struct wl_display *display = wl_display_connect(NULL);
+  if (display)
+    {
+      // Default to reasonable values for Wayland
+      *dp = 32;  // Most (all?) Wayland compositors have 32-bit depth
+      *ht = 4320;  // Default to 8K resolution for now
+      *wd = 7680;
+      *rx = 96;
+      *ry = 96;
+      *dpy_avail = 1;
+      // Clean up
+      wl_display_disconnect(display);
+      octave_unused_parameter (dpy_name);
+    }
+  else
+    msg = "no Wayland display available";
+
 #elif defined (HAVE_X_WINDOWS)

   /* If dpy_name is NULL, XopenDisplay will look for DISPLAY in the
@@ -161,7 +183,6 @@
     }
   else
     msg = "unable to open X11 DISPLAY";
-
 #else

   octave_unused_parameter (dpy_name);

is sufficient. (I suspect the entire file can be simplified this way.) At least it works for me.

The complete diff (file wayland_min.diff) is attached.

Dmitri.
--


(file #57331)

Dmitri A. Sergatskov <dasergatskov>
Wed 02 Apr 2025 10:57:13 AM UTC, comment #43: 

I think we should also change fallback values for dpi to 72 to be consistent with the rest of the code. e.g. in "display.h":

 // Create object with default values.  To be useful, you must call
  // initialize to find the actual system parameters for the given
  // display.

  display_info ()
    : m_rx (72), m_ry (72), m_ht (1), m_wd (1), m_dp (0),
      m_dpy_avail (false), m_msg ()
  { }


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 02 Apr 2025 06:05:31 AM UTC, comment #42: 

Compiling with "clang":

../libinterp/corefcn/cdisplay.c:75:61: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions]
   75 | oct_wl_geometry (void *data, struct wl_output * /* output */, int /* x */,
      |                                                             ^
../libinterp/corefcn/cdisplay.c:75:74: warning: omitting the parameter name in a function definition is a C23 extension [-Wc23-extensions]
   75 | oct_wl_geometry (void *data, struct wl_output * /* output */, int /* x */,


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 02 Apr 2025 05:34:01 AM UTC, comment #41: 

OK, may be t is easier to start with your patch and get it to work.
I had to make few small changes:

          // add output listener
           wl_registry_add_listener (registry, &registry_listener, &info);
           // process display events
+          // First roundtrip to get registry events
           wl_display_roundtrip (display);
+          // Second roundtrip to get output events
+          wl_display_roundtrip (display);
+
           // disconnect display
           wl_display_disconnect (display);

           if (info.avail)
             {
-              *dp = info.dp;
-
+              // Set default depth for Wayland displays (typically 32 bits)
+              *dp = 32;
+


I think adding second roundtrip was the essential change
(though  *dp = 32; looks important too)

"make check" passes.


octave:1> have_window_system
ans = 1
octave:2> get(0,"ScreenPixelsPerInch")
ans = 94.517
octave:3> get(0,"ScreenSize")
ans =

      1      1   1920   1200

octave:4> get(0,"MonitorPosition")
warning: get: allowing MonitorPosition to match root property monitorpositions
ans =

      1      1   1920   1200

octave:5> get(0, 'ScreenDepth')
ans = 32
octave:6> available_graphics_toolkits
ans =
{
  [1,1] = fltk
  [1,2] = gnuplot
  [1,3] = qt
}

octave:7> __octave_config_info__ ("config_opts")
ans =  'CXX=g++ -std=gnu++17' 'CFLAGS=-g3 -O3 -march=native -flto=auto' 'CXXFLAGS=-g3 -O3 -march=native -flto=auto' 'FFLAGS=-g3 -O3 -march=native -flto=auto' '--with-blas=flexiblas' '--disable-std-pmr-polymorphic-allocator' '--without-x'


Rebuild doc/ -- OK
dump_plot_demos -- OK

As far as I am concern, it is a good candidate.

Dmitri.
--
 

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 01 Apr 2025 05:28:10 PM UTC, comment #40: 


> Do we want X11 with Win32 or Apple?


Currently, X11 isn't used when the Windows API or the Carbon framework is used.
If you'd like to change that (I don't know if that makes sense), you could do that in a separate patch.

Markus Mützel <mmuetzel>
Group administrator
Tue 01 Apr 2025 11:20:00 AM UTC, comment #39: 

The main reference is probably this one:

https://wayland-book.com/introduction.html

About HiDPI:
https://wayland-book.com/surfaces-in-depth/hidpi.html
<<<
Note that this was added in version 2, so when binding to the wl_output global you must set the version to at least 2 to receive these events.

>>>


The code from
https://github.com/eklitzke/wlinfo
was very helpful for me.

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Tue 01 Apr 2025 11:06:36 AM UTC, comment #38: 

It was a pain to find all this info about WL_
(and some links already gone bad).
I am pretty sure you need level 2 to get HiDPI scaling info.
Since we are not using it at the moment we probably can use 1, but on my computer it is at 4, so I guess 2 should be fairly safe.

I have a conflicting thought about cdisplay.c From one hand I want to keep it as simple as possible, from the other hand I thought once I figure out something, well may be we could use it later. Somehow I did not see any warnings.

I guess technically X11 can go with anything and certainly with Wayland. Do we want X11 with Win32 or Apple?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 01 Apr 2025 10:25:07 AM UTC, comment #37: 


> It would be nice to add those VARs into "__octave_config_info__".


If you'd like to do that, it should definitely go into a separate patch.

Markus Mützel <mmuetzel>
Group administrator
Tue 01 Apr 2025 10:22:34 AM UTC, comment #36: 

Apart from the change to configure.ac, you should also take this change from the older patch:

diff --git a/libinterp/corefcn/module.mk b/libinterp/corefcn/module.mk
--- a/libinterp/corefcn/module.mk
+++ b/libinterp/corefcn/module.mk
@@ -343,6 +343,7 @@ noinst_LTLIBRARIES += \
   $(FT2_CPPFLAGS) \
   $(HDF5_CPPFLAGS) \
   $(SPARSE_XCPPFLAGS) \
+  $(WAYLAND_CLIENT_CPPFLAGS) \
   $(Z_CPPFLAGS) \
   $(OCTAVE_TEX_PARSER_CPPFLAGS)


Markus Mützel <mmuetzel>
Group administrator
Tue 01 Apr 2025 10:20:42 AM UTC, comment #35: 

Thank you very much for looking into this.

Some initial remarks on your patch (didn't try to apply it yet):

  • In some parts of your patch, it looks like you are trying to support linking to both the Wayland client and the X libraries. E.g., the inclusion rules for the headers and some comments in the implementation suggest that X11 should be used as a fallback if Wayland fails. But then, the implementation for `HAVE_X_WINDOWS` isn't compiled if `HAVE_WAYLAND_CLIENT` is defined.
  • The X11 header should probably not be included if the Windows API or the Carbon framework are used (even if X11 header might be available).
  • In line 107 of your patch, you are calling `wl_registry_bind` with version set to 2. Most examples that I found when googling for that, set the version to 1. Should the input argument `version` be passed to that function instead? Does it still work for you with that change?
  • I didn't compile with your patch yet. (I didn't set up Wayland.) But it looks like it would generate a lot of "unused input argument" warnings. Could you remove (or comment) unused arguments from the function definitions? (See, e.g., file #56925.)
  • Some nit: There are missing whitespace after the negation operator. We usually don't use {}-blocks for if or else branches if they consist of only one assignment. There are trailing whitespace in some lines.



I don't know much about Wayland. Can it be used in parallel with X11? Does it make sense to use X11 as a fallback for Wayland (or vice-versa)? Or should they strictly be alternatives?



Markus Mützel <mmuetzel>
Group administrator
Tue 01 Apr 2025 10:14:00 AM UTC, comment #34: 

It would be nice to add those VARs into "__octave_config_info__".
I figure one needs to edit "toplevel.cc", but not sure about
"build-env.h" and "build-env.in.cc" those look autogenerated to me.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 01 Apr 2025 09:32:02 AM UTC, comment #33: 

Thanks.

diff -r a5354a47dd24 configure.ac
--- a/configure.ac      Mon Mar 31 19:33:33 2025 -0700
+++ b/configure.ac      Tue Apr 01 05:30:32 2025 -0400
@@ -3060,9 +3060,9 @@
 AC_SUBST(LIBOCTAVE_LINK_DEPS)
 AC_SUBST(LIBOCTAVE_LINK_OPTS)

-LIBOCTINTERP_LINK_DEPS="$FT2_LIBS $HDF5_LIBS $MAGICK_LIBS $Z_LIBS $SPARSE_XLIBS $FFTW_XLIBS $OPENGL_LIBS $FONTCONFIG_LIBS $FREETYPE_LIBS $X11_LIBS $CARBON_LIBS $GL2PS_LIBS $JAVA_LIBS $LAPACK_LIBS"
-
-LIBOCTINTERP_LINK_OPTS="$FT2_LDFLAGS $HDF5_LDFLAGS $MAGICK_LDFLAGS $Z_LDFLAGS $SPARSE_XLDFLAGS $FFTW_XLDFLAGS"
+LIBOCTINTERP_LINK_DEPS="$FT2_LIBS $HDF5_LIBS $MAGICK_LIBS $Z_LIBS $SPARSE_XLIBS $FFTW_XLIBS $OPENGL_LIBS $FONTCONFIG_LIBS $FREETYPE_LIBS $WAYLAND_CLIENT_LIBS $X11_LIBS $CARBON_LIBS $GL2PS_LIBS $JAVA_LIBS $LAPACK_LIBS"
+
+LIBOCTINTERP_LINK_OPTS="$FT2_LDFLAGS $HDF5_LDFLAGS $MAGICK_LDFLAGS $WAYLAND_CLIENT_LDFLAGS $Z_LDFLAGS $SPARSE_XLDFLAGS $FFTW_XLDFLAGS"

 OCTAVE_LINK_DEPS=""
 OCTAVE_LINK_OPTS=""


did it for me.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 01 Apr 2025 07:02:37 AM UTC, comment #32: 


> I had run make as "make -j32 LIBS="-lwayland-client""

because "cdisplay.c" now needs to be linked with "-lwayland-client" and I do not know how to modify build system to do this properly. Any help with this would be appreciated.

You could probably use the respective changes to the build system from file #56925.

Markus Mützel <mmuetzel>
Group administrator
Mon 31 Mar 2025 10:42:17 PM UTC, comment #31: 

With the attached diff (file wayland_cdisplay.diff) on 8bca4868bb21+ tip @ I see:

octave:1> __octave_config_info__ ("config_opts")
ans =  'CXX=g++ -std=gnu++17' 'CFLAGS=-g3 -O3 -march=native -flto=auto' 'CXXFLAGS=-g3 -O3 -march=native -flto=auto' 'FFLAGS=-g3 -O3 -march=native -flto=auto' '--with-blas=flexiblas' '--disable-std-pmr-polymorphic-allocator' '--without-x' 'LIBS=-ljemalloc'
octave:2> have_window_system
ans = 1
octave:3> get(0, 'ScreenSize')
ans =

      1      1   2560   1440

octave:4> get(0, 'ScreenPixelsPerInch')
ans = 109.60
octave:5> get(0, 'ScreenDepth')
ans = 32
octave:6> get(0, 'MonitorPosition')
warning: get: allowing MonitorPosition to match root property monitorpositions
ans =

      1      1   2560   1440

octave:7> available_graphics_toolkits
ans =
{
  [1,1] = fltk
  [1,2] = gnuplot
  [1,3] = qt
}

octave:8>


I can build docs and run through "dump_plot_demos" with both png and pdf outputs.
I had run make as "make -j32 LIBS="-lwayland-client""
because "cdisplay.c" now needs to be linked with "-lwayland-client" and I do not know how to modify build system to do this properly. Any help with this would be appreciated.

Dmitri.
--


(file #57088)

Dmitri A. Sergatskov <dasergatskov>
Fri 21 Feb 2025 04:47:26 AM UTC, comment #30: 

The attached standalone program "cdisplay-test.c" works for me:

$ gcc -Wall -DHAVE_WAYLAND -lwayland-client cdisplay-test.c
$ ./a.out
Querying display information...
Using default display
Wayland support: YES
X11 support: NO
Windows API support: NO
Carbon framework support: NO

Connected to Wayland display
Found output interface (version 4)
Wayland Output:
  Position: x=0, y=0
  Physical size: 520x320 mm
  Make: NEC
  Model: EA241WM
  Current mode: 1920x1200@59Hz
  Scale factor: 1

Display Parameters:
  Resolution: 1920 x 1200 pixels
  Color depth: 32 bits
  DPI: 93.8 x 95.2


But the "cdisplay.c" (attached), when used in octave, does not.
It compiles if I set -DHAVE_WAYLAND (to CFLAGS), but results are still
nonsensical.
 
Dmitri.
--


(file #56933, file #56934)

Dmitri A. Sergatskov <dasergatskov>
Wed 19 Feb 2025 11:42:36 PM UTC, comment #29: 


comment #28:

>
> So there is some discrepancy: 95.925 vs 89.3.
> Official spec is 0.27mm pitch (i.e. 25.4/0.27 = 94.1 dpi?)
>


The code to calculate DPI is  somewhat strange.
More straightforward:

octave:5> 25.4*1920/520
ans = 93.785
octave:6> 25.4*1200/320
ans = 95.250

seems to be more reasonable.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 19 Feb 2025 10:53:54 PM UTC, comment #28: 

Corrections:

octave:6> get(0, 'ScreenPixelsPerInch')
ans = 95.925


So there is some discrepancy: 95.925 vs 89.3.
Official spec is 0.27mm pitch (i.e. 25.4/0.27 = 94.1 dpi?)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 19 Feb 2025 10:24:57 PM UTC, comment #27: 

I also checked what octave 10 returns (running on Wayland+Xwayland):


octave:1> get(0, 'ScreenSize')
ans =

      1      1   1920   1200

octave:2> get(0, 'ScreenPixelPerInch')
error: get: unknown root property ScreenPixelPerInch
octave:3> get(0, 'ScreenDepth')
ans = 24
octave:4> get(0, 'MonitorPosition')
warning: get: allowing MonitorPosition to match root property monitorpositions
ans =

      1      1   1920   1200

octave:5> version -hgid
ans = 83b7dddac9b3


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 19 Feb 2025 07:30:22 PM UTC, comment #26: 

No crash with modified wlinfo.c (diff is attached)

$ ./wlinfo
output 4
---------
x: 0
y: 0
physical_width: 520
physical_height: 320
subpixel: 0
make: NEC
model: EA241WM
width: 1920
height: 1200
dpi: 89.3
scale: 1
name: DP-3
description: NEC Corporation 24"


Dmitri.
--

(file #56926)

Dmitri A. Sergatskov <dasergatskov>
Wed 19 Feb 2025 07:01:29 PM UTC, comment #25: 

I tried
https://github.com/eklitzke/wlinfo
and it mostly works:

$ lddtree ./wlinfo
wlinfo => ./wlinfo (interpreter => /lib64/ld-linux-x86-64.so.2)
    libwayland-client.so.0 => /lib64/libwayland-client.so.0
        libffi.so.8 => /lib64/libffi.so.8
    libc.so.6 => /lib64/libc.so.6
        ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2



$ ./wlinfo
output 4
---------
x: 0
y: 0
physical_width: 520
physical_height: 320
subpixel: 0
make: NEC
model: EA241WM
width: 1920
height: 1200
dpi: 89.3
scale: 1
listener function for opcode 4 of wl_output is NULL
Aborted (core dumped)


The info is correct, but error at the end is unfortunate.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 19 Feb 2025 06:20:25 PM UTC, comment #24: 

Nothing works.

octave:9> have_window_system
ans = 0
octave:10> get(0, 'MonitorPosition')
warning: get: allowing MonitorPosition to match root property monitorpositions
ans =

   1   1   1   1

octave:11> get(0, 'ScreenDepth')
ans = 0
octave:12> get(0, 'ScreenPixelPerInch')
error: get: unknown root property ScreenPixelPerInch
octave:13> get(0, 'ScreenSize')
ans =

   1   1   1   1


I was googling how to get this info on misc display systems and it is all more complicated than it should be. :)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 19 Feb 2025 05:49:56 PM UTC, comment #23: 

The attached patch attempts to gather the information of the display from Wayland.
I haven't tested much more than whether Octave still builds when that patch is applied.

I'm suspecting that apart from `have_window_system` returning false, information that corresponds to the default screen isn't available for `--without-x`. E.g.,

get(0, 'MonitorPosition')
get(0, 'ScreenDepth')
get(0, 'ScreenPixelPerInch')
get(0, 'ScreenSize')


Is that true?

Do these root graphics properties show sane information with the patch? Does `have_window_system` return true?


(file #56925)

Markus Mützel <mmuetzel>
Group administrator
Wed 19 Feb 2025 04:08:06 PM UTC, comment #22: 


> It returns "0".


That's an issue. And it would probably be fixed by adding a Wayland implementation for `octave_get_display_info` in `cdisplay.c`.


In the meantime, I pushed the following change to show the value of the Wayland client flags in the configure summary:
https://hg.savannah.gnu.org/hgweb/octave/rev/ad0acc072ceb

Markus Mützel <mmuetzel>
Group administrator
Wed 19 Feb 2025 03:56:21 PM UTC, comment #21: 

It returns "0".

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 19 Feb 2025 03:50:18 PM UTC, comment #20: 


> Not sure where all this info is used. I have been using octave 11 compiled with "--without-x" and not found any obvious problem.


What does `have_window_system` return for you for that configuration?

Markus Mützel <mmuetzel>
Group administrator
Wed 19 Feb 2025 03:11:39 PM UTC, comment #19: 


> Also -- should the Apple section be updated to use Cocoa?


This report is about using Wayland (potentially in place of X11).
If you think that something needs to change for Apple, please open a separate report (if none exists yet).
(Someone else would need to look at that. I don't have any Apple device.)

Markus Mützel <mmuetzel>
Group administrator
Wed 19 Feb 2025 03:06:51 PM UTC, comment #18: 


> I also missed that jwe already pointed out that we'll need a Wayland implementation for `octave_get_display_info` in `cdisplay.c`.
>


Not sure where all this info is used. I have been using octave 11 compiled with "--without-x" and not found any obvious problem.
Also -- should the Apple section be updated to use Cocoa?

I do not think either Qt or FLTK use Carbon.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 19 Feb 2025 09:49:59 AM UTC, comment #17: 

I agree that displaying the new flags in the configure summary might be useful.
I also missed that jwe already pointed out that we'll need a Wayland implementation for `octave_get_display_info` in `cdisplay.c`.

Reverting status to "In Progress".

Markus Mützel <mmuetzel>
Group administrator
Mon 17 Feb 2025 02:10:55 PM UTC, comment #16: 

May be add some (all?) WAYLAND flags to the configure status printout?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 16 Feb 2025 12:36:55 PM UTC, comment #15: 

I vote to push it to stable.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 16 Feb 2025 11:38:47 AM UTC, comment #14: 

Thank you for testing.

This changes a part of the build rules that is used extensively.
Also, I'm not interested personally in testing if this works in detail. I'm also not sure if there is potential that this breaks existing use cases.

All in all, I don't feel confident enough about this change to apply it on the stable branch directly.
I pushed them to the default branch instead:
https://hg.savannah.gnu.org/hgweb/octave/rev/6e4d2c812619
https://hg.savannah.gnu.org/hgweb/octave/rev/0d61e5951a3a

If it turns out that these changes break anything, we can revert them or try to fix them in follow-ups.
On the other hand, if we feel confident that this is more useful than risky, the changes could still be grafted to the stable branch.

Markus Mützel <mmuetzel>
Group administrator
Sat 15 Feb 2025 11:36:02 PM UTC, comment #13: 

Sorry -- I guess it was some mistake on my part. With a clean bootstrap/configure/build it  now works (with ./configure --without-x):


$ DISPLAY='' ./run-octave
GNU Octave, version 10.0.1
Copyright (C) 1993-2025 The Octave Project Developers.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-pc-linux-gnu".

Home page:            https://octave.org
Support resources:    https://octave.org/support
Improve Octave:       https://octave.org/get-involved

For changes from previous versions, type 'news'.

octave:1> plot(rand(3))
octave:2> __octave_config_info__ ("WAYLAND_CLIENT")
ans = 1
octave:3> __octave_config_info__ ("X_WINDOWS")
ans = 0


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 15 Feb 2025 07:36:47 PM UTC, comment #12: 

I tried to build with those patches and "../configure --without-x".
Configure finds and adds Qt and FLTK libraries (and no X11 libs/includes).
I thought that fltk can be wayland only with 1.4.x versions (I have 1.3.8).
Anyway on startup I see:

$ ./run-octave
octave: no graphical display found
octave: disabling GUI features
GNU Octave, version 10.0.1
Copyright (C) 1993-2025 The Octave Project Developers.
...


If I configure with default flags, then:

$ DISPLAY='' ./run-octave
octave: X11 DISPLAY environment variable not set
octave: disabling GUI features
GNU Octave, version 10.0.1
...


In my environment I see:

$ set | grep -i display
DISPLAY=:0
GNOME_SETUP_DISPLAY=:1
WAYLAND_DISPLAY=wayland-0
$ set | grep -i wayland
WAYLAND_DISPLAY=wayland-0
XAUTHORITY=/run/user/1001/.mutter-Xwaylandauth.AHCH22
XDG_SESSION_TYPE=wayland


This is on Centos Stream 10 which does not have Xorg server at all.
To change On Ubuntu (or Fedora) - there should be a "cog-wheel"
icon on right-bottom corner of the login screen which should allow you to chose your session to be on Xorg (or default --> Wayland). If you do not see this cog-wheel, then you may need to change (enable Wayland) in "/etc/gdm3/custom.conf" (? typing from memory).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 15 Feb 2025 05:40:27 PM UTC, comment #11: 

Oops. Forgot to set `dpy_avail` on success with Wayland.
See the updated patch that replaces the second patch from the previous comment.


(file #56902)

Markus Mützel <mmuetzel>
Group administrator
Sat 15 Feb 2025 05:23:47 PM UTC, comment #10: 

We could probably try to connect to a Wayland display and check if that succeeds. For that, we could maybe use `wl_display_connect` from the `wayland-client` library.

Trying to implement that, first was stalled by the fact that our OCTAVE_CHECK_LIB m4 function doesn't work for libraries that contain "-".
The first attached patch should be generalizing OCTAVE_CHECK_LIB to be able to deal with that.

The second patch adds the actual check (on top of the first patch).
I'm using Ubuntu with X11. So, I can't tell if the test actually works.
(I had issues with Wayland in the past and switched my user session to X11 when Ubuntu started to use Wayland by default.
I don't recall which issues those were. And I didn't bother to check how to switch back to Wayland again now.)


(file #56900, file #56901)

Markus Mützel <mmuetzel>
Group administrator
Sat 15 Feb 2025 03:19:01 PM UTC, comment #9: 

Sorry, I can not give any helpful insights here. The link in comment #5 regarding the file display-available.c links to a changeset pushed by me but this changeset does not include any changes in display-available.c. The changeset that added this file in this chageset:

https://hg.savannah.gnu.org/hgweb/octave/rev/299fe39163a2

Later changes only affected formatting or copyright information.

Torsten Lilge <ttl>
Group Member
Sat 15 Feb 2025 05:44:37 AM UTC, comment #8: 

Could we revisit this for release 10?
May be Torsten can comment (if somebody can Cc to him).
Currently it possible to compie octave on linux '--without-x'
and ir would link all the Qt and GL libraries in, but will not start any gui.

How does it work on MacOS. There is no DISPLAY or anything
with CARBON in the environment, yet gui starts just fine.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 10 Sep 2024 12:31:52 PM UTC, comment #7: 

I was trying to run GNU Octave [ version 9.2.0 ] on my system. Xwayland is disabled. I have GNU Octave installed as a flatpak. When I try to run in terminal I get following output :

bash-5.2$ flatpak run org.octave.Octave
octave: X11 DISPLAY environment variable not set
octave: disabling GUI features
GNU Octave, version 9.2.0
Copyright (C) 1993-2024 The Octave Project Developers.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-pc-linux-gnu".

Home page:            https://octave.org
Support resources:    https://octave.org/support
Improve Octave:       https://octave.org/get-involved

For changes from previous versions, type 'news'.

octave:1>

Anonymous
Sun 04 Feb 2024 05:17:13 PM UTC, comment #6: 

comment #5:

> In the old days, a reasonable way to do that on a Unix-like system was to check whether the DISPLAY environment variable was set.
>

Could Octave perform the same check with the WAYLAND_DISPLAY environment variable? Then, instead of trying to open the X11 display it should try to connect to the wayland compositor in use, or do whatever the wayland equivalent of "trying to open the display" is.

itshog <itshog>
Sun 04 Feb 2024 05:05:22 PM UTC, comment #5: 

When Octave starts, it tries to determine whether there is a graphical display available.  If there is, it attempts to open the graphical user interface.  Otherwise, it attempts to open a command-line interface in a terminal.

In the old days, a reasonable way to do that on a Unix-like system was to check whether the DISPLAY environment variable was set.

The code is here:  http://hg.savannah.gnu.org/hgweb/octave/file/4b99c92fc2b2/src/display-available.c

There are currently three separate ways we attempt to detect whether a graphical display is available.  The code path to use is selected by the configuration variables OCTAVE_USE_WINDOWS_API, HAVE_FRAMEWORK_CARBON, and HAVE_X_WINDOWS.  If we need another special case for Wayland, what should the code be and how do we detect that case?

See also

http://hg.savannah.gnu.org/hgweb/octave/file/4b99c92fc2b2/libinterp/corefcn/cdisplay.c

http://hg.savannah.gnu.org/hgweb/octave/file/4b99c92fc2b2/configure.ac#l1784

http://hg.savannah.gnu.org/hgweb/octave/file/4b99c92fc2b2/configure.ac#l1804

http://hg.savannah.gnu.org/hgweb/octave/file/4b99c92fc2b2/oct-conf-post-private.in.h#l54



John W. Eaton <jwe>
Group administrator
Sun 04 Feb 2024 04:46:47 PM UTC, comment #4: 

comment #3:

> What do you mean by "latest source"? Does building Octave 9 (from the "stable" branch) work?
> How did you configure Octave?
> Did you build the GUI against Qt6? Does it open (ignoring the failing test)?


These are the commands I used to build Octave:

hg clone https://hg.octave.org/octave
cd octave
hg update stable
./bootstrap
mkdir .build && cd .build
./../configure --prefix=$HOME/my_octave
make -j$(nproc)
make check
make install

Anyway, ignoring the tests, when I run

./run-octave --gui

from the .build directory I get the same behaviour that I reported before: despite being a native wayland application, the Octave GUI (even when built with qt6) refuses to open if Xwayland is not available.

itshog <itshog>
Sun 04 Feb 2024 03:36:42 PM UTC, comment #3: 

What do you mean by "latest source"? Does building Octave 9 (from the "stable" branch) work?
How did you configure Octave?
Did you build the GUI against Qt6? Does it open (ignoring the failing test)?

Markus Mützel <mmuetzel>
Group administrator
Sun 04 Feb 2024 03:08:07 PM UTC, comment #2: 

comment #1:

> Is this still an issue if you build Octave 9 with Qt6?
>


I'm currently unable to build from latest source on Arch Linux. When running "make test" following the instructions here it segfaults at "libinterp/octave-value/ov-class.cc-tst".

Also, I got two warning during compilation about "libGraphicsMagick++.la" and "libGraphicsMagick.la" being moved.

itshog <itshog>
Sun 04 Feb 2024 01:44:51 PM UTC, comment #1: 

Is this still an issue if you build Octave 9 with Qt6?

Markus Mützel <mmuetzel>
Group administrator
Sun 04 Feb 2024 11:59:32 AM UTC, original submission:  

Trying to launch the GUI in an environment without Xwayland results in the following warnings:


octave: X11 DISPLAY environment variable not set
octave: disabling GUI features


After the warnings the CLI version is launched instead.

When Xwayland is available but not running (for instance, when using Sway with "xwayland enable" in the configuration file, which automatically launches Xwayland when an application needs it) the GUI launches normally as a native wayland window, and after a few seconds the Xwayland process is automatically terminated. So, if I understand correctly, Octave doesn't actually need Xwayland for running, and only makes use of it during the startup phase: would it be possible to remove this dependency on Xwayland, making it possible to use Octave in pure wayland environments?

itshog <itshog>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #57331:  wayland_min.diff added by dasergatskov (2KiB - text/x-patch)
file #57088:  wayland_cdisplay.diff added by dasergatskov (6KiB - text/x-patch)
file #56933:  cdisplay-test.c added by dasergatskov (10KiB - text/x-csrc)
file #56934:  cdisplay.c added by dasergatskov (8KiB - text/x-csrc)
file #56926:  wlinfo.diff.gz added by dasergatskov (548B - application/gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by itshog (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-06-26 dasergatskov Attached File- Added wayland_min.diff, #57331
    2025-03-31 dasergatskov Attached File- Added wayland_cdisplay.diff, #57088
    2025-02-21 dasergatskov Attached File- Added cdisplay-test.c, #56933
        Attached File- Added cdisplay.c, #56934
    2025-02-19 dasergatskov Attached File- Added wlinfo.diff.gz, #56926
    2025-02-19 mmuetzel Attached File- Added bug65251-wayland-display-info.patch, #56925
    2025-02-19 mmuetzel StatusReady For Test In Progress
    2025-02-16 mmuetzel StatusPatch Submitted Ready For Test
        Planned ReleaseNone 11.1.0 (current default)
    2025-02-15 mmuetzel Attached File- Added bug65251-wayland-display-v2.patch, #56902
    2025-02-15 mmuetzel Attached File- Added build-check-library-with--.patch, #56900
        Attached File- Added bug65251-wayland-display.patch, #56901
        StatusNeed Info Patch Submitted
    2024-02-04 mmuetzel StatusNone Need Info

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code