We are working toward enabling the GNOME desktop on Wayland as the default for the Fedora Workstation project. The question is: What features do we have to complete in order to make this switch? Everyone seems to have their own ideas of what is required, and a systematic approach is needed to organize the effort.
Over the years, many features have been developed for the traditional X11-based GNOME desktop, and we are bringing these features over to the Wayland-based version. Quite a few of these features have already been implemented for the Wayland-based desktop and we already have highly functional desktop experience that everyone can use, but it is not yet complete. In order for us to enable it by default we need to both implement the missing features and fix the bugs in features that are already complete.
For the bugs, we simply need to fix them. However, the situation with features is more complex. We each have our own list of features that we believe need to be implemented, but we lack a complete list of all the missing features and a clear way to determine when we have implemented enough of them to enable the Wayland-based GNOME desktop by default.
Toward that goal, we are consolidating all of the various feature lists in the following Fedora wiki page:
https://fedoraproject.org/wiki/Wayland_features
We are putting this on the Fedora wiki (instead of a GNOME, Wayland, kernel, Freedesktop or other wiki) since this is a Fedora decision on when we feel the Wayland-based GNOME desktop is ready to be the default for our Fedora Workstation project.
The initial step is to list all features for the Wayland-based GNOME desktop. Olivier Fourdan, who has been heavily involved in the upstream Wayland development and also involved in GNOME development activities, has agreed to maintain this page. If you have ideas for what features should be included, please add them to the wiki page and discuss them on this list.
What we need for each missing or incomplete feature is a descriptive name and what stage of development it is in. Links to other pages where more detailed description of the feature status and implementation details are also welcomed. For the development stages, there are kernel, supporting libraries, Wayland protocol, XWayland, mutter, gtk+ and application levels. For example, tablet support is currently implemented in the kernel and supporting libraries. The protocol has been proposed and is under discussion. Once the protocol has been accepted, there will be additional development needed at higher levels. This feature will remain on the list until it is complete at all levels.
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.
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...
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
On 9 Dec 2015 10:39, "Kamil Paral" kparal@redhat.com wrote:
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...
I don't know whether this is a missing feature, bug or just my ignorance (I assume the latter), but I've been unable to configure my trackball under Wayland the way I like under X. From what I've read it looks like it ought to be possible. I asked about it on Ask Fedora Project, but so far I've drawn a blank: https://ask.fedoraproject.org/en/question/78865/wayland-libinput-marble-mous...
Cheers, R
On Wed, Dec 9, 2015 at 3:39 AM, Kamil Paral kparal@redhat.com wrote:
https://fedoraproject.org/wiki/How_to_debug_Wayland_problems#Known_issues.2C...
I'm skeptical. I have my own personal "blockers", but it's really just that fact there's a long list that's the problem. There are enough "blockers" and "important" items missing that something or other will adversely affect a broad range of users. That strikes me as not ready for prime time as a default.
The design SIG may have very different opinions on what is "blocking" for their group, but if they can make X default for their spin, that might mitigate their concern. Same for a games spin (?). For example, tablet support, display rotation, and dual graphics are pretty basic in the design world. Anyone using those these things, depend on them, and won't just bypass Fedora 24 but would probably even opt out of a lot of testing. It's just not at all aligned with their workflow.
If this is all understood and acceptable, then by all means push through with it by default, and hopefully by Fedora 25 it's definitely feature complete. But if there's some good chance that won't happen until Fedora 26, I think that's asking too many people to skip too many releases. Users skipping one release isn't surprising, but two rapidly is suboptimal.
On Wed, 2015-12-09 at 05:39 -0500, Kamil Paral wrote:
- Display rotation support
- Not needed from the beginning, but quite a few people will probably miss it.
For whatever it's worth, this is a showstopper for me on my main test box (this one); I just can't run Wayland on it until this is fixed. So I'll be running with X11 until this is done, regardless of what's the default.
On Wed, Dec 16, 2015 at 3:10 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2015-12-09 at 05:39 -0500, Kamil Paral wrote:
- Display rotation support
- Not needed from the beginning, but quite a few people will probably miss it.
For whatever it's worth, this is a showstopper for me on my main test box (this one); I just can't run Wayland on it until this is fixed. So I'll be running with X11 until this is done, regardless of what's the default.
What is meant by display rotation support? Changing from portrait to landscape without a reboot? Or does it mean portrait isn't supported at all? For me, I use a laptop without external attached sometimes and can do some Wayland testing. But mostly I connect to a display rotated to portrait orientation. I don't tend to rotate it landscape though.
On Wed, 2015-12-16 at 15:36 -0700, Chris Murphy wrote:
On Wed, Dec 16, 2015 at 3:10 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2015-12-09 at 05:39 -0500, Kamil Paral wrote:
- Display rotation support
- Not needed from the beginning, but quite a few people will probably miss it.
For whatever it's worth, this is a showstopper for me on my main test box (this one); I just can't run Wayland on it until this is fixed. So I'll be running with X11 until this is done, regardless of what's the default.
What is meant by display rotation support? Changing from portrait to landscape without a reboot? Or does it mean portrait isn't supported at all? For me, I use a laptop without external attached sometimes and can do some Wayland testing. But mostly I connect to a display rotated to portrait orientation. I don't tend to rotate it landscape though.
Wayland itself has rotation support, but GNOME provides no interface for it. I have this vague memory that I somehow managed to get a Wayland session to rotate its displays with xrandr somehow, but I've never managed to replicate that; apart from that one time (if it really happened...) I haven't found any way to rotate the display from a GNOME-on-Wayland session in Fedora. Wayland doesn't really have the concept of server-level configuration like X, there's no xorg.conf you can go to and configure rotation the way you can with X; AIUI, in the Wayland world, that's supposed to happen at the compositor/desktop level.
On Wed, Dec 16, 2015 at 4:00 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2015-12-16 at 15:36 -0700, Chris Murphy wrote:
On Wed, Dec 16, 2015 at 3:10 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2015-12-09 at 05:39 -0500, Kamil Paral wrote:
- Display rotation support
- Not needed from the beginning, but quite a few people will probably miss it.
For whatever it's worth, this is a showstopper for me on my main test box (this one); I just can't run Wayland on it until this is fixed. So I'll be running with X11 until this is done, regardless of what's the default.
What is meant by display rotation support? Changing from portrait to landscape without a reboot? Or does it mean portrait isn't supported at all? For me, I use a laptop without external attached sometimes and can do some Wayland testing. But mostly I connect to a display rotated to portrait orientation. I don't tend to rotate it landscape though.
Wayland itself has rotation support, but GNOME provides no interface for it. I have this vague memory that I somehow managed to get a Wayland session to rotate its displays with xrandr somehow, but I've never managed to replicate that; apart from that one time (if it really happened...) I haven't found any way to rotate the display from a GNOME-on-Wayland session in Fedora. Wayland doesn't really have the concept of server-level configuration like X, there's no xorg.conf you can go to and configure rotation the way you can with X; AIUI, in the Wayland world, that's supposed to happen at the compositor/desktop level.
Hmmm well if the display isn't fakaked, which is actually surprisingly infrequent (i.e. it is fakaked), via EDID it should inform the OS (if it asks) what the orientation is so the OS can just do the right thing. I have a display in a box about 20 feet away that does the right thing. Maybe....hmmm....MAYbE I should get it outta the box? And I don't know, test it? Egads. I know it works on X, but ONLY with the discrete GPU. Integrated GPU, no go.
On Wed, 2015-12-16 at 16:16 -0700, Chris Murphy wrote:
Hmmm well if the display isn't fakaked, which is actually surprisingly infrequent (i.e. it is fakaked), via EDID it should inform the OS (if it asks) what the orientation is so the OS can just do the right thing. I have a display in a box about 20 feet away that does the right thing. Maybe....hmmm....MAYbE I should get it outta the box? And I don't know, test it? Egads. I know it works on X, but ONLY with the discrete GPU. Integrated GPU, no go.
These are desktop displays. They don't know which way up they are, they can't tell the OS.
On Wed, Dec 16, 2015 at 5:06 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2015-12-16 at 16:16 -0700, Chris Murphy wrote:
Hmmm well if the display isn't fakaked, which is actually surprisingly infrequent (i.e. it is fakaked), via EDID it should inform the OS (if it asks) what the orientation is so the OS can just do the right thing. I have a display in a box about 20 feet away that does the right thing. Maybe....hmmm....MAYbE I should get it outta the box? And I don't know, test it? Egads. I know it works on X, but ONLY with the discrete GPU. Integrated GPU, no go.
These are desktop displays. They don't know which way up they are, they can't tell the OS.
Yeah I'm talking about desktop displays that pivot, either landscape or portrait. Any display, pivoting or fixed, is supposed to be able to communicate it's h and v resolution and hence orientation. As far as I know, the fixed ones all communicate this correctly. The pivoting ones don't always do that, or it could be a graphics card or driver or window server miscommunication.
On Wed, Dec 16, 2015, 10:05 PM Chris Murphy lists@colorremedies.com wrote:
On Wed, Dec 16, 2015 at 5:06 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2015-12-16 at 16:16 -0700, Chris Murphy wrote:
Hmmm well if the display isn't fakaked, which is actually surprisingly infrequent (i.e. it is fakaked), via EDID it should inform the OS (if it asks) what the orientation is so the OS can just do the right thing. I have a display in a box about 20 feet away that does the right thing. Maybe....hmmm....MAYbE I should get it outta the box? And I don't know, test it? Egads. I know it works on X, but ONLY with the discrete GPU. Integrated GPU, no go.
These are desktop displays. They don't know which way up they are, they can't tell the OS.
Yeah I'm talking about desktop displays that pivot, either landscape or portrait. Any display, pivoting or fixed, is supposed to be able to communicate it's h and v resolution and hence orientation. As far as I know, the fixed ones all communicate this correctly. The pivoting ones don't always do that, or it could be a graphics card or driver or window server miscommunication.
I'm not sure if it communicates via EDID or DDCI, but it definitely communicates it via either a DVI, mDP or adapter connection because all I do on OS X is pivot this display the way I want and the OS changes the signal it sends. There's no UI for this on OS X either. So the lack of UI in GNOME doesn't tell me if it'll work out bit with Wayland.
-- Chris Murphy
On Wed, 2015-12-16 at 15:00 -0800, Adam Williamson wrote:
Wayland itself has rotation support, but GNOME provides no interface for it. I have this vague memory that I somehow managed to get a Wayland session to rotate its displays with xrandr somehow, but I've never managed to replicate that; apart from that one time (if it really happened...)
This is not really factually true.
The Wayland protocol does not have display configuration (ie the equivalent to XRANDR). GNOME shell provides a D-Bus interface for display configuration which is what drives the control-center display panel, and that D-Bus interface does support rotation.
The X11 implementation in mutter is translating it into XRANDR and does support rotation. The Wayland implementation translates it into libdrm calls, and does not support rotation yet.
I could also quibble with the notion that "I happen to use a rotated monitor on my system, so rotation is a test blocker", but thats probably not worth it... clearly rotation needs to be supported, and I believe Carlos and Florian have recently discussed the some plans for implementing it. Carlos, Florian - is that correct ?
On Thu, 2015-12-17 at 08:40 -0500, Matthias Clasen wrote:
On Wed, 2015-12-16 at 15:00 -0800, Adam Williamson wrote:
Wayland itself has rotation support, but GNOME provides no interface for it. I have this vague memory that I somehow managed to get a Wayland session to rotate its displays with xrandr somehow, but I've never managed to replicate that; apart from that one time (if it really happened...)
This is not really factually true.
The Wayland protocol does not have display configuration (ie the equivalent to XRANDR). GNOME shell provides a D-Bus interface for display configuration which is what drives the control-center display panel, and that D-Bus interface does support rotation.
The X11 implementation in mutter is translating it into XRANDR and does support rotation. The Wayland implementation translates it into libdrm calls, and does not support rotation yet.
OK, I must've had it garbled. The result's the same, anyhow.
I could also quibble with the notion that "I happen to use a rotated monitor on my system, so rotation is a test blocker",
Well, feel free to quibble with that notion, but it's not what I said - I just said that it was a blocker for my daily use, because I'm not going to use non-rotated displays. I didn't say it was a "test blocker".
OK so this has broken for me in Fedora 23, using X. Wayland might be worse, hard to see how though.
On Thu, Dec 17, 2015 at 02:33:35PM -0700, Chris Murphy wrote:
OK so this has broken for me in Fedora 23, using X. Wayland might be worse, hard to see how though.
Looks like a duplicate of this one:
On Thu, 2015-12-03 at 10:47 -0500, Kevin E Martin wrote:
The next step is determining which of these features must be implemented before we can enable Wayland by default in Fedora Workstation.
To make a start on this, here is my own assessment of the list from the wiki. I'm not too confident that discussing this on the list is going to yield great results, but here it goes:
1 - blocker 2 - important 3 - not important 4 - works today, or NAKed
2 1 remote display 4 2 screencast 1 3 primary selection 1 4 dnd actions 2 5 Other dnd features 2 6 kinetic scrolling 1 7 input methods 2 8 on-screen keyboard 2 9 relative/locking pointer confinement 4 10 hi-dpi support 3 11 attached modal dialogs 1 12 tablet support 1 13 startup notification 1 14 clipboard proxy for xwayland 1 15 touch proxy for xwayland 2 16 accessibility features 2 17 output rotation 4 18 XRandR control of Wayland outputs 3 19 Device and Driver information 4 20 screensaver control 3 21 Xfree86-VidModeExtension in Xwayland 3 22 XVideo extension in Xwayland 3 23 Optional surface IDs 3 24 Hotplug USB devices 2 25 Outputs on secondary GPUs 4 26 Window size hints
On 9 Dec 2015, at 18:19, Matthias Clasen mclasen@redhat.com wrote:
On Thu, 2015-12-03 at 10:47 -0500, Kevin E Martin wrote:
The next step is determining which of these features must be implemented before we can enable Wayland by default in Fedora Workstation.
To make a start on this, here is my own assessment of the list from the wiki. I'm not too confident that discussing this on the list is going to yield great results, but here it goes:
1 - blocker 2 - important 3 - not important 4 - works today, or NAKed
2 1 remote display 4 2 screencast 1 3 primary selection 1 4 dnd actions 2 5 Other dnd features 2 6 kinetic scrolling 1 7 input methods 2 8 on-screen keyboard 2 9 relative/locking pointer confinement 4 10 hi-dpi support 3 11 attached modal dialogs 1 12 tablet support 1 13 startup notification 1 14 clipboard proxy for xwayland 1 15 touch proxy for xwayland 2 16 accessibility features 2 17 output rotation 4 18 XRandR control of Wayland outputs 3 19 Device and Driver information 4 20 screensaver control 3 21 Xfree86-VidModeExtension in Xwayland 3 22 XVideo extension in Xwayland 3 23 Optional surface IDs 3 24 Hotplug USB devices 2 25 Outputs on secondary GPUs 4 26 Window size hints -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
Apologies for top posting, but iPhone :(
I want to ask why is tablet support critical?
Is this a primary market for Fedora? Also is there a range of supported tablets that can run Fedora as a production OS? If yes, can someone point me to some information? I am sincerely curious.
Abis
On Wed, Dec 9, 2015 at 1:45 PM, Alex Bisogiannis alexixor@gmail.com wrote:
On 9 Dec 2015, at 18:19, Matthias Clasen mclasen@redhat.com wrote:
On Thu, 2015-12-03 at 10:47 -0500, Kevin E Martin wrote:
The next step is determining which of these features must be implemented before we can enable Wayland by default in Fedora Workstation.
To make a start on this, here is my own assessment of the list from the wiki. I'm not too confident that discussing this on the list is going to yield great results, but here it goes:
1 - blocker 2 - important 3 - not important 4 - works today, or NAKed
2 1 remote display 4 2 screencast 1 3 primary selection 1 4 dnd actions 2 5 Other dnd features 2 6 kinetic scrolling 1 7 input methods 2 8 on-screen keyboard 2 9 relative/locking pointer confinement 4 10 hi-dpi support 3 11 attached modal dialogs 1 12 tablet support 1 13 startup notification 1 14 clipboard proxy for xwayland 1 15 touch proxy for xwayland 2 16 accessibility features 2 17 output rotation 4 18 XRandR control of Wayland outputs 3 19 Device and Driver information 4 20 screensaver control 3 21 Xfree86-VidModeExtension in Xwayland 3 22 XVideo extension in Xwayland 3 23 Optional surface IDs 3 24 Hotplug USB devices 2 25 Outputs on secondary GPUs 4 26 Window size hints -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
Apologies for top posting, but iPhone :(
I want to ask why is tablet support critical?
Is this a primary market for Fedora? Also is there a range of supported tablets that can run Fedora as a production OS? If yes, can someone point me to some information?
This is a guess on my part, but it might be more "hybrid laptop" than "pure tablet". The existence of Yoga, Surface, and iPad Pro like devices is increasing, and people are going to naturally want to be able to use them in both modes.
josh
On Wed, Dec 9, 2015 at 10:51 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Dec 9, 2015 at 1:45 PM, Alex Bisogiannis alexixor@gmail.com wrote:
[...]
Apologies for top posting, but iPhone :(
I want to ask why is tablet support critical?
Is this a primary market for Fedora? Also is there a range of supported tablets that can run Fedora as a production OS? If yes, can someone point me to some information?
This is a guess on my part, but it might be more "hybrid laptop" than "pure tablet". The existence of Yoga, Surface, and iPad Pro like devices is increasing, and people are going to naturally want to be able to use them in both modes.
I think "tablet support" here refers to wacom graphic tablets, not iPad-like tablets.
Cheers,
Giovanni
On Wed, Dec 09, 2015 at 11:49:13AM -0800, Giovanni Campagna wrote:
On Wed, Dec 9, 2015 at 10:51 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Dec 9, 2015 at 1:45 PM, Alex Bisogiannis alexixor@gmail.com wrote:
[...]
Apologies for top posting, but iPhone :(
I want to ask why is tablet support critical?
Is this a primary market for Fedora? Also is there a range of supported tablets that can run Fedora as a production OS? If yes, can someone point me to some information?
This is a guess on my part, but it might be more "hybrid laptop" than "pure tablet". The existence of Yoga, Surface, and iPad Pro like devices is increasing, and people are going to naturally want to be able to use them in both modes.
I think "tablet support" here refers to wacom graphic tablets, not iPad-like tablets.
correct, this is about graphics tablets/drawing tablets/Wacom tablets, however you want to call them, not the iPad-style tablets. It's an unfortunate ambiguity, we're trying to use "graphics tablets" in most places these days but old habits die hard :)
Cheers, Peter
On Thu, Dec 3, 2015 at 4:47 PM, Kevin E Martin kem@redhat.com wrote:
The next step is determining which of these features must be implemented before we can enable Wayland by default in Fedora Workstation.
That's the wrong way to look at it ... the question should be "when do the benefits outweigh the drawbacks" .. given that the only user visible benefit is better hidpi support just implementing a subset of that features is not good enough. The end result would simply be a worse user experience.
Here is a status update on the various blocker and important tasks that we've identified a while ago.
primary selection
Lyude send a proposed protocol+implementation to the wayland mailing list in December, there was quite a bit of discussion into early January, but no clear consensus on the desired changes to the protocol. Carlos has GTK+/mutter implementations of the proposed protocol. Incomplete :-(
input methods
The current IBus implementation using D-Bus on the client-side works fine under Wayland. A small problem is that the candidate window is not correctly positioned. Rui has a fix for this problem. The gnome-shell part of the fix is in 3.19.90, the IBus side is supposed to get merged upstream soon too.
tablet support
The various tabet protocol and support patches have seen many iterations on the wayland mailing list, but haven't landed yet. Incomplete.
startup notification
Carlos has a minimal implementation gnome-shell and gtk+, adding a new request to the private gtk-shell interface. Incomplete.
clipboard proxy for xwayland touch proxy for xwayland
These are in place and should work, modulo bugs.
remote display
Jonas has a workng vnc implementation that is alpha quality. Waiting for damage reporting in pinos and for a pinos release.
Other dnd features
Pretty much all done. Only missing feature is drop-on-root, which is important for detaching tabs in gnome-terminal and firefox. Should be easy to add though.
kinetic scrolling
Done.
On-screen keyboard
Making the on-screen keyboard work requires the text protocol. v2 of this protocol is under discussion on the wayland list. Rui is still planning on getting text protocol support into 3.20. Incomplete. relative/locking pointer confinement
Merged this week, will be in 3.19.90.
accessibility features
Not done.
output rotation
Partially done. Rotation that is implemented in hw / drivers works, but we don't have software fallback. Hw support for rotation is somewhat rare, so: Incomplete.
Outputs on secondary GPUs
Not done.
Matthias Clasen wrote:
Here is a status update on the various blocker and important tasks that we've identified a while ago.
primary selection
Lyude send a proposed protocol+implementation to the wayland mailing list in December, there was quite a bit of discussion into early January, but no clear consensus on the desired changes to the protocol. Carlos has GTK+/mutter implementations of the proposed protocol. Incomplete :-(
input methods
The current IBus implementation using D-Bus on the client-side works fine under Wayland. A small problem is that the candidate window is not correctly positioned. Rui has a fix for this problem. The gnome-shell part of the fix is in 3.19.90, the IBus side is supposed to get merged upstream soon too.
tablet support
The various tabet protocol and support patches have seen many iterations on the wayland mailing list, but haven't landed yet. Incomplete.
startup notification
Carlos has a minimal implementation gnome-shell and gtk+, adding a new request to the private gtk-shell interface. Incomplete.
clipboard proxy for xwayland touch proxy for xwayland
These are in place and should work, modulo bugs.
remote display
Jonas has a workng vnc implementation that is alpha quality. Waiting for damage reporting in pinos and for a pinos release.
Other dnd features
Pretty much all done. Only missing feature is drop-on-root, which is important for detaching tabs in gnome-terminal and firefox. Should be easy to add though.
kinetic scrolling
Done.
On-screen keyboard
Making the on-screen keyboard work requires the text protocol. v2 of this protocol is under discussion on the wayland list. Rui is still planning on getting text protocol support into 3.20. Incomplete.
relative/locking pointer confinement
Merged this week, will be in 3.19.90.
accessibility features
Not done.
" I've noticed that in gnome 3.18, orca works quite well in wayland. The only exceptions seem to be that the desktop icons are not drawn (known bug) and that it can occasionally be more memory intensive (gnome-shell) and that it can be slow when selecting multiple icons in nautilus. The one major thing I've seen some discussion on hear is that the gnome devs consider the at-spi socket a major security risk and want a redesign, because it allows anyone or anything to send pretty much anything to it an through it with basically no checking or authenticating done. I'm guessing this isn't in 3.20 since it would require a ton of work, but does anyone know whether this is on the todo for 3.22? If so I can start commenting on the bug or wiki pages, if I can figure out how to leave comments on the wiki. And if not, I can file bugs for this so they're in the system. Thanks Kendell clark"
output rotation
Partially done. Rotation that is implemented in hw / drivers works, but we don't have software fallback. Hw support for rotation is somewhat rare, so: Incomplete.
Outputs on secondary GPUs
Not done.
desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
desktop@lists.stg.fedoraproject.org
-
Adam Williamson -
Alexander Bisogianis -
Chris Murphy -
Chuck Anderson -
drago01 -
Giovanni Campagna -
Josh Boyer -
Kamil Paral -
kendell clark -
Kevin E Martin -
Matthias Clasen -
Peter Hutterer -
Richard Turner