Bug 121275 - LibreOffice does not start on wayland without an Xwayland DISPLAY running
Summary: LibreOffice does not start on wayland without an Xwayland DISPLAY running
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
6.1.2.1 release
Hardware: All FreeBSD
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:6.2.0
Keywords:
Depends on:
Blocks: Wayland
  Show dependency treegraph
 
Reported: 2018-11-08 15:07 UTC by Greg V
Modified: 2018-11-09 15:44 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Greg V 2018-11-08 15:07:09 UTC
Description:
LibreOffice seems to require an X11 $DISPLAY just to start, even if it actually runs in Wayland native mode

Steps to Reproduce:
Disable Xwayland in your compositor (or probably just unset $DISPLAY) and launch LO

Actual Results:
It just silently quits, showing nothing on the console even

Expected Results:
Should have launched


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
Comment 1 Caolán McNamara 2018-11-08 15:38:46 UTC
It might be the splashscreen thing, which is still in X, does launching from the command line like...

libreoffice --nologo

work ?
Comment 2 Greg V 2018-11-08 15:54:39 UTC
(In reply to Caolán McNamara from comment #1)
> It might be the splashscreen thing, which is still in X, does launching from
> the command line like...
> 
> libreoffice --nologo
> 
> work ?

I have tested nologo (forgot to mention), it does not help.

Though the instant quit probably meant LO was already open, so these results were not right.

Actually what's happening when DISPLAY is not set and there's no existing LO session is that two processes are both waiting on a mutex forever (umtx ~= futex):

  538: pwrite(5,"<item oor:path="/org.openoffice."...,65541,0x13d5ef) = 65541 (0x10005)
  538: pwrite(5,"Position" oor:op="fuse"><value>1"...,55277,0x14d5f4) = 55277 (0xd7ed)
  538: close(5)                                  = 0 (0x0)
  538: rename("/home/greg/.config/libreoffice/4/user/Uxl7Ia","/home/greg/.config/libreoffice/4/user/registrymodifications.xcu") = 0 (0x0)
  538: <thread 101507 exited>
  527: _umtx_op(0x800a4b008,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffdfffcec8) ERR#60 'Operation timed out'
  538: _umtx_op(0x8077a7008,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffdfffcec8) ERR#60 'Operation timed out'
  527: _umtx_op(0x800a4b008,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffdfffcec8) ERR#60 'Operation timed out'
  538: _umtx_op(0x8077a7008,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffdfffcec8) ERR#60 'Operation timed out'
  527: _umtx_op(0x800a4b008,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffdfffcec8) ERR#60 'Operation timed out'
  538: _umtx_op(0x8077a7008,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x18,0x7fffdfffcec8) ERR#60 'Operation timed out'
Comment 3 Caolán McNamara 2018-11-08 16:02:44 UTC
hmm, under Linux and wayland, if I unset DISPLAY I get "Failed to open display" but I get a successful launch, adding --nolog and I get a successful launch without the "Failed to open display" junk
Comment 4 Caolán McNamara 2018-11-08 16:04:46 UTC
export SAL_DISABLEGL=1
is another possibility, might be some opengl detection bustage
Comment 5 Greg V 2018-11-08 16:40:43 UTC
(In reply to Caolán McNamara from comment #4)
> export SAL_DISABLEGL=1
> is another possibility, might be some opengl detection bustage

nah. That doesn't help (neither does disabling Java, which I tried just in case).

I guess I'll have to make a debug build, but does this backtrace suggest anything?

    frame #5: 0x0000000800843f15 libc++.so.1`std::__1::condition_variable::__do_timed_wait(this=<unavailable>, lk=<unavailable>, tp=<unavailable>) at condition_variable.cpp:74
    frame #6: 0x00000008043721e5 libvcllo.so`___lldb_unnamed_symbol6964$$libvcllo.so + 117
    frame #7: 0x0000000804371e2e libvcllo.so`SvpSalInstance::DoYield(bool, bool) + 638
    frame #8: 0x00000008042d28de libvcllo.so`Application::Execute() + 318
Comment 6 Caolán McNamara 2018-11-08 16:56:42 UTC
yeah, it means it has gone into headless mode, and is happily waiting for input which will never come, so maybe get_desktop_environment in vcl/unx/generic/desktopdetect/desktopdetector.cxx failure failure

you could try some stuff from there

e.g.

export OOO_FORCE_DESKTOP=gnome-wayland

or

export SAL_USE_VCLPLUGIN=gtk3
Comment 7 Greg V 2018-11-08 19:05:16 UTC
(In reply to Caolán McNamara from comment #6)
> yeah, it means it has gone into headless mode, and is happily waiting for
> input which will never come, so maybe get_desktop_environment in
> vcl/unx/generic/desktopdetect/desktopdetector.cxx failure failure
> 
> you could try some stuff from there
> 
> e.g.
> 
> export OOO_FORCE_DESKTOP=gnome-wayland
> 
> or
> 
> export SAL_USE_VCLPLUGIN=gtk3

Yeah, these do fix the problem, thanks!

I guess the detector should choose GTK3 if just WAYLAND_DISPLAY is present…
Comment 8 Caolán McNamara 2018-11-08 19:27:40 UTC
would https://gerrit.libreoffice.org/#/c/63123/ do the right thing for you ?
Comment 9 Greg V 2018-11-08 19:29:18 UTC
(In reply to Caolán McNamara from comment #8)
> would https://gerrit.libreoffice.org/#/c/63123/ do the right thing for you ?

I'm not going to rebuild LibreOffice right now, but I'm 99.9% sure it would :) Thanks!
Comment 10 Commit Notification 2018-11-09 15:34:36 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/293526165fcd236ba1742de2feec6ea06376e83f%5E%21

tdf#121275 fallback to gtk3 under wayland with unknown desktop

It will be available in 6.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Caolán McNamara 2018-11-09 15:44:40 UTC
lets assume that works then