Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Issue with Wayland #664

Closed
ghost opened this issue Feb 23, 2018 · 18 comments
Closed

Issue with Wayland #664

ghost opened this issue Feb 23, 2018 · 18 comments
Labels
question

Comments

@ghost
Copy link

ghost commented Feb 23, 2018

Hello,
I was trying to run Mudlet AppImage without sudo it said: 'Segmentation fault (core dumped)' With sudo it said 'XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root/. No protocol specified. qt.qpa.screen: QXcbConnection: Could not connect to display :0. Could not connect to any X display, however Wayland should also have XWayland, which should serve as backward compatibility for X server or I am mistaken? If you need more info, which I suppose you do, then you need to navigate me in order to obtain necessary information.
@probonopd
Copy link
Member

probonopd commented Feb 23, 2018 •
edited
Loading

Which exact operating system, version, and desktop environment are you running?
Which exact Mudlet AppImage are you using?

Can you reproduce this on any of the available Linux distribution Live ISOs?

@ghost
Copy link
Author

ghost commented Feb 23, 2018

I am running Fedora 27 64-bit with GNOME DE with kernel version 4.15.4-300 on notebook, which is installed on HDD.

I am using 3.7.1 Mudlet AppImage

I tried live ISO of Antergos on my PC and it worked.
I tried live ISO of Fedora 27 on my notebook and it worked. (Same live ISO, which resides on my ntb HDD)
It was needed to run it under sudo, but it worked.
Difference between live ISO output, which works, and Fedora 27 on my HDD is this line:
qt.qpa.screen: QXcbConnection: Could not connect to display :0. Could not connect to any X display
Mudlet works - Live ISO Fedora 27
Mudlet doesn't work - HDD Fedora 27

@probonopd
Copy link
Member

Please report this issue to the publisher of the Mudlet AppImage.

@vadi2
Copy link

vadi2 commented Feb 24, 2018

As far as I see it's not a problem related to us, or at least I don't know where to start. If the AppImage is working on certain distributions and not on others, it would seem to be a distribution problem, not a software one...

@probonopd
Copy link
Member

Well, since AppImage is just a self-mounting filesystem that executes whatever is inside the AppImage, I think we need to look for the issue either in the application, the dependencies it uses (e.g., Qt), and/or the system that was used to deploy those into the AppImage (e.g., linuxdeployqt).

@ghost
Copy link
Author

ghost commented Feb 25, 2018 •
edited by ghost
Loading

I tried to install Antergos on my notebook and tried to launch Mudlet. It was successful. My guess is that some package within QT is not installed by default in Fedora and is not included in Mudlet AppImage, since mentioned variables are set on same value. Probably something like with Texlive. You install it as a whole, but if you need something specific, you need to install that separately (texlive-cjk) or from RPMFusion (texlive-babel-czech).

@probonopd
Copy link
Member

I tried to install Antergos on my notebook and tried to launch Mudlet. It was successful.

Thanks for testing. Interesting. Is Antergos using Wayland or Xorg or Xorg-on-Wayland?

My guess is that some package within QT is not installed by default in Fedora and is not included in Mudlet AppImage

The Qt bundled inside an AppImage should never attempt to use Qt modules from the system, since this will lead to crashes due to version mismatches.

@KurtPfeifle
Copy link
Contributor

@vadi2:

'If the AppImage is working on certain distributions and not on others, it would seem to be a distribution problem, not a software one...'

Well, you can easily build an "AppImage" on a very current and bleeding-edge system, which will NOT run on MOST systems. While it may technically be an AppImage, it would not by one by spirit... It may not be a problem of the payload software itself, but a problem with the specific way the AppImage was built.

(@vadi2: I wrote my above comment without knowing anything about Mudlet or its AppImage building environment, so please don't take this as a personal reference to YOU or YOUR work. It's just a comment about that specific statement of yours, which seems to be too general to justify the logic of its conclusion...)

@ghost
Copy link
Author

ghost commented Feb 25, 2018 •
edited by ghost
Loading

