QtWebEngine and Wayland

[The-Compiler]

Apparently --backend webengine on Wayland (probably with QT_QPA_PLATFORM=wayland-egl or QT_QPA_PLATFORM=wayland, without xwayland) segfaults (or aborts?).

We should probably detect that and show an error.

[The-Compiler]

Hmm, https://codereview.qt-project.org/#/c/203480/4//ALL,unified mentions "Fixed crash when using Wayland QPA.".

[tidux]

This looks like it goes back to QtWebEngine not having an actual Wayland port. Last I looked it still uses Xcb directly on Linux.

[The-Compiler]

Yes, but I'm mainly wondering whether we can handle this in a nicer way, i.e. display an error message instead of crashing.

[The-Compiler]

I now pushed a nicer fix for this to the webengine-by-default branch, it'd be nice if some people could try it out. I've tried with Weston and sway both with XWayland (which should work normally) and without (which should show an error).

[bitraid]

For me it didn't always crash (wayland-sway). Some times it started and worked fine.

[The-Compiler]

@bitraid And that was with the QtWebEngine backend and without XWayland?

[bitraid]

Yes.

[The-Compiler]

I only get this:

09:15:11 WARNING: WebEngine compiled with X11 support, however qpa backend is not xcb. This may fail.
[27960:27960:0929/091511.391419:ERROR:browser_main_loop.cc(494)] Failed to put Xlib into threaded mode.
[27960:27960:0929/091511.391534:ERROR:browser_main_loop.cc(1471)] Unable to open X display.

and then a segfault. I don't see how things could be any different for you...

Note that sway automatically uses XWayland unless you don't have it installed at all (or set WLC_XWAYLAND=0). If echo $DISPLAY gives you something, QtWebEngine used X, and qutebrowser should continue to run.

[bitraid]

Yes, thats the crash message i get under wayland:

WARNING: WebEngine compiled with X11 support, however qpa backend is not xcb. This may fail.
  File "/home/bitraid/bin/qutebrowser/qutebrowser.py", line 29, in <module>
    sys.exit(qutebrowser.qutebrowser.main())
  File "/home/bitraid/bin/qutebrowser/qutebrowser/qutebrowser.py", line 172, in main
    return app.run(args)
  File "/home/bitraid/bin/qutebrowser/qutebrowser/app.py", line 119, in run
    init(args, crash_handler)
  File "/home/bitraid/bin/qutebrowser/qutebrowser/app.py", line 145, in init
    _init_modules(args, crash_handler)
  File "/home/bitraid/bin/qutebrowser/qutebrowser/app.py", line 429, in _init_modules
    crash_handler.handle_segfault()
  File "/home/bitraid/bin/qutebrowser/qutebrowser/misc/crashsignal.py", line 98, in handle_segfault
    self._args.debug, data)
  File "/home/bitraid/bin/qutebrowser/qutebrowser/misc/crashdialog.py", line 472, in __init__
    self._set_crash_info()
  File "/home/bitraid/bin/qutebrowser/qutebrowser/misc/crashdialog.py", line 244, in _set_crash_info
    self._gather_crash_info()
  File "/home/bitraid/bin/qutebrowser/qutebrowser/misc/crashdialog.py", line 510, in _gather_crash_info
    super()._gather_crash_info()
  File "/home/bitraid/bin/qutebrowser/qutebrowser/misc/crashdialog.py", line 228, in _gather_crash_info
    self._crash_info.append(("Version info", version.version()))
  File "/home/bitraid/bin/qutebrowser/qutebrowser/utils/version.py", line 329, in version
    lines.append("Backend: {}".format(_backend()))
  File "/home/bitraid/bin/qutebrowser/qutebrowser/utils/version.py", line 319, in _backend
    return 'QtWebEngine (Chromium {})'.format(_chromium_version())
  File "/home/bitraid/bin/qutebrowser/qutebrowser/utils/version.py", line 303, in _chromium_version
    profile = QWebEngineProfile()
  File "/home/bitraid/bin/qutebrowser/qutebrowser/utils/log.py", line 445, in qt_message_handler
    stack = ''.join(traceback.format_stack())

