> 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.2C_frequent_complaints.2C_fundamental_changes 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 -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/desktop@xxxxxxxxxxxxxxxxxxxxxxx
