bugGNU Octave - Bugs: bug #51442, graphics_toolkit qt does not work...

 
 

bug #51442: graphics_toolkit qt does not work with Qt 5 in Xwayland and Intel mesa driver

Submitter:  None
Submitted:  Tue 11 Jul 2017 02:46:57 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Harish Hyma Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 4.2.1
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 21 Oct 2017 06:34:56 PM UTC, comment #30: 

I filed bug #52260 for the issue I am seeing.

Markus Mützel <mmuetzel>
Group administrator
Sat 21 Oct 2017 06:19:24 PM UTC, comment #29: 

I think you should file a new bug report about the upside-down axes glitch. This bug was specifically about running Octave in a wayland environment. When I ran in an x11 environment everything was fine.

Yes, you are using QOpenGLWidget. If your Qt provides both, QOpenGLWidget is preferred.

Mike Miller <mtmiller>
Group Member
Sat 21 Oct 2017 05:14:44 PM UTC, comment #28: 

I am using Ubuntu 17.10 on an x11 session with Qt5 version 5.9.1.
In the config.h, I see the following:

/* Define to 1 if you have the <QGLWidget> header file. */
#define HAVE_QGLWIDGET 1
 [snip]
/* Define to 1 if you have the <QOpenGLWidget> header file. */
#define HAVE_QOPENGLWIDGET 1


Does that mean I am using QOpenGLWidget?

Markus Mützel <mmuetzel>
Group administrator
Wed 18 Oct 2017 05:39:47 PM UTC, comment #27: 

Since 59cdf06c940e this has been fixed completely for me.

Markus - I don't see the upside-down axes that you show in your screenshot. Which version of Qt 5 do you have? Is your build using QGLWidget or QOpenGLWidget? Are you running in a wayland environment?

Mike Miller <mtmiller>
Group Member
Sat 14 Oct 2017 03:16:06 PM UTC, comment #26: 

Plotting with Qt5 didn't work for me either (unless I set LIBGL_ALWAYS_SOFTWARE=1). That has improved with a recent tip (hg id 8e034cb195f1). That is, the figures no longer appear black even without that switch.

However, the axes grids are rendered upside down on screen. When printing "demo light 1", I see the following:

>> print (1, "demo_light_1_qt5_print.png")
context mismatch in svga_sampler_view_destroy
context mismatch in svga_sampler_view_destroy


Nothing upside down here.

Both on-screen and print results are attached.

With "LIBGL_ALWAYS_SOFTWARE=1 ./run-octave", the figure renders correctly.


Markus Mützel <mmuetzel>
Group administrator
Sun 08 Oct 2017 04:11:34 PM UTC, comment #25: 

Since I have switched to Wayland, I have been running Octave with LIBGL_ALWAYS_SOFTWARE=Yes whenever I need to plot something. I think jwe wants to add some logic to the octave wrapper executable so it automatically sets this environment variable when needed.

Mike Miller <mtmiller>
Group Member
Fri 11 Aug 2017 09:10:21 PM UTC, comment #24: 

It seems to me that something needs fixing, but I don't know whether it's a Mesa problem or a Qt problem.

I've found other problems when building with Qt 5 that seem to me like regressions from Qt 4, but I don't know where to pursue them. It will be a shame if users get a bad Octave experience when systems start to move to Wayland and drop Qt 4 support. We are continuing to build Octave with Qt 4 in Debian as long as things with Qt 5 and Mesa remain fragile.

Mike Miller <mtmiller>
Group Member
Fri 11 Aug 2017 08:55:29 PM UTC, comment #23: 

This has been marked as "Won't Fix".  Can it be closed?

Rik <rik5>
Group administrator
Wed 12 Jul 2017 07:59:45 PM UTC, comment #22: 

It still fails occasionally for me even when I set LIBGL_ALWAYS_SOFTWARE=1.

John W. Eaton <jwe>
Group administrator
Wed 12 Jul 2017 07:51:04 PM UTC, comment #21: 

I can reproduce the problem on

cat /proc/cpuinfo
processor        : 0
vendor_id        : GenuineIntel
cpu family        : 6
model                : 60
model name        : Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
stepping        : 3
microcode        : 0x22

glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Haswell Desktop  (0x412)
    Version: 17.1.4
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Desktop
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.4
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 17.1.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.1.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10


Setting LIBGL_ALWAYS_SOFTWARE=1
"solves" the problem, though there is a black screen flash
that lasts about a sec before the actual plot appears.

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Wed 12 Jul 2017 06:02:20 PM UTC, comment #20: 

OK.  Thanks for checking.