[8090:8113:0928/193852.754907:ERROR:gl_surface_qt.cpp(479)] eglCreatePbufferSurface failed with error EGL_BAD_MATCH

After 3-5 retries (sometimes more) it starts ok. It runs for sure under wayland: xprop doesn't recognize the window and yanking doesn't pass the text to X clipboard. I have set QT_QPA_PLATFORM=wayland-egl

[The-Compiler]

I've seen that kind of thing happen when QT_QPA_PLATFORM=wayland-egl is set, but DISPLAY (and thus XWayland) is still available. Is that the case for you?

Like you say it doesn't really work reliably though, so I'd rather not support that. Maybe things look better with 5.9.2 or 5.10, I haven't checked that yet.

[bitraid]

Yes XWayland is available. Things on wayland-wlc are not reliable in general.

[The-Compiler]

Hmm, fair enough, that scenario seems fine to run under Weston. I'll need to investigate some more and maybe allow that again.

[The-Compiler]

I just tried with some other compositors (orbment and way-cooler), and I get the same crashes there. So it seems like it works in Weston but even there shows some Qt/OpenGL errors. I'd rather keep that disabled for now, and look at it again with Qt 5.10 as part of #2939.

[bitraid]

Sway and way-cooler will soon switch to wlroots. I guess things will be better then...

[The-Compiler]

Okay, okay, you just gave me another reason to re-open this 😆 See https://github.com/swaywm/sway/issues/1301

I'll take a look at how things look then.

[The-Compiler]

FWIW in 9c080538ba23ecb3253275060af7a79ccf9ae514 I added a qt.force_platform setting plus a button in the wayland error dialog to set that to xcb (if DISPLAY was set). In other words, if you have QT_QPA_PLATFORM=wayland set globally, you can easily set that back to xcb for qutebrowser/QtWebEngine to work properly now.

[bitraid]

That's useful. How about an option (for testing purposes) to qt.force_platform, so it will try to run under wayland anyway?

[The-Compiler]

There's QUTE_SKIP_WAYLAND_CHECK=1 you can set as an environment variable. I don't want to document it, because I know people will ignore my warnings and I'll have to deal with the crash report :wink:

[The-Compiler]

Related changes/issues:

• https://codereview.qt-project.org/#/c/208093/
• https://codereview.qt-project.org/#/c/208094/
• https://codereview.qt-project.org/#/c/209577/
• https://codereview.qt-project.org/#/c/210031/
• https://bugreports.qt.io/browse/QTBUG-63862

[bitraid]

I tried setting QUTE_SKIP_WAYLAND_CHECK=1 but i still get the check...

[The-Compiler]

@bitraid How did you set it? Note that you need to do export QUTE_SKIP_WAYLAND_CHECK=1 if doing it in a terminal.

[bitraid]

I forgot the export, sorry - now it works.

[edrex]

It seems to work for me (arch, sway, qt 5.9.2):

QT_QPA_PLATFORM=wayland QUTE_SKIP_WAYLAND_CHECK=1 qutebrowser --temp-basedir --backend webengine
16:41:46 WARNING: WebEngine compiled with X11 support, however qpa backend is not xcb. This may fail.
[4694:4715:1023/164147.056835:ERROR:gl_surface_qt.cpp(480)] eglCreatePbufferSurface failed with error EGL_BAD_MATCH
[4694:4715:1023/164147.705767:ERROR:gl_surface_qt.cpp(480)] eglCreatePbufferSurface failed with error EGL_BAD_MATCH

The window decorations show up and fullscreen youtube doesn't quite work, but other than that it seems ok.

I'm eager to make the leap to wayland/sway to benefit from its better support for mixed DPI with native wayland clients, so I'll probably keep testing.

[edrex]

(no segfault)

