[GH-ISSUE #3602] Wiki: x11 guide

gitea-mirror commented

2026-05-05 08:57:10 -06:00

Owner

Originally created by @matu3ba on GitHub (Aug 26, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3602

Summary

Xpra 4.x version works out of the box. However, it has input delay of around 0.5seconds.
Xephyr has less input dela, but it is a mess to setup. Once Xephyr gets configurated, it breaks Xpra.
We could sandbox the sandbox setup to fix this or use an overlay, but thats too much clutter.

Xpra
just works, but with constant lag :(

Xephyr

Xephyr clibpoard only has a copy-to-all clipboards solution, which leaves room for clipboard attacks and application sneaking the clipboard. Xephyr also takes some setup.
A suggested clipboard solution xclipsync does NOT work for me.
If -extension MIT-SHM is used, no shared memory (more secure)

TODOs

X11

Document and add extensions like -extension MIT-SHM
Document needed xpra version, test xpra (+clipboard)

Wayland

Known security caveats of implementations => stuff that runs on X11 without user knowledge (login manager)
No guarantee or user indication, if applications use Wayland (it may just refuse to do without extra setup like firefox)
Document how to always start applications with Wayland(GTK,Qt)
~~(too much effort) Document how to sandbox XWayland (replace login manager, rewrite session handling in elogind/logind)~~ just disallow X11
~~Need to check with xlsclients(requires restart), xeyes, xwininfo, starting application with DISPLAY='' app or WAYLAND_DEBUG=1 app in contrast to grepping for display ports~~ hack around with a huge command / upstream stuff to firejail?!
Application specific mitigations => force Wayland and see, if stuff crashes => then use an alternative
~~Many distros dont ship a separate name to indicate that the application definitely uses wayland~~ dont trust distros, they dont even manage to deprecate non-XDGBDS conforming applications
~~Login managers of distros still all use X11 (session management interaction?)~~ no useless work
~~Each login manager uses its own scripts for the Wayland and Xwayland session, but default X11 installation setup remains in /etc/X11~~ no useless work

Originally created by @matu3ba on GitHub (Aug 26, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3602 **Summary** 1. Xpra 4.x version works out of the box. However, it has input delay of around 0.5seconds. 2. Xephyr has less input dela, but it is a mess to setup. Once Xephyr gets configurated, it breaks Xpra. We could sandbox the sandbox setup to fix this or use an overlay, but thats too much clutter. __Xpra__ just works, but with constant lag :( __Xephyr__ 1. Xephyr clibpoard only has a [copy-to-all clipboards solution](https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Sandboxing_the_Firefox_Browser_with_Firejail#Setting_Up_Clipboard_Sharing_and_Display_Rescaling_for_Xephyr), which leaves room for clipboard attacks and application sneaking the clipboard. Xephyr also takes some setup. 2. A suggested clipboard solution [xclipsync](https://github.com/apenwarr/xclipsync) does NOT work for me. 3. If `-extension MIT-SHM` is used, no shared memory (more secure) TODOs **X11** - [ ] Document and add extensions like `-extension MIT-SHM` - [ ] Document needed xpra version, test xpra (+clipboard) **Wayland** - [ ] Known security caveats of implementations => stuff that runs on X11 without user knowledge (**login manager**) - [ ] No guarantee or user indication, if applications use Wayland (it may just refuse to do without extra setup like firefox) - [ ] Document how to always start applications with Wayland(GTK,Qt) - [ ] ~~(too much effort) Document how to sandbox XWayland (replace login manager, rewrite session handling in elogind/logind)~~ just disallow X11 - [ ] ~~Need to check with `xlsclients`(requires restart), `xeyes`, `xwininfo`, starting application with `DISPLAY='' app` or `WAYLAND_DEBUG=1 app` in contrast to grepping for display ports~~ hack around with a huge command / upstream stuff to firejail?! - [ ] Application specific mitigations => force Wayland and see, if stuff crashes => then use an alternative - [ ] ~~Many distros dont ship a separate name to indicate that the application definitely uses wayland~~ dont trust distros, they dont even manage to deprecate non-XDGBDS conforming applications - [x] ~~Login managers of distros still all use X11 (session management interaction?)~~ no useless work - [x] ~~Each login manager uses its own scripts for the Wayland and Xwayland session, but default X11 installation setup remains in /etc/X11~~ no useless work

gitea-mirror

2026-05-05 08:57:10 -06:00

closed this issue
added the
wiki
label

gitea-mirror commented

2026-05-05 08:57:13 -06:00

Author

Owner

@matu3ba commented on GitHub (Aug 26, 2020):

The old x11 guide is here and the new one will be here. For now it is more of a stub.

The wiki should live at git@github.com:netblue30/firejail.wiki.git, so I cant push images.
@netblue30 Should I link the images from your x11 guide as github user content or move into a folder wiki/images / doc/image and link from the wiki?

man firejail-config is missing on my distribution(arch-based endeavour) imho.

@matu3ba commented on GitHub (Aug 26, 2020): The old x11 guide is [here](https://firejail.wordpress.com/documentation-2/x11-guide/) and the new one will be [here](https://github.com/netblue30/firejail/wiki/X11-Guide). For now it is more of a stub. The wiki should live at `git@github.com:netblue30/firejail.wiki.git`, so I cant push images. @netblue30 Should I link the images from [your x11 guide](https://firejail.wordpress.com/documentation-2/x11-guide/) as github user content or move into a folder `wiki/images` / `doc/image` and link from the wiki? man firejail-config is missing on my distribution(arch-based endeavour) imho.

gitea-mirror commented

2026-05-05 08:57:14 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 2, 2020):

@rusty-snake Can you review?

I did only find this half-baked scripting solution for synchronizing the clipboard.
The other solution xclipsync did not work for me.

Do you have any idea what to use?

@matu3ba commented on GitHub (Sep 2, 2020): @rusty-snake Can you review? I did only find this [half-baked scripting solution](https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki%27s_EFI_Install_Guide/Sandboxing_the_Firefox_Browser_with_Firejail#Setting_Up_Clipboard_Sharing_and_Display_Rescaling_for_Xephyr) for synchronizing the clipboard. The other solution xclipsync did not work for me. Do you have any idea what to use?

gitea-mirror commented

2026-05-05 08:57:15 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 3, 2020):

I'm on wayland for two years or so. So IDK too much about this, but here are three things I noted:

Why should I use this?: X11 is unsafe, no matter if it is used over an abstract or normal socket is used
How do I get NET? (ip addr show)
You current firejail commandline, will break if e.g falkon.profile does not contains openbox in its ${PATH} (e.g. private-bin is used). The last time I used X11-sandboxing, I started xephyr+openbox in one sandbox and the started e.g falkon in another sandbox and set DISPLAY.

@rusty-snake commented on GitHub (Sep 3, 2020): I'm on wayland for two years or so. So IDK too much about this, but here are three things I noted: 1. `Why should I use this?`: X11 is unsafe, no matter if it is used over an abstract or normal socket is used 2. How do I get `NET`? (`ip addr show`) 3. You current firejail commandline, will break if e.g falkon.profile does not contains openbox in its ${PATH} (e.g. private-bin is used). The last time I used X11-sandboxing, I started xephyr+openbox in one sandbox and the started e.g falkon in another sandbox and set DISPLAY.

gitea-mirror commented

2026-05-05 08:57:16 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 3, 2020):

@rusty-snake Could you exemplify what on X11 remains unsafe, if one uses network namespaces + sandboxing?
Just curious: Do you use Sway, Gnome or tty/no Desktop Environment? For me KDE is very unstable and uses alot CPU on idle.

I fix 2+3 later.

@matu3ba commented on GitHub (Sep 3, 2020): @rusty-snake Could you exemplify what on X11 remains unsafe, if one uses network namespaces + sandboxing? Just curious: Do you use Sway, Gnome or tty/no Desktop Environment? For me KDE is very unstable and uses alot CPU on idle. I fix 2+3 later.

gitea-mirror commented

2026-05-05 08:57:17 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 3, 2020):

IDK if you got me, but I mean the unsafe parts of X11 are not that unrelated to the socket which is used by the sandboxed program.

Could you exemplify what on X11 remains unsafe, if one uses network namespaces + sandboxing?

If you restrict the X11 access of a sandbox to Xephyr (of whatever) it can obviously no longer do bat things like key-logger. So the most holes are closed. X11 is the only reason why we can not use ipc-namespace for graphical programs and almost every flatpak has --share=ipc.

Just curious: Do you use Sway, Gnome or tty/no Desktop Environment? For me KDE is very unstable and uses alot CPU on idle.

I follow the Wayland development of KDE since 2017. kwin_wayland looks good to me. However QT/KDE with Wayland is a torture. Crash, ugly window, broken clipboard, crash again, ... . GTK has full wayland support since 2015. Even firefox has good wayland support since 78 or so (before 78 you had crashes if you left-click on the wrong spot, open add-on pop-overs, ... every release a new crash, but now it's pretty good). To your question I use GNOME. The last time I tried sway (before 1.0, around summer 2018) it was lacking too much features.

@rusty-snake commented on GitHub (Sep 3, 2020): 1. IDK if you got me, but I mean the unsafe parts of X11 are not that unrelated to the socket which is used by the sandboxed program. > Could you exemplify what on X11 remains unsafe, if one uses network namespaces + sandboxing? If you restrict the X11 access of a sandbox to Xephyr (of whatever) it can obviously no longer do bat things like key-logger. So the most holes are closed. X11 is the **only** reason why we can not use `ipc-namespace` for graphical programs and almost every flatpak has `--share=ipc`. > Just curious: Do you use Sway, Gnome or tty/no Desktop Environment? For me KDE is very unstable and uses alot CPU on idle. I follow the Wayland development of KDE since 2017. kwin_wayland looks good to me. However QT/KDE with Wayland is a torture. Crash, ugly window, broken clipboard, crash again, ... . GTK has full wayland support since 2015. Even firefox has good wayland support since 78 or so (before 78 you had crashes if you left-click on the wrong spot, open add-on pop-overs, ... every release a new crash, but now it's pretty good). To your question I use GNOME. The last time I tried sway (before 1.0, around summer 2018) it was lacking too much features.

gitea-mirror commented

2026-05-05 08:57:18 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 3, 2020):

Thanks for the insight.

As I understand it, one can still abuse the shared memory region of the x11-server. Is there more you can think of?
Did you test x11docker (description) yet?
This looks like an excellent tool to compare firejail with.

1+2 I found the option

--hostipc sets docker run option --ipc=host. Allows MIT-SHM / shared memory. Disables IPC namespacing.

We could ~~steal~~ copy the config.

@matu3ba commented on GitHub (Sep 3, 2020): Thanks for the insight. 1. As I understand it, one can still abuse the shared memory region of the x11-server. Is there more you can think of? 2. Did you test [x11docker](https://github.com/mviereck/x11docker) ([description](https://www.researchgate.net/publication/332848180_x11docker_Run_GUI_applications_in_Docker_containers/link/5ccc7caea6fdccc9dd8b333c/download)) yet? This looks like an excellent tool to compare firejail with. 1+2 I found the option ``` --hostipc sets docker run option --ipc=host. Allows MIT-SHM / shared memory. Disables IPC namespacing. ``` We could ~~steal~~ copy the config.

gitea-mirror commented

2026-05-05 08:57:18 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 3, 2020):

IDK if it can abuse the shared-memory of the host-X11-server. However, we can not harden the sandbox with ipc-namespace as long as it uses X11.
No, never used.

@rusty-snake commented on GitHub (Sep 3, 2020): 1. IDK if it can abuse the shared-memory of the host-X11-server. However, we can not harden the sandbox with ipc-namespace as long as it uses X11. 2. No, never used.

gitea-mirror commented

2026-05-05 08:57:19 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 3, 2020):

3. You current firejail commandline, will break if e.g falkon.profile does not contains openbox in its ${PATH} (e.g. private-bin is used). The last time I used X11-sandboxing, I started xephyr+openbox in one sandbox and the started e.g falkon in another sandbox and set DISPLAY.

Do you mean like this?

DISPLAY=":150" firejail Xephyr $DISPLAY
DISPLAY=":150" firefox --no-remote

firemon --x11 returns all possible display numbers and firejail --x11 does return the current display number only as debug output for the user and not scriptable.

@matu3ba commented on GitHub (Sep 3, 2020): > 3. You current firejail commandline, will break if e.g falkon.profile does not contains openbox in its ${PATH} (e.g. private-bin is used). The last time I used X11-sandboxing, I started xephyr+openbox in one sandbox and the started e.g falkon in another sandbox and set DISPLAY. Do you mean like this? ``` DISPLAY=":150" firejail Xephyr $DISPLAY DISPLAY=":150" firefox --no-remote ``` firemon --x11 returns all possible display numbers and `firejail --x11` does return the current display number only as debug output for the user and not scriptable.

gitea-mirror commented

2026-05-05 08:57:20 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 3, 2020):

Something like this, but I don't remember.

firejail --x11=xephyr --net=eth0 openbox &
firejail  --env=DISPLAY=:123 --net=eth0 firefox

@rusty-snake commented on GitHub (Sep 3, 2020): Something like this, but I don't remember. ``` firejail --x11=xephyr --net=eth0 openbox & firejail --env=DISPLAY=:123 --net=eth0 firefox ```

gitea-mirror commented

2026-05-05 08:57:21 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 3, 2020):

Something like this, but I don't remember.
firejail --x11=xephyr --net=eth0 openbox &
firejail  --env=DISPLAY=:123 --net=eth0 firefox

Thats not scriptable, since the status code of the first line $? remains zero and DISPLAY in my shell environment remains ":0".

@matu3ba commented on GitHub (Sep 3, 2020): > Something like this, but I don't remember. > > ``` > firejail --x11=xephyr --net=eth0 openbox & > firejail --env=DISPLAY=:123 --net=eth0 firefox > ``` Thats not scriptable, since the status code of the first line `$?` remains zero and DISPLAY in my shell environment remains ":0".

gitea-mirror commented

2026-05-05 08:57:21 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 4, 2020):

TODOs:

Rewrite xpra section, since a recent version just works.
Package xpra on arch/endeavour?
Document xpra and xephyr incompatibilities of configuration
Figure out, if it is possible to disable MIT-SHM / shared memory on x11, xpra or xephyr
Change firejail --x11 output or firemon --x11 to have a scriptable output

If we can disable MIT-SHM / shared memory and performance is reasonable, we can use IPC namespacing.

@matu3ba commented on GitHub (Sep 4, 2020): TODOs: - [ ] Rewrite xpra section, since a recent version [just works](https://github.com/mviereck/x11docker/issues/257#issuecomment-687058877). - [ ] Package xpra on arch/endeavour? - [ ] Document xpra and xephyr incompatibilities of configuration - [ ] Figure out, if it is possible to disable MIT-SHM / shared memory on x11, xpra or xephyr - [ ] Change `firejail --x11` output or `firemon --x11` to have a scriptable output If we can disable MIT-SHM / shared memory and performance is reasonable, we can use IPC namespacing.

gitea-mirror commented

2026-05-05 08:57:22 -06:00

Author

Owner

@mviereck commented on GitHub (Sep 4, 2020):

Figure out, if it is possible to disable MIT-SHM / shared memory on x11, xpra or xephyr

In Xephyr, just set option -extension MIT-SHM to disable it. (A + would enable it).
xpra does not directly provide an option to disable MIT-SHM, but you can run a custom Xvfb command with disabled MIT-SHM or attach to an already running custom X/Xvfb server.
To disable MIT-SHM on regular Xorg started by a display manager, you can create a file in /etc/X11/xorg.conf.d.
Example:

$ ls /etc/X11/xorg.conf.d/disable-mit-shm.conf
Section "Extensions"
    Option "MIT-SHM" "Disable"
EndSection

You can check for enabled MIT-SHM with xdpyinfo | grep -q "MIT-SHM".

I don't have a solution for Xwayland started by a Wayland compositor.

@mviereck commented on GitHub (Sep 4, 2020): > Figure out, if it is possible to disable MIT-SHM / shared memory on x11, xpra or xephyr In Xephyr, just set option `-extension MIT-SHM` to disable it. (A `+` would enable it). xpra does not directly provide an option to disable MIT-SHM, but you can run a custom Xvfb command with disabled MIT-SHM or attach to an already running custom X/Xvfb server. To disable MIT-SHM on regular Xorg started by a display manager, you can create a file in `/etc/X11/xorg.conf.d`. Example: ``` $ ls /etc/X11/xorg.conf.d/disable-mit-shm.conf Section "Extensions" Option "MIT-SHM" "Disable" EndSection ``` You can check for enabled MIT-SHM with `xdpyinfo | grep -q "MIT-SHM"`. I don't have a solution for Xwayland started by a Wayland compositor.

gitea-mirror commented

2026-05-05 08:57:23 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 8, 2020):

I don't have a solution for Xwayland started by a Wayland compositor.

/usr/bin/Xwayland -help shows an option -extension name Disable extension, but breaks awkwardly the pipe.
~~Since I cant find any other specific paths for KDE, in the Wayland manual or in a search engine, I would assume that the standard paths for x11 configuration are used.~~

Since the manual leaves the option open to define the display variable yourself, this would mean multiple x11 servers which I find dubious (since x11 handles all kind of stuff).
Hence I asked on stackoverflow and will likely contact the x11/Wayland devs to improve their manual.

@matu3ba commented on GitHub (Sep 8, 2020): > I don't have a solution for Xwayland started by a Wayland compositor. `/usr/bin/Xwayland -help` shows an option `-extension name Disable extension`, but breaks awkwardly the pipe. ~~Since I cant find any other specific paths for KDE, in the Wayland manual or in a search engine, I would assume that the standard paths for x11 configuration are used.~~ ~~Since the manual leaves the option open to define the display variable yourself, this would mean multiple x11 servers which I find dubious (since x11 handles all kind of stuff). Hence I [asked on stackoverflow](https://stackoverflow.com/q/63802784/9306292) and will likely contact the x11/Wayland devs to improve their manual.~~

gitea-mirror commented

2026-05-05 08:57:24 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 10, 2020):

