Gnome Wayland porting – the endgame | Hacker News Reader

Gnome Wayland porting – the endgame

blogs.gnome.org

145 pointsbkor70 comments

Does Wayland have an input method story? Last I heard, GNOME was telling users that ibus was the only supported input method for their software; ibus doesn't have the same feature set or flexibility as my current setup, which involves switching between fcitx and XIM dynamically. Plus, what about being able to accessibly enter text into things other than ibus-bound GNOME applications?

I've heard talk of a Wayland port of fcitx, but I could never get it to do anything at all, and it sounds like GNOME might not support it even if it does work?

I'd love to hear how this all is supposed to work from someone who knows what's going on.

Apparently libinput is what is going to handle Wayland input and the X team is already moving to add it as an input option to x11 to ease the transition.

Libinput is a low-level library that handles and normalizes evdev (kernel) events. "Input methods" here refers to high-level ways of interpreting various devices' events to produce text input for programs that accept text: on-screen keyboards, predictive input, pinyin, and so on.

Also plain old keyboard input is an important part of this. Dealing with international keyboard layouts is anything but trivial. E.g. to write ñ on my keyboard layout (fi), I need to press AltGr+~ and then n. In X11, this is handled by the XIM library.

There's no shortage of applications that do this incorrectly.

Particularly annoying are some games which don't get this right. The key for ", ^ and ~ is a "dead" key (doesn't produce any character output, to write ~ you press AltGr+~ and then space) which is where the US keyboard has ]. Lots of games use [] for something important, and this completely fails to work on my key layout.

For game keyboard input, the game should use "raw" scan codes (which are keyboard specific) for all configurable keys. Ie. not "keysyms" and especially not character codes.

International keyboard handling is very difficult. I was talking about a mostly western key layout, I don't even want to know what it's like to deal with non-western keyboard layouts (russian, greek, chinese, japanese, etc).

One of my pains on the early GNU/Linux days (slackware 2.0 and beyond) was to configure the keyboard for Portuguese both on the console and on X.

Almost as fun as finding out the right modes not to burn the monitor.

> International keyboard handling is very difficult. I was talking about a mostly western key layout, I don't even want to know what it's like to deal with non-western keyboard layouts (russian, greek, chinese, japanese, etc).

The difficulty here is getting things like dead keys, key combinations (AltGr) and Compose right. Everything after that simply generates a Unicode string in the application. At which point the script is irrelevant. In fact, the difficult parts here happen completely below anything that needs text, so language or script is a non-issue at that point.

Why not have said "high level" methods available at a low level? What if I want to write Chinese in my config files while editing with vi on a tty running through the system fb console?

does anyone know if it will solve the consistent copy-paste shortcut problem in Linux. Yes, I know we cant use ctrl-c .... but the lack of consistency which I see on OSX is frustrating.

I'm curious: Why do you switch between fcitx and XIM? What are the advantages of one over the other, and in what situations?

Most input methods, including fcitx, don't follow the user-specified compose-key sequences in ~/.XCompose, but XIM specifically does. In the other direction, fcitx supports C-S-u NNN to enter characters by codepoint value but XIM doesn't. For the trifecta of compose-key, pinyin, and one-off symbols I haven't found anything better than switching off.

We almost got the old thing half-working, time to switch to the new totally-not-working thing! I love you, free software.

Recently I switched from Ubuntu's awful default whatever they call it to plain X11 with every newfangled thing disabled, and fvwm2. My satisfaction with my computer's performance is almost back to where it was in 1998 when my computer had 1% of these resources and for some reason double the performance. I'm definitely not looking forward to the next next thing unless it has a really great performance story incorporating all the lessons that whoever works on this stuff should have learned in the last 20 years.

Like you I have removed almost everything "Desk Top Environment" recently and have been enjoying the increased resources I get. I similarly hate that everything is getting intertwined so much that it is hard to actually pick and choose applications without taking a huge amount of cruft with it.

Having said that, if you look at the list of people working on Wayland it is quite impressive. As it contains a good number of core X windows developers, you would be hard pressed to argue that they don't understand the trade-offs that they are introducing. And while I haven't had time to play with it in any real depth, I've looked at Mutter's API and it is quite nice. Finally, I've actually tried Wayland (with Gnome and on top of Mutter by itself) and while there were still some problems at the time (about 3 months ago), I was actually able to get a full day's work done without much complaint. In fact, it is snappy and responsive and it mostly works.