dependent on your graphics card, i'd guess

[edrex]

nevermind, I am getting segfaults after awhile :P

[The-Compiler]

@edrex Note that you can still run qutebrowser on Wayland (via XWayland).

[The-Compiler]

I've tried the current Qt dev branch, but get:

[21635:21658:1031/112807.219869:ERROR:gl_implementation.cc(246)] Failed to load /home/florian/code/qt/devenv/bin/libGLESv2.so: /home/florian/code/qt/devenv/bin/libGLESv2.so: cannot open shared object file: No such file or directory
[21635:21658:1031/112807.534079:ERROR:gl_surface_qt.cpp(701)] Requested OpenGL implementation is not supported. Implementation: 0
11:28:07 CRITICAL: ASSERT failure in Q_UNREACHABLE(): "Q_UNREACHABLE was reached", file ../gl_surface_qt.cpp, line 702
Received signal 6
#0 0x7f8c87cc275b base::debug::StackTrace::StackTrace()
#1 0x7f8c87cc0558 base::debug::StackTrace::StackTrace()
#2 0x7f8c87cc1444 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x7f8ca657fda0 <unknown>
#4 0x7f8ca61eb8a0 __GI_raise
#5 0x7f8ca61ecf09 __GI_abort
#6 0x7f8ca0d3fa7f qt_message_fatal()
#7 0x7f8ca0d4084d QMessageLogger::fatal()
#8 0x7f8ca0d3a772 qt_assert_x()
#9 0x7f8c83e22abe gl::init::CreateOffscreenGLSurfaceWithFormat()
#10 0x7f8c89e7bebe gl::init::CreateOffscreenGLSurface()
#11 0x7f8c89eb7874 gpu::GpuChannelManager::GetDefaultOffscreenSurface()
#12 0x7f8c89ec1ea3 gpu::GpuCommandBufferStub::Initialize()
#13 0x7f8c89ebf0c7 gpu::GpuCommandBufferStub::Create()
#14 0x7f8c89e962aa gpu::GpuChannel::CreateCommandBuffer()
#15 0x7f8c89e95a6d gpu::GpuChannel::OnCreateCommandBuffer()
#16 0x7f8c89ea6fce _ZN4base20DispatchToMethodImplIPN3gpu10GpuChannelEMS2_FvRK28GPUCreateCommandBufferConfigiNS_18SharedMemoryHandleEPbPNS1_12CapabilitiesEERSt5tupleIJS4_iS7_EESD_IJbS9_EEJLm0ELm1ELm2EEJLm0ELm1EEEEvRKT_T0_OT1_PT2_NS_13IndexSequenceIJXspT3_EEEENSP_IJXspT4_EEEE
#17 0x7f8c89ea290a _ZN4base16DispatchToMethodIPN3gpu10GpuChannelEMS2_FvRK28GPUCreateCommandBufferConfigiNS_18SharedMemoryHandleEPbPNS1_12CapabilitiesEERSt5tupleIJS4_iS7_EESD_IJbS9_EEEEvRKT_T0_OT1_PT2_
#18 0x7f8c89e9dd41 _ZN3IPC8MessageTI38GpuChannelMsg_CreateCommandBuffer_MetaSt5tupleIJ28GPUCreateCommandBufferConfigiN4base18SharedMemoryHandleEEES2_IJbN3gpu12CapabilitiesEEEE8DispatchINS7_10GpuChannelESC_vMSC_FvRKS3_iS5_PbPS8_EEEbPKNS_7MessageEPT_PT0_PT1_T2_
#19 0x7f8c89e94c6d gpu::GpuChannel::OnControlMessageReceived()
#20 0x7f8c89e95782 gpu::GpuChannel::HandleMessageHelper()
#21 0x7f8c89e95886 gpu::GpuChannel::HandleOutOfOrderMessage()
#22 0x7f8c89eb0b38 _ZN4base8internal13FunctorTraitsIMN3gpu10GpuChannelEFvRKN3IPC7MessageEEvE6InvokeIRKNS_7WeakPtrIS3_EEJS7_EEEvS9_OT_DpOT0_
#23 0x7f8c89eadcc6 _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN3gpu10GpuChannelEFvRKN3IPC7MessageEERKNS_7WeakPtrIS5_EEJS9_EEEvOT_OT0_DpOT1_
#24 0x7f8c89eaa257 _ZN4base8internal7InvokerINS0_9BindStateIMN3gpu10GpuChannelEFvRKN3IPC7MessageEEJNS_7WeakPtrIS4_EES6_EEEFvvEE7RunImplIRKSA_RKSt5tupleIJSC_S6_EEJLm0ELm1EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE
#25 0x7f8c89ea575c _ZN4base8internal7InvokerINS0_9BindStateIMN3gpu10GpuChannelEFvRKN3IPC7MessageEEJNS_7WeakPtrIS4_EES6_EEEFvvEE3RunEPNS0_13BindStateBaseE
#26 0x7f8c83fa61bd _ZNO4base8CallbackIFvvELNS_8internal8CopyModeE0ELNS2_10RepeatModeE0EE3RunEv
#27 0x7f8c87f5fff3 base::debug::TaskAnnotator::RunTask()
#28 0x7f8c87d3860a base::MessageLoop::RunTask()
#29 0x7f8c87d387a1 base::MessageLoop::DeferOrRunPendingTask()
#30 0x7f8c87d38ce7 base::MessageLoop::DoWork()
#31 0x7f8c87d51e0b base::MessagePumpDefault::Run()
#32 0x7f8c87d37ef6 base::MessageLoop::Run()
#33 0x7f8c87dddf1c base::RunLoop::Run()
#34 0x7f8c87e67ae4 base::Thread::Run()
#35 0x7f8c87e68399 base::Thread::ThreadMain()
#36 0x7f8c87e46004 base::(anonymous namespace)::ThreadFunc()
#37 0x7f8ca657508a start_thread
#38 0x7f8ca62ad24f __GI___clone
  r8: 0000000000000000  r9: 00007f8c1f31b940 r10: 0000000000000008 r11: 0000000000000246
 r12: 00007f8c1f31bd38 r13: 0000000000000000 r14: 00007f8c1f31bf78 r15: 00007f8c08009760
  di: 0000000000000002  si: 00007f8c1f31b940  bp: 00007f8c1f31bba8  bx: 0000000000000006
  dx: 0000000000000000  ax: 0000000000000000  cx: 00007f8ca61eb8a0  sp: 00007f8c1f31b940
  ip: 00007f8ca61eb8a0 efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.