For sddm the configuration is in nvim /usr/lib/sddm/sddm.conf.d/default.conf and for my distro it uses /usr/share/sddm/scripts/Xsession for the scripts to start the Xorg session.

It is very annoying that Wayland provides no central place for the Wayland-specific config parts and every login manager has a different place.
At least for x11 there was a convention to place the startup scripts it into /etc/X11/ and the session scripts into xorg.conf.d.

xorg setup commands

# run all system xinitrc shell scripts.
if [ -d /etc/X11/xinit/xinitrc.d ]; then
  for i in /etc/X11/xinit/xinitrc.d/* ; do
  if [ -x "$i" ]; then
    . "$i"
  fi
  done
fi

# Load Xsession scripts
# OPTIONFILE, USERXSESSION, USERXSESSIONRC and ALTUSERXSESSION are required
# by the scripts to work
xsessionddir="/etc/X11/Xsession.d"
OPTIONFILE=/etc/X11/Xsession.options
USERXSESSION=$HOME/.xsession
USERXSESSIONRC=$HOME/.xsessionrc
ALTUSERXSESSION=$HOME/.Xsession

if [ -d "$xsessionddir" ]; then
    for i in `ls $xsessionddir`; do
        script="$xsessionddir/$i"
        echo "Loading X session script $script"
        if [ -r "$script"  -a -f "$script" ] && expr "$i" : '^[[:alnum:]_-]\+$' > /dev/null; then
            . "$script"
        fi
    done
fi

if [ -d /etc/X11/Xresources ]; then
  for i in /etc/X11/Xresources/*; do
    [ -f $i ] && xrdb -merge $i
  done
elif [ -f /etc/X11/Xresources ]; then
  xrdb -merge /etc/X11/Xresources
fi
[ -f $HOME/.Xresources ] && xrdb -merge $HOME/.Xresources

if [ -f "$USERXSESSION" ]; then
  . "$USERXSESSION"
fi

if [ -z "$*" ]; then
    exec xmessage -center -buttons OK:0 -default OK "Sorry, $DESKTOP_SESSION is no valid session."
else
    exec $@
fi

@matu3ba commented on GitHub (Sep 10, 2020): For sddm the configuration is in `nvim /usr/lib/sddm/sddm.conf.d/default.conf` and for my distro it uses `/usr/share/sddm/scripts/Xsession` for the scripts to start the Xorg session. It is very annoying that Wayland provides no central place for the Wayland-specific config parts and every login manager has a different place. At least for x11 there was a convention to place the startup scripts it into `/etc/X11/` and the session scripts into `xorg.conf.d`. <details><summary>xorg setup commands</summary> <p> ```shell # run all system xinitrc shell scripts. if [ -d /etc/X11/xinit/xinitrc.d ]; then for i in /etc/X11/xinit/xinitrc.d/* ; do if [ -x "$i" ]; then . "$i" fi done fi # Load Xsession scripts # OPTIONFILE, USERXSESSION, USERXSESSIONRC and ALTUSERXSESSION are required # by the scripts to work xsessionddir="/etc/X11/Xsession.d" OPTIONFILE=/etc/X11/Xsession.options USERXSESSION=$HOME/.xsession USERXSESSIONRC=$HOME/.xsessionrc ALTUSERXSESSION=$HOME/.Xsession if [ -d "$xsessionddir" ]; then for i in `ls $xsessionddir`; do script="$xsessionddir/$i" echo "Loading X session script $script" if [ -r "$script" -a -f "$script" ] && expr "$i" : '^[[:alnum:]_-]\+$' > /dev/null; then . "$script" fi done fi if [ -d /etc/X11/Xresources ]; then for i in /etc/X11/Xresources/*; do [ -f $i ] && xrdb -merge $i done elif [ -f /etc/X11/Xresources ]; then xrdb -merge /etc/X11/Xresources fi [ -f $HOME/.Xresources ] && xrdb -merge $HOME/.Xresources if [ -f "$USERXSESSION" ]; then . "$USERXSESSION" fi if [ -z "$*" ]; then exec xmessage -center -buttons OK:0 -default OK "Sorry, $DESKTOP_SESSION is no valid session." else exec $@ fi ``` </p> </details>

gitea-mirror commented

2026-05-05 08:57:24 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 10, 2020):

~~Maybe Wayland accepts changes to the Wayland standard for using XDG_BASE.~~ My mail got ignored.

The need of tools like xeyes to check what programs use Xwayland (and conversely Wayland) is very annoying.

Starting XWayland sandboxed would require replacing the graphical login manager + rewriting invoking commands (in elogind or logind) of the display manager.

The rabbit hole of session management is also very deep.

The replacement login manager/display manager can be greetd or writing custom scripts/the Sway way of doing things.

@matu3ba commented on GitHub (Sep 10, 2020): ~~Maybe Wayland accepts changes to the Wayland standard for using XDG_BASE.~~ My mail got ignored. The need of tools like xeyes to check what programs use Xwayland (and conversely Wayland) is very annoying. **Starting XWayland sandboxed would require replacing the graphical login manager + rewriting invoking commands (in elogind or logind) of the display manager.** The rabbit hole of [session management is also very deep](https://github.com/KillingSpark/HowLogindWorks). The replacement login manager/display manager can be [greetd](https://wiki.archlinux.org/index.php/Greetd) or writing custom scripts/the Sway way of doing things.

gitea-mirror commented

2026-05-05 08:57:25 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 17, 2020):

@rusty-snake
Did you ever check with xeyes, if Chromium or Firefox are started on XWayland?

On my OS GTK appears to always start with XWayland (in contrast to Qt applications), which defeats the purpose of using Wayland.

(Firefox is also laggy and cant handle the content on maximizing, when using with KDE + Wayland. I can only use it on one screenside. I did not have issues with Falkon/Qt though.)

@matu3ba commented on GitHub (Sep 17, 2020): @rusty-snake Did you ever check with `xeyes`, if Chromium or Firefox are started on XWayland? On my OS `GTK` appears to always start with XWayland (in contrast to Qt applications), which defeats the purpose of using Wayland. (Firefox is also laggy and cant handle the content on maximizing, when using with KDE + Wayland. I can only use it on one screenside. I did not have issues with Falkon/Qt though.)

gitea-mirror commented

2026-05-05 08:57:26 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 18, 2020):

Did you ever check with xeyes, if Chromium or Firefox are started on XWayland?

I use xlsclients.

On my OS GTK appears to always start with XWayland (in contrast to Qt applications), which defeats the purpose of using Wayland.

Use GDK_BACKEND=wayland CLUTTER_BACKEND=wayland if you want to change this.

(Firefox is also laggy and cant handle the content on maximizing, when using with KDE + Wayland. I can only use it on one screenside. I did not have issues with Falkon/Qt though.)

I can only talk about mutter (GNOME), but here firefox 80 is very stable now. No crashes, flickering, broken clipboard, wrong context-menu, ...

@rusty-snake commented on GitHub (Sep 18, 2020): > Did you ever check with xeyes, if Chromium or Firefox are started on XWayland? I use `xlsclients`. > On my OS GTK appears to always start with XWayland (in contrast to Qt applications), which defeats the purpose of using Wayland. Use `GDK_BACKEND=wayland CLUTTER_BACKEND=wayland` if you want to change this. > (Firefox is also laggy and cant handle the content on maximizing, when using with KDE + Wayland. I can only use it on one screenside. I did not have issues with Falkon/Qt though.) I can only talk about mutter (GNOME), but here firefox 80 is very stable now. No crashes, flickering, broken clipboard, wrong context-menu, ...

gitea-mirror commented

2026-05-05 08:57:26 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 18, 2020):

@rusty-snake
xlsclients -display :1 -a returns only

pc  xeyes

even though xeyes shows vlc to use X11 (uses GTK).

There are also no more apps with such functionality.
Interestingly vlc is still started on XWayland (shown by xeyes).
Qt applications however just work fine.

@matu3ba commented on GitHub (Sep 18, 2020): @rusty-snake `xlsclients -display :1 -a` returns only ``` pc xeyes ``` even though `xeyes` shows vlc to use X11 (uses GTK). There are also no more [apps](https://gitlab.freedesktop.org/xorg/app?page=5) with such functionality. Interestingly vlc is still started on XWayland (shown by xeyes). Qt applications however just work fine.

gitea-mirror commented

2026-05-05 08:57:26 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 19, 2020):

xlsclients -display :1 -a returns only

I know it does not show all programs, on the other can it can show you X11-clints without window such as ibus. You can also use xprop, ... see https://fedoraproject.org/wiki/How_to_debug_Wayland_problems#Does_your_application_run_on_Wayland_natively.2C_or_uses_XWayland_.28X11_compatibility_layer.29.3F

There are also no more apps with such functionality.
Interestingly vlc is still started on XWayland (shown by xeyes).
Qt applications however just work fine.

Maybe the devs force X11 because the have bugs / missing features in wayland (HW-accel?). Or vlc still stuck on qt4.

@rusty-snake commented on GitHub (Sep 19, 2020): > xlsclients -display :1 -a returns only I know it does not show all programs, on the other can it can show you X11-clints without window such as ibus. You can also use xprop, ... see https://fedoraproject.org/wiki/How_to_debug_Wayland_problems#Does_your_application_run_on_Wayland_natively.2C_or_uses_XWayland_.28X11_compatibility_layer.29.3F > There are also no more apps with such functionality. Interestingly vlc is still started on XWayland (shown by xeyes). Qt applications however just work fine. Maybe the devs force X11 because the have bugs / missing features in wayland (HW-accel?). Or vlc still stuck on qt4.

gitea-mirror commented

2026-05-05 08:57:27 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 19, 2020):

@rusty-snake

Setting

enable media.ffmpeg.vaapi.enabled
enable gfx.webrenderer.all
disable media.ffvpx.enabled

mitigated the issues (mostly heavy flickering with javascript or on initial resizing/maximizing the window, which still on initial loading of javascript occurs and then generally disappears after 10-15 sec).
vaapi is for GPU acceleration, which is optional.

xlsclients may require a restart of the system after installation.

@matu3ba commented on GitHub (Sep 19, 2020): @rusty-snake Setting ``` enable media.ffmpeg.vaapi.enabled enable gfx.webrenderer.all disable media.ffvpx.enabled ``` mitigated the issues (mostly heavy flickering with javascript or on initial resizing/maximizing the window, which still on initial loading of javascript occurs and then generally disappears after 10-15 sec). `vaapi` is for GPU acceleration, which is optional. `xlsclients` may require a restart of the system after installation.

gitea-mirror commented

2026-05-05 08:57:27 -06:00

Author

Owner

@matu3ba commented on GitHub (Sep 20, 2020):

@rusty-snake @netblue30

This is expected behavior of Firefox.
"More recent versions of Firefox support opting into Wayland via an environment variable."

The Wayland standard implies probably unsecure applications, because it gives no user indication for its usage. This was just a big waste of time.

Can I write about this in a separate Wayland guide, since this may compromise user security?

@matu3ba commented on GitHub (Sep 20, 2020): @rusty-snake @netblue30 This is [expected behavior of Firefox](https://wiki.archlinux.org/index.php/Firefox#Wayland). "More recent versions of Firefox support opting into Wayland via an environment variable." **The Wayland standard implies probably unsecure applications**, because it gives no user indication for its usage. This was just a big waste of time. Can I write about this in a separate Wayland guide, since this may compromise user security?

gitea-mirror commented

2026-05-05 08:57:28 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 21, 2020):

The Wayland standard implies probably unsecure applications, because it gives no user indication for its usage. … Can I write about this in a separate Wayland guide, since this may compromise user security?

What do you mean exactly?

FYI: Weston and sway can be used w/o XWayland AFAIK and GNOME is 2 or 3 release away from it.

@rusty-snake commented on GitHub (Sep 21, 2020): > The Wayland standard implies probably unsecure applications, because it gives no user indication for its usage. … Can I write about this in a separate Wayland guide, since this may compromise user security? What do you mean exactly? FYI: Weston and sway can be used w/o XWayland AFAIK and GNOME is 2 or 3 release away from it.

gitea-mirror commented

2026-05-05 08:57:28 -06:00

Author

Owner

@matu3ba commented on GitHub (Feb 8, 2021):

What do you mean exactly?

FYI: Weston and sway can be used w/o XWayland AFAIK and GNOME is 2 or 3 release away from it.

Yes. However, many distros have XWayland and Wayland for compatibility. It is however not visually distinguished and easily checkable, if the program uses XWayland or Wayland.

Programs can choose as they please and it would be the distros job to prevent this or ship separate versions. However, few actually do this (due to maintenance costs and no easy way in the standard to check/no simple programs available).

@matu3ba commented on GitHub (Feb 8, 2021): > What do you mean exactly? > > FYI: Weston and sway can be used w/o XWayland AFAIK and GNOME is 2 or 3 release away from it. Yes. However, many distros have XWayland and Wayland for compatibility. It is however not visually distinguished and easily checkable, if the program uses XWayland or Wayland. Programs can choose as they please and it would be the distros job to prevent this or ship separate versions. However, few actually do this (due to maintenance costs and no easy way in the standard to check/no simple programs available).

gitea-mirror commented

2026-05-05 08:57:28 -06:00

Author

Owner

@rusty-snake commented on GitHub (Feb 8, 2021):

Ahhh, so you want to write a warning with some background and suggest to add a include disable-X11.inc to the most <program>.locals which supports it?

blacklist /tmp/.X11-unix
blacklist ${HOME}.Xauthority
blacklist ${RUNUSER}/.mutter-Xwaylandauth*
blacklist /tmp/.ICE-unix
blacklist ${RUNUSER}/ICEauthority
rmenv DISPLAY
rmenv XAUTHORITY

ipc-namespace

@rusty-snake commented on GitHub (Feb 8, 2021): Ahhh, so you want to write a warning with some background and suggest to add a `include disable-X11.inc` to the most `<program>.local`s which supports it? ``` blacklist /tmp/.X11-unix blacklist ${HOME}.Xauthority blacklist ${RUNUSER}/.mutter-Xwaylandauth* blacklist /tmp/.ICE-unix blacklist ${RUNUSER}/ICEauthority rmenv DISPLAY rmenv XAUTHORITY ipc-namespace ```

gitea-mirror commented

2026-05-05 08:57:29 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 4, 2021):

https://github.com/netblue30/firejail/discussions/4451

@rusty-snake commented on GitHub (Aug 4, 2021): https://github.com/netblue30/firejail/discussions/4451

gitea-mirror referenced this issue

2026-05-05 10:16:33 -06:00

[PR #2275] [MERGED] allowing local python* in mpv and youtube-dl #2262 #4247

Rows
Columns

[GH-ISSUE #3602] Wiki: x11 guide #2262