I like exporting my X displays through ssh, so I really don't know if I will use Wayland seriously any time soon, but I think it is a good prospect for people who aren't me. I like the fact that this update from the Gnome guys shows that they are thinking, "Hey maybe not everybody will dump X. Let's try to find a place where we can showcase Wayland with the least inconvenience to conservative people".

IMHO, this kind of development is nothing but good. The real question is if Red Hat will take a less heavy hand in deployment of this as opposed to other "Let's reinvent the world" projects. As an option, I'm extremely happy to have it. If it gets wrapped up in everything so that I can't use any popular software without it, then I will be unhappy. But so far I see no signs of that.

Exporting X via SSH is still ultimately a bad user experience, since it's not portable.

The thing we desperately need is a desktop-session (Mutter-level) VNC server that will operate behind a lockscreen, so you can export a remote desktop locally or remotely and have it persist between logins.

As long as it supports root windowless mode, whatever works is fine for me. Also, it must work out of the box on most common distributions, without requiring extra software installation. Configuration is fine though, not even X11 forwarding is enabled on many platforms by default.

I have sadly seen nothing of value in Wayland that would be worth losing X11 over SSH forwarding. I really need some similar feature, and I am not aware of anything usable being available with Mir or Wayland. VNC doesn't cut it unless it can export single windows.

I am well aware that X11 tunneling is an aged piece of technology that is in serious need of facelift, but the new alternative to X11 should match the functionality. Before that happens, I will keep uninstalling Wayland and Mir, because the critical requirements (for me and my environments) have not been met.

> I am well aware that X11 tunneling is an aged piece of technology that is in serious need of facelift, but the new alternative to X11 should match the functionality

But many of the performance problems of X11 is rooted directly in features most of the user-base no longer uses (X11 as a network protocol being the prime example) and the work on a new protocol is being made specifically by eliminating the tradeoffs introduced by those features.

I welcome a newer, more performant option, but I guess it won't have anything to offer for your concerns.

Converting API calls into network messages is usually still a better option than something like VNC, which just tries to copy across images of the screen. Put VNC side by side with Windows RDP, and RDP's advantage is usually very clear. Unless many heavy assets need to be processed by the API before it can composite the screen, sending API calls ought to be better. Fancy 3D effects etc. in particular should be much smoother.

The bigger issue with X11 is its backwards server / client orientation. That optimizes for a rare scenario, and makes the more common situation - where you want to connect to an existing session with a bunch of running apps, and disconnect from it without blowing everything away - much more awkward to configure.

I believe the main advantage is that wayland enables better access to hardware acceleration, at least once Nvidia and AMD implement support for egl.

Weston already supports RDP (including desktop sharing). I believe newer versions of RDP can support a root windowless mode (so I'm not sure if Weston's RDP currently supports this).

NX pretty much does this, and works much better than VNC or ordinary X forwarding.

NX doesn't get the love it deserves

NoMachine's NX (the original) is a proprietary product in a free-software world. That doesn't really surprise me.

x2go is really nice, and is free software: http://wiki.x2go.org/doku.php/start

Like GP I am using an older desktop, OpenBox+ROX Filer, basically the same desktop I was using in 1999. Very fast over remote, maximally fast locally. Doubt I'll ever change.

The core NX compression technology was available to everyone up until 3.5.0. This sparked x2go, neatx, freenx and opennx. Are there any more derivatives to add to that list which we should thank NX for?

X forwarding is not really secure anyway if you are using it on an untrusted remote machine.

If you are an admin on a server and someone logs in with X forwarding then you can access his X server easily without any limitation (keylogger, screenshots, etc...).

Not sure i see how that can be fixed in software, if the attacker has control over the hardware (or sit closer to it than the software you are using).

The point being made here is that if I run an xterm on your machine (forwarded to the X server on my machine), then you can now access everything happening in the X server on my machine.

Noted. What puzzles me is that this has not been sorted in all the years, without doing a complete ground up recreation...

Well, back in the mid-90's we had lots of fun with it in the university.

Specially since most students didn't even bothered to configure xauth and xhost properly.

Weston has a VNC server built in. Then if you have a desktop environment which uses Weston you'll be able to use VNC.

What has been added to the spec is being able to run one "compositor" in another. So you can have KDE/Enlightment running within/under Weston. I don't think that is the approach taken by GNOME though.

Not sure if it'll be session specific or not.

> Exporting X via SSH is still ultimately a bad user experience, since it's not portable.

I'm not sure what you mean by 'not portable' you can have X server on Windows..

And 'Wayland' export is even worse as it depends on whether the Wayland compositor support the export or not, AFAIK Weston is the only one which currently have an export display backend. I think that you're suggesting to "stack" compositor to avoid this issue (not a new idea), I hope that this is what will happen eventually..

