The next step is determining which of these features must be
implemented
before we can enable Wayland by default in Fedora Workstation. The plan
is to form a small group of people deeply involved in the Wayland, GNOME
and/or Fedora development to prioritize the list of features and then
draw a line in this prioritized list above which all features must be
complete before we will enable the GNOME desktop on Wayland by default
in our Fedora Workstation project. We can then evaluate this list
during the Fedora 24 development cycle to determine if we are ready to
enable Wayland by default in the alpha, beta and final releases.
Hi, not sure if you want to hear some feedback for this already, or later, but let me add
my thoughts. I've tried to document the most user visible Wayland-related issues on
this wiki page:
https://fedoraproject.org/wiki/How_to_debug_Wayland_problems#Known_issues...
Going through that list and also the wayland features wiki page, these are my current
opinions on their importance when switching to Wayland by default:
* Invalid window placing (everything started in top left corner), invalid child dialog
placing (child dialogs appearing on a different screen, or just very far from the parent
window)
- Needs to be fixed, it's annoying to use this way
* Primary selection
- Contrary to what many people will say, I don't think this needs to be implemented
when going default. A month ago, I was also very critical about this removed feature. A
month later running on Wayland daily, I have to say I don't miss it that much. I
suppose it will be similar with many other people - they will be very vocal at first, but
if they run it for a longer time, they'll realize it's not a big deal. I think it
would be a nice compromise if gnome-terminal emulated this behavior internally (if you
highlight a word, you can paste it back using middle mouse button), but this would only
work inside gnome-terminal and would not touch system clipboard.
* Drag & drop actions
- I think this is needed. It changes/breaks the common behavior in many of standard
desktop apps like Nautilus, and people would be annoyed and confused if they could just
copy and nothing else.
* Sudo with graphical apps
- I think we're going to get much worse publicity with this than primary selection.
Inexperienced Linux users are used to run "sudo gedit", because terminal editors
are unfriendly. Even I, with my years of experience, use "sudo meld" to merge
configuration files, because I don't want to learn vimdiff, and graphical apps can
simply offer a much superior experience. There was a discussion on devel list about this
and everybody talked why running root gui apps is unsafe on X11, but nobody explained why
it is unsafe on Wayland. Polkit and fine-grained permissions were proposed, which is a
good idea, but it's not going to solve all use cases and it's not the current
state of things in many apps. So unless there's a very good reason for deviating from
current common practices, I'd put this onto "needs to be fixed" list. The
more things we break without a really good reason, the more pushback we're going to
get. Maybe this can be improved gradually over time?
* Replacement for many X utilities (xkill, xrandr, xdotool, xsel)
- This is not necessary for going forward, I guess if people miss them, somebody will
appear and write replacements. It would be nice to document what is possible and what is
not in the new world.
* Games issues (mouse locking, relative mouse movement, setting custom resolution,
XFree86-VidModeExtension)
- This is going to be a fun topic. I believe that in order to get people on board, we
can't break people's games. We're finally at point where we have thousands of
great titles available for Linux, and our users get used to it. If we try to steal this
from them, most of these users will stay with X11. Because what's the point of saying
"we support dual graphics well now!" and other Wayland slogans when the games
don't work? We would go back to the time when people didn't want to switch to
Linux because there were no games. So this would be in my "must fix" category.
- For mouse locking and relative mouse movement, we need to design and implement the
protocol and hopefully games don't need to be adjusted, right?
- For custom resolutions, this is going to be harder, IIUIC. Unless we figure out how to
fake the xrandr communication (or whatever the games use) and let them think they have set
a proper resolution (while scaling their output instead), we will need to patch those
games, right? I know recent SDL builds have Wayland support, should that make it magically
work? But how many non-OSS games (Steam games) will get rebuilt? Can we convince Valve to
get developers to rebuild all their games against a newer SDK? And what about those not
using SDL?
- You might think that running a game in desktop resolution with no option to change is no
big deal. But for some people it's a showstopper performance-wise. Some games
don't default to desktop resolution, so they run fixed at e.g. 800x600. Some games
don't support windowed mode which could be used as a backup. I have documented some of
their common behavior at
https://bugzilla.redhat.com/show_bug.cgi?id=1289714 .
* Display rotation support
- Not needed from the beginning, but quite a few people will probably miss it.
* Mouse pointer lagging under load
- This is quite visible and it gives a very bad impression, especially on lower spec
hardware (but it happens even on state of the art hardware). If we want to convince people
Wayland is good, this needs to be fixed.
* Glitches and bugs
- Mouse pointer disappearing, key events repeated, alt+tab focus issues, gnome-shell
freezes, windows being resized when defocused. All these bugs need to be fixed, they are
very visible and inconvenient when they occur, and they are not that rare.
* Remote display
- Not needed from the beginning, because I don't think it's that much used. We
don't do a good job on X11 either (VNC is very suboptimal).
* Kinetic scrolling
- Not that important, should not block.
* Tablet support
- This is I believe currently not important from Fedora POV. Should not block.
* Accessibility features
- If X11 session will stay available and it can be easily selected from login screen even
by people with some disability, I think this doesn't need to be a day 1 feature.
* Dual graphics, outputs on secondary GPUs
- On day 1, I think we don't need to be more feature complete here than X11. So if
don't actually break stuff compared to X11, I think that's fine in the beginning.
Kamil