John W. Eaton <jwe>
Group administrator
Wed 12 Jul 2017 05:58:55 PM UTC, comment #19: 

I cranked the delay up to 1 second and I still get only a black canvas.

Mike Miller <mtmiller>
Group Member
Wed 12 Jul 2017 05:06:57 PM UTC, comment #18: 

Mike:  Could you test the patch I posted?  You may have to experiment with the delay time.

Also, for the record, here is the output from glxinfo -B on my system:


zbox:44> glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 400 (Braswell)  (0x22b1)
    Version: 13.0.6
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 400 (Braswell)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.0.6
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 13.0.6
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 13.0.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10


John W. Eaton <jwe>
Group administrator
Wed 12 Jul 2017 04:37:13 PM UTC, comment #17: 

Resizing the window doesn't help here, but that could still be a timing thing.

Mike Miller <mtmiller>
Group Member
Wed 12 Jul 2017 04:29:28 PM UTC, comment #16: 

I also see the problem with qt5 and can confirm that resizing the window makes the plot appear.

If I run Octave, attach gdb to the octave-gui process, set a breakpoint in the QtHandles::Container::resizeEvent function and then execute "sombrero" at the octave prompt, execution stops in the resizeEvent function and the figure is properly displayed when I continue execution.  If I delete the breakpoint or type "continue" for gdb prior to executing "sombrero", then the plot doesn't appear properly.

To me, this suggests some kind of timing or threading issue.  And if I make the attached change (inserting a delay in the QtHandles::Container::resizeEvent function), it seems the plot will appear correctly given a sufficient delay.  On my system, a delay of 0.2 seconds appears to be sufficient to make the plot always appear correctly.  With a smaller delay the plot is sometimes correct and sometimes not.  Oddly, it seems to fail more often if the cursor is in the plot window when it is drawn.

I'm not saying that a delay is the right fix, only that this behavior points to some kind of timing issue.  If so, then maybe there is something we can do to avoid the problem?


(file #41192)

John W. Eaton <jwe>
Group administrator
Wed 12 Jul 2017 10:02:25 AM UTC, comment #15: 

I can confirm here that building octave from source using qt4 solves the problem.

Harish Hyma <sitwano>
Wed 12 Jul 2017 03:56:37 AM UTC, comment #14: 

I did switch to Intel graphycs and it works fine.

 glxinfo -B
name of display: :1
display: :1  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Sandybridge Desktop  (0x122)
    Version: 17.1.4
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop
OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.1.4
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 17.1.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 17.1.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

uname -a
Linux i7 4.11.9-300.fc26.x86_64 #1 SMP Wed Jul 5 16:21:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

cat /proc/cpuinfo

processor        : 0
vendor_id        : GenuineIntel
cpu family        : 6
model                : 42
model name        : Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
...


FYI.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 11 Jul 2017 10:17:05 PM UTC, comment #13: 

Ok, I see the same. I guess the Intel direct rendering has some problems that are exposed by this combination of Qt 5 running under wayland.

Workarounds include LIBGL_ALWAYS_SOFTWARE=1, using Xorg instead of Xwayland, and compiling Octave with Qt 4 (works here at least).

Mike Miller <mtmiller>
Group Member
Tue 11 Jul 2017 08:17:25 PM UTC, comment #12: 

Dmitry, you're a genius! Not sure what this command does but my plots are working. This should maybe be the default flag to use to run octave.


LIBGL_ALWAYS_SOFTWARE=1 octave


However, the plot does not show up until I resize the plot window. This is very annoying. So I would say its still a bit buggy.

Harish Hyma <sitwano>
Tue 11 Jul 2017 07:58:05 PM UTC, comment #11: 

Could you try
+verbose+
LIBGL_ALWAYS_SOFTWARE=1 octave
-verbose-

provided you have llvmpipe installed.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 11 Jul 2017 07:44:56 PM UTC, comment #10: 

I'm not sure about arch linux, but I've almost always compiled octave using qt4 in the past on ubuntu. And I do remember the configuration options showing qt5 as an option. I didn't even know that octave was built using qt5 in Arch Linux.

Harish Hyma <sitwano>
Tue 11 Jul 2017 07:44:23 PM UTC, comment #9: 

I have both Qt-5.7.1 and Qt-4.8.7 and both work.

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Tue 11 Jul 2017 07:36:46 PM UTC, comment #8: 

Harish - does Arch give you the option of building Octave against either Qt 4 or Qt 5?

Dmitri - which Qt versions have functional plotting for you in a Xwayland session?

Mike Miller <mtmiller>
Group Member
Tue 11 Jul 2017 07:27:29 PM UTC, comment #7: 

I have almost the same output as Harish, different device and memory size, but same Mesa version and Intel DRI.

If I built Octave with Qt 4 on the same machine, the qt toolkit works fine in an Xwayland session. Built with Qt 5 it shows a black area. The fltk toolkit works fine either way. So again, this doesn't seem to be a Mesa or video driver issue, this seems to be a Qt 5 / Wayland / OpenGL issue.

Mike Miller <mtmiller>
Group Member
Tue 11 Jul 2017 06:47:42 PM UTC, comment #6: 

I get the following when I run glxinfo -B

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)  (0x1616)
    Version: 17.1.4
    Accelerated: yes
    Video memory: 3072MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.4
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 17.1.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.1.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