I believe he meant sessions being portable across devices. You cannot start a X application on your laptop, disconnect, switch to your desktop, continue using the application. (At least, it does not easily work out of the box. Allegedly it is possible in certain scenarios.)

VNC and other on-top approaches can do this (even with Wayland).

Not to sound cliche, but try Gentoo. It takes a bit of getting used to be it's concept of USE Flags are designed exactly because of "everything is getting intertwined so much that it is hard to actually pick and choose applications".

At the very least wayland can simply be used as a underlying graphics driver via XWayland, allowing for GPU acceleration of the whole of the X session without having to muck around with questionable WM hacks etc.

Switch to FreeBSD, seriously. We don't always have the new shiny things that ubuntu or linux generally does, but it's rock solid; everything continues to work and the interfaces don't keep changing for no reason.

After recently seeing several articles related to FreeBSD (one of them was the Digital Ocean intro for linux users) I decided to play with FreeBSD 10.1 in virtual box. I liked pkgng, the "compactness" of the OS and several other features and after I successfully installed Xfce and Mate I decided to give FreeBSD a try on the bare metal, to see how it performs compared to Ubuntu and how many devices will recognize of the various devices (especially the Broadcom wifi which gave me some head aches under linux) on my Lenovo Yoga 2 11. The experience was very short. I was not able to boot any of the memstick FreeBSD images. 'Fatal trap 1 : privileged instruction fault' in the first milliseconds. After some investigation I had to give up cause there was no apparent easy way to bypass this panic. I knew that FreeBSD hardware support is behind Linux hw support but in my case it was very disappointing. Overall I like FreeBSD principles but I can't find any good use of it in virtual box (it's a step forward though, I remember that some previous FreeBSD version failed to boot even in virtual box).

I've been toting around a custom fvwm2 config for 12+ years now, and every year or two I look at new features, then do a little research for how someone accomplished the same or similar in fvmw2, and modify it for my own needs (or just write it from scratch if needed). It makes for an interesting diversion for a day, and everything works exactly as I like it.

I've been using windows for the past two years, but prior to that people that sat with me for a minute while I did something would often comment "wow, what are you using?" The kicker was that the comment wasn't because it looked super great, but because it was effective and efficient. I found that much more satisfying than if they just liked how it looked.

Jamie Zawinski's CADT[1] observation is relevant again. We are perpetually stuck on version 0.8.