[21662:21662:0100/000000.446258:ERROR:command_buffer_proxy_impl.cc(229)] Failed to send GpuChannelMsg_CreateCommandBuffer.
[21662:21662:0100/000000.446377:ERROR:context_provider_command_buffer.cc(262)] GpuChannelHost failed to create command buffer.

[bitraid]

I haven't seen any crash yet after the latest qt update on arch.

[camoz]

I still get crashes sometimes with QT_QPA_PLATFORM=wayland QUTE_SKIP_WAYLAND_CHECK=1 qutebrowser on up-to-date Arch Linux (without testing). This is on a Thinkpad X200 (Intel GMA X4500MHD).

[bitraid]

Well, i got one today...

[ghost]

Getting it right now on Void with Sway, backend regardless.

[The-Compiler]

@Nobabs27 "it"? Can you please open a new issue with the output you get exactly and version information?

[The-Compiler]

FWIW with Qt 5.10 there's QTBUG-65682 so using Wayland + QtWebEngine without XWayland will need to wait at least until Qt 5.10.1.

[ghost]

@The-Compiler By "it" I mean this issue (segfault on Wayland).

[The-Compiler]

@Nobabs27 Well, with that little information, I still won't be able to help you.

[tidux]

I'm not seeing segfaults of QtWebEngine on Wayland either, even with explicitly forcing the Wayland QPA variables.