Antergos is arch-based distribution with LightDM manager. Somehow it was running under x11 (xorg), when it should be running under wayland, so I installed gdm and xorg-server-xwayland as a dependency and gone through GDM. It's running under wayland properly now. Tested both x11 (xorg) and wayland sessions with Mudlet. Both seem to be working with Mudlet. I am running GNOME v3.26.1-2.

@vadi2
Copy link

vadi2 commented Feb 27, 2018

Mudlet's AppImage is built on Travis's standard trusty image, build log for the image in question is https://travis-ci.org/Mudlet/Mudlet/jobs/320754399.

@sudo-give-me-coffee
Copy link

Wayland is a joke, most programs in all distribution formats do not run and developers do not listen to users

With these steps you can run your application (it worked for me):

  • Fix "XDG_RUNTIME_DIR":
xdg-user-dirs-update
sudo su
cd ~
xdg-user-dirs-update
  • Fix "Could not connect to display :0"

Just install XWayland

In some cases before starting application is needed run:

export "DISPLAY=:0"

@probonopd
Copy link
Member

@sudo-give-me-coffee thanks for your help here. Is it fair to say this is an issue of the distribution, as the distribution should do the xdg-user-dirs-updateand the export "DISPLAY=:0"?

@sudo-give-me-coffee
Copy link

sudo-give-me-coffee commented Mar 6, 2018 •
edited
Loading

@probonopd So,

The xdg-user-dirs-update yes, but export "DISPLAY =: 0" no, this should be done by Wayland whenever running an application that depends on X.org (XWayland),

$ XDG_RUNTIME_DIR I don't know what happens and the reason for xdg-user-dirs fix it in some cases, because this is a necessary environment variable for multiple applications, and normally (outside of wayland) is required to follow these steps to fix:

Xvfb :0 -screen 0 [screen resolution]x[monitor frequency] +extension GLX -nolisten tcp -dpi 96
export DISPLAY=:0
xhost +SI:localuser:root
sudo whatever...
xhost -SI:localuser:root
xhost

So i think that if xdg-user-dirs-update fix, there isn't issue of the distribution

@Omaj7 This #664 (comment) fix?

@probonopd
Copy link
Member

So it loos we can close this issue here, do you agree? Or do you think AppImageKit needs to change something?

@ghost
Copy link
Author

ghost commented Mar 10, 2018

@probonopd No need to change anything in AppImageKit.
@sudo-give-me-coffee Thank you for writing down steps to do in order to make Mudlet work on Fedora.

  • Fix "XDG_RUNTIME_DIR":

xdg-user-dirs-update
sudo su
cd ~
xdg-user-dirs-update

  • Fix "Could not connect to display :0"

Just install XWayland

@vadi2 Should clone this issue to Mudlet FAQ or wiki until these steps won't be needed for Fedora anymore.

@ghost ghost closed this as completed Mar 10, 2018
@vadi2
Copy link

vadi2 commented Mar 10, 2018 via email

@probonopd
Copy link
Member

Thanks everyone, added https://github.com/AppImage/AppImageKit/wiki/Wayland

@probonopd
Copy link
Member

Please see https://blog.martin-graesslin.com/blog/2018/03/unsetting-qt_qpa_platform-environment-variable-by-default/

Since the introduction of the Plasma/Wayland session we set the QT_QPA_PLATFORM variable to wayland by default. After a long and hard discussion we decided to no longer do this with Plasma 5.13. This was a hard decision and unliked by everyone involved. (...) But how can it happen that the qpa platform plugin is missing although Plasma itself happily uses it? The problem is that application installed outside of the system bundle their own Qt and Qt does not (yet) include QtWayland QPA platform plugin. This affects proprietary applications, FLOSS applications bundled as appimages, FLOSS applications bundled as flatpaks and not distributed by KDE and even the Qt installer itself. In my opinion this is a showstopper for running a Wayland session.

So it seems that we should include the QtWayland QPA platform plugin going forward; but in the meantime distributions should not set the QT_QPA_PLATFORM variable to wayland by default.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@vadi2 @probonopd @TheAssassin @KurtPfeifle @sudo-give-me-coffee