[1][http://www.jwz.org/doc/cadt.html]

Fedora is cutting edge experimental distro. So yes.

I hear this type of opinion from time to time, and I honestly don't understand where it comes from. My computer back in 1998 didn't do nearly as much as my machine today, and yet my machine today responds to everything almost instantly. It's probably an order of magnitude faster than the Linux desktop that I had in 1998.

he's referring to Ubuntu's desktop, which, IIRC, is GNOME 3. You could have the latest CPU and 500 GB of RAM, and GNOME 3 will find a way to make it crawl. I always switch to XFCE now. But fvwm2 would also be quite an improvement.

Linux desktop in 1998 was super snappy. As long as you didn't expect much in the way of latest 3d graphics card drivers.

Nope, Ubuntu uses Unity, not GNOME 3.

For reference, Mir is hoped to be ready for Ubuntu 16.04...

Wait, they're still hanging on to that!?

The ubuntu phone is based on it, so they will be hanging onto it for a while.

Is there any chance for an actual device? (Except for flashing it onto a Nexus phone?)

Coming in early 2015:

http://www.pcworld.com/article/2861446/ubuntu-phone-launch-d...

To be fair, Wayland seems similarly hopeful about shipping in Fedora 23, which is only 4 months before Ubuntu 16.04. Also, Canonical has a big incentive to ship Mir in 16.04, since it's a long term support release. If they don't make it, they'll be forced to support X for an extra 5 years.

I think both projects have equally "hopeful" (slim) chances of hitting their dates. If they do ship on time, I expect stability and features to suffer.

I'll take "Suffering Stability and Features" for $500, Alex. As long as I can bet everything on chance to get rid of X 5 years sooner.

They've always said they'll continue supporting X after Mir ships anyway.

Wayland has been around, I think, at least 3 years before Mir's announcement, though. It's had plenty of time to evolve naturally without any fixed corporate goals necessitating them to act fast.

It's also worth noting that many of the changes required when switching out the display server (moving stuff out of X and into the kernel, adding features to drivers) was done while developing Wayland. Mir doesn't have to worry about this stuff, so they should be able to do it much quicker than the time it has taken Wayland to mature.

It sounds like whatever supersedes waylan should have a much easier time. Hows that for planning.

this.

I cant seem to find a .deb + bleeding edge Gnome system anywhere. Ubuntu Gnome is what I use right now, but Fedora 22 is so good that it is making me jealous.

I would pay money to get a Debian based Gnome distro which is constantly updated. And now that is even more critical as Ubuntu goes off in Mir territory while the rest of the world go to Wayland.

Debian Testing or Unstable?

I tried to get on the Debian bandwagon, but it is so unfriendly that it is not funny. I know it is built around a philosophy, but I seriously encourage everyone to try out Fedora 21 Workstation to really see what a great Linux experience can feel like.

Why did you feel it was unfriendly?

This is great, congratulations and thanks to everyone who's been working on this stuff!

> The login screen is pretty self-contained and we don’t have to worry about application compatibility or support for exotic devices. And we will get Wayland to run on (almost) all systems this way, which should give a lot more exposure and help shake out lingering bugs and hardware issues.

Let's test the exciting new technology by making it a dependency of ... being able to log in.

I. Um. This seems ... unwise.

What do you sugest?

The reverse would be wiser: put the login session on Wayland after the Wayland session is stable: if there are bugs in the Wayland session the users could easily use other sessions.. But Fedora devs aren't especially known for caring about the users' pain, remember KDE4.0?

The Wayland session is already available. It just lacks features. That's why the next step is the login manager. Though from reading the latest discussion on fedora-devel, there might be a few complications to correctly automatically fall back to X.

> It just lacks features.

Does it work on NVidia closed source driver? I thought that this wasn't the case yet..

I only learned this recently: Red Hat is working with NVidia, only expected to work around Fedora 23 release. I've switched quite a while ago to the nouveau driver. Next machine will probably have an Intel. I'm waiting for something which is quiet, doesn't use too much power and can drive an Ultra HD monitor at 60fps without any hacks (seems to require HDMI 2.0).

This is more thought out than it might appear. In various Fedora releases you can already test GNOME under Wayland. Due to Wayland, certain functionality is not available. The one case which is not resolved yet is the "color picker" from anywhere on the screen. This as security wise you don't want applications to determine the screen content of other applications.

So the switch is actually gradual:

  1. Now: Optional GNOME Wayland session (with slightly less functionality)
  2. Wayland login session in development distribution
  3. QA testing (Fedora has a big QA team)
  4. Go/no go decision
  5. GNOME Wayland login session in stable distribution
  6. Repeat 2-5 for Wayland as default session (for next distribution version)

The login session doesn't use the functionality that might be different between releases. That is why to proceed with testing Wayland, login session is a better test than knowingly reducing functionality.

I'm aiming to also have the Mageia development version switch to using Wayland for GDM. A lot of people use that and we (Mageia) often notice bugs quite quickly.

The problem is that the process is good for the software but it won't be good for the users in the early iterations.

I use Fedora at home and I love it, but sometimes it is a little bit too experimental and in this case I'm afraid it might not be usable (Fedora has shipped broken things in the past that I would qualify as "release blockers", but the release team have a different opinion).

Things settle in the sweet spot (eventually), but with every upgrade is like "what will be broken this time", and that's not a pleasant end-user experience.

If 3+4 are done sensibly, it's possibly not that terrible.

But I think in that case there should be a boot option of some sort to get a non-wayland login session, just in case.

The login screen is much simpler and controlled than the full session. Its much more likely to work than a full session where you can run any application and do anything. Sounds like a pretty good starting point, much better than introducing it for the whole session.

I'm sure there will be a way to disable it to work around issues, but this way we get broad testing while not risking the stability of people actually trying to get their real work done (after logging in).

How is XWayland doing these days? Last time I heard anything about it, it sounded like GLX programs didn't work yet, which would be a major impediment to switching fully to Wayland. Lots of older programs (especially games) won't ever be ported to use the new Wayland APIs, so compatibility is important.

QT 5 supoorts Wayland. these "maybe" is false.

You're reading too much into it. GTK+3.x has supported Wayland for various versions already. Fully supporting everything required changes (additions) to Wayland (the spec). There's still a few things missing in Wayland for GTK+ to support everything. Qt support, we're (=GNOME) not the ones to know.

Aside from that, this bit is probably about if we set environment variables to prefer/force Wayland backend, or leave it up to toolkits to discover. For GNOME to change behaviour of Qt might not be a good idea (or maybe it is :-P). As such, "maybe".

Reply on news.ycombinator.com