Is it really a hardware driver issue even though the qt plot stuff works when logged in using XOrg?

Harish Hyma <sitwano>
Tue 11 Jul 2017 05:04:13 PM UTC, comment #5: 

Could you post
glxinfo -B
output?

All my computers currently running Gallium with either
amd or nouveau or llvmpipe backends. None of them have
problem with plotting to either qt or fltk.
Here is one with nvidia:



name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: nouveau (0x10de)
    Device: NVC3 (0xdd8)
    Version: 17.1.4
    Accelerated: yes
    Video memory: 975MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NVC3
OpenGL core profile version string: 4.3 (Core Profile) Mesa 17.1.4
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 17.1.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.1.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

The one that used to give me problem was i7-2600k with integrated
graphics. At some moment I bought ~$50 entry level amd card for it and i do not have problem with it anymore. I will try its integrated graphics later today or tomorrow, but I cannot mess
with it at this moment. And I am running Wayland since Fedora 25beta which probably longer than a year.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 11 Jul 2017 04:35:26 PM UTC, comment #4: 

Is it a graphics hardware or driver issue if Octave's OpenGL rendering works perfectly under fltk but not under the Qt OpenGL-based qt toolkit? Both are using the same underlying rendering code.

Mike Miller <mtmiller>
Group Member
Tue 11 Jul 2017 03:42:09 PM UTC, comment #3: 

Works for me.
I think it is mostly graphics hardware driver issue.
Intel integrated graphics seems more problematic than
Gallium (AMD or Nvidia).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 11 Jul 2017 03:32:08 PM UTC, comment #2: 

I can confirm this here. Only the qt graphics_toolkit is affected. If you use graphics_toolkit fltk, plots seem to work fine.

Mike Miller <mtmiller>
Group Member
Tue 11 Jul 2017 02:55:36 PM UTC, comment #1: 

Does it help if you start octave as:

LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0 octave

?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 11 Jul 2017 02:46:57 PM UTC, original submission:  

Octave is not able to show any plots when plotted in wayland session. I have tried this on Arch Linux in the gnome desktop environment running with wayland. The plot controls show up, but are unresponsive as the plot window is just filled with a black background. Resizing the plot window just leads to weird artefacts.

This behaviour does not happen when logged in with XOrg, although initially one has to resize the plot window in order to see the plot. Any subsequent plot works fine in Xorg except the initial plot.

However plotting using octave-cli works under both wayland and XOrg. The only issue is that it uses the old plotting interface instead of the modern one.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #41192:  diffs.txt added by jwe (541B - text/plain)
file #41165:  Screenshot from 2017-07-11 16-43-17.png added by None (155KiB - image/png - Screenshot of broken plot in Wayland using Octave)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by sitwano (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by None (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
    2017-10-21 mtmiller Open/ClosedOpen Closed
    2017-10-18 mtmiller StatusWont Fix Fixed
    2017-10-14 rik5 Carbon-CopyRemoved 72865 -
    2017-10-14 mmuetzel Attached File- Added demo_light_1_qt5_onscreen.png, #42144
        Attached File- Added demo_light_1_qt5_print.png, #42145
    2017-07-12 mtmiller Open/ClosedClosed Open
    2017-07-12 jwe Attached File- Added diffs.txt, #41192
    2017-07-11 mtmiller StatusNone Wont Fix
        Open/ClosedOpen Closed
        Summarygraphics_toolkit qt does not work with Qt 5 in Xwayland graphics_toolkit qt does not work with Qt 5 in Xwayland and Intel mesa driver
    2017-07-11 mtmiller Summarygraphics_toolkit qt does not work in Xwayland graphics_toolkit qt does not work with Qt 5 in Xwayland
    2017-07-11 mtmiller CategoryPlotting Plotting with OpenGL
        SummaryOctave plotting does not work in Wayland graphics_toolkit qt does not work in Xwayland
    2017-07-11 None Attached File- Added Screenshot from 2017-07-11 16-43-17.png, #41165

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code