

Gnome Wayland porting – the endgame - bkor
http://blogs.gnome.org/mclasen/2015/01/19/gnome-wayland-porting-the-endgame/

======
gue5t
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.

~~~
hyperion2010
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.

~~~
gue5t
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.

~~~
exDM69
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).

~~~
pjmlp
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.

------
thrownaway2424
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.

~~~
mikekchar
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.

~~~
XorNot
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.

~~~
erglkjahlkh
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.

~~~
josteink
> 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.

~~~
barrkel
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.

------
mindstab
For reference, Mir is _hoped_ to be ready for Ubuntu 16.04...

~~~
chroma
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.

~~~
DonHopkins
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.

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

------
mst
> 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.

~~~
bkor
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.

~~~
reidrac
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.

------
drv
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.

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

~~~
bkor
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".