[The-Compiler]

FWIW I'm still having issues here with Qt 5.10.1 and Sway/Weston (when doing QT_QPA_PLATFORM=wayland QUTE_SKIP_WAYLAND_CHECK=1 python3 -m qutebrowser --temp-basedir). It crashes before it even starts.

Hoping things will look better with Qt 5.11 though!

[bitraid]

I'm testing (and writing this message from) the alpha version of sway 1.0, which uses wlroots, and that crash seems to be gone (the QT version is 5.10.1).

[edrex]

@bitraid as soon as sway@wlroots gets tab/stack container layouts I'm going to try using it as my daily driver. I'll test a bit now with qutebrowser...

[edrex]

@The-Compiler qutebrowser is working with that line for me under sway alpha, qt 5.10.1.

[johanhelsing]

@The-Compiler It's working fine for me as well. Can you please link to the bugs in Qt you encounter?

Perhaps it's time to add a button to continue anyway to that dialog at startup?

[The-Compiler]

On Qt 5.10.1 I got QTBUG-63862 - entirely possible that this got fixed in Qt 5.11.

On Qt 5.11, I'm getting QTBUG-68479, but Archlinux added a patch to make it work (with disabled GPU rendering).

I'd still much rather let the user choose (rendering without GPU support can be quite a performance hog on some machines), but it's definitely time to update that dialog on Qt 5.11 (and maybe 5.10.1 too).

[The-Compiler]

On Qt 5.11, the dialog now offers "use software rendering" as a third option (which is the equivalent of the Archlinux patch).

[edrex]

Confusingly, I'm no longer seeing the QTBUG-68479 workaround message, and qutebrowser is running (not so stably, but usable for awhile) with HW acceleration reported in chrome:gpu (Arch, Qt 5.11.1 package, latest sway trunk). I don't see any relevant patches in the arch package commit log so I have no idea what changed. Anyway it looks gorgeous on my 4k XPS13. This feels tantalizingly close :)

[glglwty]

Qt 5.11.1 with QTBUG-68479 patch works for me with HW accelaration (sway 0.15.2, mesa driver). I also tested amdgpu. It doesn't crash but there are random dislocations all over any page.

[The-Compiler]

@glglwty Huh? What that Archlinux patch does is disabling HW acceleration.

[glglwty]

@The-Compiler I meant I patched Qt 5.11 with https://codereview.qt-project.org/#/c/232017/ which is supposed to fix QTBUG-68479. We can expect 5.12 to work in wayland without significant issues.

[dax-dev]

Working fine under Arch with sway-1.0-alpha.5, qt5-5.11.1, qutebrowser-1.4.1

QT_QPA_PLATFORM=wayland QUTE_SKIP_WAYLAND_CHECK=1 qutebrowser

[The-Compiler]

Looks like I'll need to look at this one yet again :laughing:

FWIW 5.12 has some other changes (mostly using the Ozone backend) which might change this situation yet again.

[cosmojg]

Here's a screenshot of my setup: https://i.imgur.com/txJVuZb.png

I have both QT_QPA_PLATFORM=wayland and QUTE_SKIP_WAYLAND_CHECK=1 set and use Qutebrowser natively on a daily basis! Everything works beautifully, even hardware acceleration according to chrome:gpu. I'm currently running qt5-base version 5.11.1-3, qt5-wayland version 5.11.1-1, and qt5-webengine version 5.11.1-3, all three of which are straight from the Arch Linux repositories without any patching on my part. In case it's relevant, I'm also using Sway version 1.0-alpha.5-332 from the AUR.

The only problem I've experienced thus far is that UI elements and UI fonts appear comically large with Wayland and the default 10-point font settings. For comparison, here's how fonts look with XWayland on the same system with the same settings: https://i.redd.it/4s2wsyy2snl11.png

Any idea about what's causing this or how to fix it?