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.

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

Already on GitHub? Sign in to your account

Plasma: Experimental Wayland support #30610

Merged
merged 2 commits into from Oct 20, 2017
Merged

Conversation

ttuegel
Copy link
Member

@ttuegel ttuegel commented Oct 20, 2017

Motivation

Upstream has indicated that they no longer test Plasma on Xorg. This is still experimental; the default Plasma session in NixOS will still run under Xorg.

To start a Plasma session on Wayland,

# Switch to a console with Ctrl-Alt-Fn

# Stop the display manager so D-Bus does not get confused
sudo systemctl stop display-manager

# Start a Plasma session in Wayland
startplasmacompositor >plasma-wayland.log 2>&1

I have performed only minimal testing because Wayland is extremely unstable on my hardware (amdgpu driver + multiple displays). There do not seem to be any missing packages. Some programs even work under Wayland! Bug reports are welcome, bug fixes even more so! 馃槈

Testing

  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

We no longer have a separate `startkde` script; instead we patch the script
which comes with `plasma-workspace`. The primary reason to do this is that we
have not been keeping up with the minor bugfixes that the upstream script
receives. A secondary reason is: now that we support Wayland, we don't really
want to have a separate package for each session script.
@ttuegel ttuegel self-assigned this Oct 20, 2017
@ttuegel ttuegel merged commit ae8d9cb into NixOS:master Oct 20, 2017
@peterhoeg
Copy link
Member

FWIW, on a Yoga 2 Pro with intel graphics and the modesetting driver, plasma comes up and is perfectly usable. I'll try it as the daily driver for work tomorrow.

Only issue is that systemd user units cannot run graphical programs but I'm guessing that has to do with the WAYLAND_DISPLAY variable not being set.

@ttuegel
Copy link
Member Author

ttuegel commented Oct 22, 2017

Only issue is that systemd user units cannot run graphical programs but I'm guessing that has to do with the WAYLAND_DISPLAY variable not being set.

That is by design! systemd user units are not for running graphical programs. You probably want an XDG autostart file instead. The session manager (ksmserver for Plasma) will take care of those. Besides not running on console sessions, XDG autostart entries let you filter based on session type, e.g. you can pick certain programs to start only in a Plasma session, or only in a Gnome session, etc.

I know that NixOS encourages using user units for everything because it provides a declarative interface, but it's really not what they're for.

@ttuegel
Copy link
Member Author

ttuegel commented Oct 22, 2017

Yoga 2 Pro with intel graphics and the modesetting driver

BTW, remember modesetting is an Xorg driver, so that shouldn't have any effect. AFAICT, the KWin compositor uses KMS+Mesa in all cases.

@peterhoeg
Copy link
Member

remember modesetting is an Xorg driver

Indeed, that was a brain fart on my side.

That is by design! systemd user units are not for running graphical programs

I don't think that's true. Upstream KDE is (or was at least) ref http://web.archive.org/web/20170219035853/http://blog.davidedmundson.co.uk/blog/systemd-and-plasma contemplating rejigging startkde/kinit to use systemd user units to spawn its processes rather than doing it itself.

And not only that, it works! This comment is written inside of an a KDE plasma session spawned from sddm using firefox run as a systemd user session, so it looks like we're getting closer!

In order to get proper support, it looks like we need to rework quite a bit of the sddm and services.xserver infrastructure to separate out the bits that are X specific and move them into a non-X specific namespace.

My ugly hack to get to sddm to spawn plasma wayland: https://gist.github.com/0180264db635408d58fb6b9a143f0614

A few things that aren't working (as a FYI):

  • font anti-aliasing isn't enabled in konsole
  • the plasma pager simply doesn't show (known issue)
  • we need a proper script as sessioncommand that does systemctl --user import-environment DISPLAY WAYLAND_DISPLAY
  • my custom keymaps are gone

@ttuegel
Copy link
Member Author

ttuegel commented Oct 23, 2017

I don't think that's true. Upstream KDE is (or was at least) ref http://web.archive.org/web/20170219035853/http://blog.davidedmundson.co.uk/blog/systemd-and-plasma contemplating rejigging startkde/kinit to use systemd user units to spawn its processes rather than doing it itself.

They have been talking about doing this for a long time with X and Wayland, but AFAICT they have never shipped a systemd unit to replace startkde or startplasmacompositor. IOW, at this time, XDG autostart is the way to go.

we need a proper script as sessioncommand that does systemctl --user import-environment DISPLAY WAYLAND_DISPLAY

If these variables are set and exported in startplasma before dbus-update-activation-environment --systemd, then they should be imported. I believe DISPLAY already is for Xwayland to work.

my custom keymaps are gone

Wayland will be using libinput. Plasma has partial support for configuring libinput, but nothing like what was available under Xorg.

font anti-aliasing isn't enabled in konsole

I didn't catch that because I'm using Alacritty. Could you open an issue? It could be a NixOS problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants