Wayland driver development - December 2021 update and next steps
Hi everyone! Since the last Wayland driver update [1] a lot of work has been done to improve the functionality and stability of the Wine Wayland driver, and to provide a cleaner and more reviewable/upstreamable patchset. The driver has now reached a point where it would benefit from wider community testing. In the mailing list discussions earlier this year it was recommended that we go through wine-staging as a stepping stone towards upstream. To this end, I have prepared a patchset and attached it to the existing bug for a Wayland driver, as per the wine-staging guidelines, at: https://bugs.winehq.org/show_bug.cgi?id=42284 This is intended to be an active patchset, meaning that it will receive updates regularly, as feedback is received and issues are fixed. Development will continue in the development branch (currently at [2]) which will be used as the canonical source for any updated patchsets for wine-staging. The vast majority (but not all) of the commits in the series affect only the driver itself. However, there is still a lot of surface area, mostly in terms of interfaces used to interact with Wine core, that could lead to broken code when upstream is updated. This has been more pronounced the last few weeks with the various changes in the driver interface. I will be tracking upstream and providing updated patchsets as needed and as timely as I can. I want to make sure that this patchset will not cause undue burden on the wine-staging maintainers. However, if the maintainers feel that this patchset will make life difficult for them, I am open to different ideas about how to move this driver towards upstream. A related question now that holiday season is approaching: what happens if a wine-staging patch breaks due to an upstream change, such that it requires intervention from the original author, but this is not provided in time for the next release? Is the patchset disabled for that wine-staging release and re-enabled when fixed? Let me stress again that my aim is to track upstream and respond in a timely manner, but sometimes this is not possible, and I want to be clear about how the situation is handled. --- Now, some information about the state of the driver. First of all a non-exhaustive list of what's supported, minus bugs: * Window state handling: resizing, maximization, minimization (often no proper minimized window contents, though), fullscreen. * OpenGL and Vulkan (including using wined3d and DXVK). * Display mode changes (emulated with compositor scaling, rather than real display hardware mode changes). * Multiple monitors. * Mouse capture/clipping/relative motion (but note that Wayland compositors don't tend to deal with non-fullscreen cases very well). * Popups, menus and other transient windows (except when cross-process, see below). * Keymaps set/updated from the Wayland compositor should work transparently. * HiDPI scaling (configurable to use either application/wine or compositor scaling). * Copy/paste both ways, drag and drop in the direction from native Wayland to Wine. * Systray (minus right-click menu positioning, see below). TL;DR of how to use the development branch: $ git clone -b wayland https://gitlab.collabora.com/alf/wine/ $ cd wine $ ./configure --with-wayland [--with-vulkan --with-vkd3d] $ make [-jN] $ DISPLAY= WAYLAND_DISPLAY=wayland-0 ./wine ... There are some known cases where the driver doesn't work properly, that I think deserve an explicit mention since they may trip people up. The first is when applications try to render to window created by another process. Although this not a typical scenario, it's how Chrome/Chromium and thus applications using CEF, including some game store apps, work. For now, the workaround is to instruct the application to use "in-process" GPU handling (with the "--in-process-gpu" command-line) or turn-off GPU rendering completely (typically with "--disable-gpu --disable-software-rasterizer"). For example, one can run GOG Galaxy with: "GalaxyClient.exe --in-process-gpu [--use-angle=d3d11]" Some applications launch a separate CEF process internally, so passing the flag in the command line doesn't work, it needs to be passed to the CEF process instead. I have had some good results with detecting and overriding the arguments in CreateProcessInternalW (e.g., Rockstar Launcher), but of course that's a complete hack. I am trying to find a way to resolve this issue, but the solution is still an open question, and could require a Wayland extension, although there other (more complex) possibilities I need to explore further. The second case involves the standalone systray included in the driver, based on the one from winex11. Due to the context/right-click menu being drawn from a process different from the one owning the systray window, the driver heuristics to anchor the window to its effective Wayland surface parent don't work. The practical effect is that the menu is rendered as a Wayland toplevel and thus placed by the Wayland compositor at arbitrary locations on screen (although it's still usable). Finally, please note that although there are certainly still bugs in the Wayland driver, Wayland compositors also have their share fair of issues (my main testing happens on Weston, GNOME and occasionally kwin). So, please try to use a recent version of your favorite compositor, so that you can enjoy the best possible experience. Thanks, Alexandros [1] https://www.winehq.org/pipermail/wine-devel/2021-June/188412.html [2] https://gitlab.collabora.com/alf/wine/-/commits/wayland
Hi Alexandros, On 12/10/21 20:56, Alexandros Frantzis wrote:
In the mailing list discussions earlier this year it was recommended that we go through wine-staging as a stepping stone towards upstream.
Do you recall which part of the prior discussion made such an impression? Staging used to be a testing ground for some patches, yes, but as far as I know no patchset was ever easier to get accepted upstream because of its presence in Staging. Nor that ever was a requirement for any patches to get upstream. So in this regard it would be probably more interesting to get some opinion if the direction the things are being implemented now is acceptable for upstream and Staging probably can't help with that. I am not talking for the primary Staging maintainers now and they may decide differently, but I personally doubt having it Staging is feasible. It is a huge thing (I doubt there is a precedent of similarly sized and scoped patchset in Staging) and I doubt any of Staging maintainers is ready to routinely rebase it. Additionally, Wine is currently in process of huge display driver interfacing redesign, which means the patchset will be disabled most of the time. On a separate note it is not obvious how the presence of the driver in Staging is universally useful. It can't yet be enabled by default apparently. So probably it will be still tested only by people who want to do it specifically but then they already can do that easily by dropping in the external driver.
On Fri, Dec 10, 2021 at 09:44:23PM +0300, Paul Gofman wrote:
Hi Alexandros,
Hi Paul, Thanks for the feedback!
On 12/10/21 20:56, Alexandros Frantzis wrote:
In the mailing list discussions earlier this year it was recommended that we go through wine-staging as a stepping stone towards upstream.
Do you recall which part of the prior discussion made such an impression? Staging used to be a testing ground for some patches, yes, but as far as I know no patchset was ever easier to get accepted upstream because of its presence in Staging. Nor that ever was a requirement for any patches to get upstream. So in this regard it would be probably more interesting to get some opinion if the direction the things are being implemented now is acceptable for upstream and Staging probably can't help with that.
My understanding was based on a discussion earlier the year, see for example the thread at: https://www.winehq.org/pipermail/wine-devel/2021-February/181667.html Of course, the circumstances have changed since then, and it could be the case that going through wine-staging is not the most productive way forward anymore. The question then is, given that the driver is already quite capable (with some documented inherent Wayland related limitations) and split in easily digestible/reviewable commits, what more can I do to help people form an opinion about the overall direction, so that we can move forward?
I am not talking for the primary Staging maintainers now and they may decide differently, but I personally doubt having it Staging is feasible. It is a huge thing (I doubt there is a precedent of similarly sized and scoped patchset in Staging) and I doubt any of Staging maintainers is ready to routinely rebase it. Additionally, Wine is currently in process of huge display driver interfacing redesign, which means the patchset will be disabled most of the time.
I agree that maintaining this patchset in staging is a lot of work (and currently a pain due to the driver updates). As mentioned in my original email, if this is still the recommended way forward, I am willing to put in the effort to keep the patchset up to date as well as possible. That being said, I am also happy to move forward in a different direction (e.g., direct to upstream or something else) if upstream and staging maintainers find it more acceptable and feasible. Not going through staging is likely to be easier for all involved, but it's ultimately not my choice to make.
On a separate note it is not obvious how the presence of the driver in Staging is universally useful. It can't yet be enabled by default apparently. So probably it will be still tested only by people who want to do it specifically but then they already can do that easily by dropping in the external driver.
That's a good point. I think Zebediah originally suggested that we could turn this on by default in staging, and this is certainly something I could enable. On the other hand, given the cost of maintaining it in staging, perhaps this doesn't provide any advantage compared to moving directly to upstream, where people could just try it out by simply setting the right environment variables [1]. Thanks, Alexandros [1] DISPLAY= WAYLAND_DISPLAY=wayland-0
On 12/10/21 23:05, Alexandros Frantzis wrote:
On Fri, Dec 10, 2021 at 09:44:23PM +0300, Paul Gofman wrote:
Hi Alexandros, Hi Paul,
Thanks for the feedback!
On 12/10/21 20:56, Alexandros Frantzis wrote:
In the mailing list discussions earlier this year it was recommended that we go through wine-staging as a stepping stone towards upstream. Do you recall which part of the prior discussion made such an impression? Staging used to be a testing ground for some patches, yes, but as far as I know no patchset was ever easier to get accepted upstream because of its presence in Staging. Nor that ever was a requirement for any patches to get upstream. So in this regard it would be probably more interesting to get some opinion if the direction the things are being implemented now is acceptable for upstream and Staging probably can't help with that. My understanding was based on a discussion earlier the year, see for example the thread at:
https://www.winehq.org/pipermail/wine-devel/2021-February/181667.html
Of course, the circumstances have changed since then, and it could be the case that going through wine-staging is not the most productive way forward anymore.
Yeah, I see... I don't think anything changed. I think it would be best if Zebediah would comment directly but I suppose the meaning of her older comment is that she's not against seeing it in Staging if there is a clear understanding that something along the lines of present implementation can go upstream. Maybe it might be a good way for some riksy patches to get some prior testing before the patches get finalized and go upstream but (correct me please if I am wrong) I don't think upstream maintainers recommended patches to go to Staging first or otherwise indicated that it is a shorter or preferred way for patches to go upstream.
On 12/10/21 14:30, Paul Gofman wrote:
On 12/10/21 23:05, Alexandros Frantzis wrote:
On Fri, Dec 10, 2021 at 09:44:23PM +0300, Paul Gofman wrote:
Hi Alexandros, Hi Paul,
Thanks for the feedback!
On 12/10/21 20:56, Alexandros Frantzis wrote:
In the mailing list discussions earlier this year it was recommended that we go through wine-staging as a stepping stone towards upstream. Do you recall which part of the prior discussion made such an impression? Staging used to be a testing ground for some patches, yes, but as far as I know no patchset was ever easier to get accepted upstream because of its presence in Staging. Nor that ever was a requirement for any patches to get upstream. So in this regard it would be probably more interesting to get some opinion if the direction the things are being implemented now is acceptable for upstream and Staging probably can't help with that. My understanding was based on a discussion earlier the year, see for example the thread at:
https://www.winehq.org/pipermail/wine-devel/2021-February/181667.html
Of course, the circumstances have changed since then, and it could be the case that going through wine-staging is not the most productive way forward anymore.
Yeah, I see... I don't think anything changed. I think it would be best if Zebediah would comment directly but I suppose the meaning of her older comment is that she's not against seeing it in Staging if there is a clear understanding that something along the lines of present implementation can go upstream. Maybe it might be a good way for some riksy patches to get some prior testing before the patches get finalized and go upstream but (correct me please if I am wrong) I don't think upstream maintainers recommended patches to go to Staging first or otherwise indicated that it is a shorter or preferred way for patches to go upstream.
I don't think I'd assert that patches, however large or small, *should* go through wine-staging as a "stepping stone" to upstream. I wouldn't see wine-staging as an end goal or even a necessary step. I'd rather look at it as a tool; essentially a way of getting broad testing. In essence, the same reason that staging branches exist in any project. Thus I'm not sure that the sheer existence of a patch has helped its credibility upstream—it might have happened, but I haven't heard of it. On the other hand, I can name several patches which have benefited greatly from user testing while in wine-staging, such that a lot of bugs were flushed out by that time. ntdll-Junction_Points, Rémi's raw input patches, Andrew's winepulse timing rework, and my own server-default-integrity and ntdll-NtAlertThreadByThreadId are several such cases. I can't speak for Alexandros, but if this is his goal in proposing the driver for wine-staging, I don't have any objections, at least on those grounds. And, frankly, when we're talking about an entire USER driver, I can anticipate that the testing that wine-staging provides would be quite useful. I do have some other thoughts, but I'll have to defer them for a separate email.
On Fri, Dec 10, 2021 at 06:46:46PM -0600, Zebediah Figura wrote:
On 12/10/21 14:30, Paul Gofman wrote:
On 12/10/21 23:05, Alexandros Frantzis wrote:
On Fri, Dec 10, 2021 at 09:44:23PM +0300, Paul Gofman wrote:
Hi Alexandros, Hi Paul,
Thanks for the feedback!
On 12/10/21 20:56, Alexandros Frantzis wrote:
In the mailing list discussions earlier this year it was recommended that we go through wine-staging as a stepping stone towards upstream. Do you recall which part of the prior discussion made such an impression? Staging used to be a testing ground for some patches, yes, but as far as I know no patchset was ever easier to get accepted upstream because of its presence in Staging. Nor that ever was a requirement for any patches to get upstream. So in this regard it would be probably more interesting to get some opinion if the direction the things are being implemented now is acceptable for upstream and Staging probably can't help with that. My understanding was based on a discussion earlier the year, see for example the thread at:
https://www.winehq.org/pipermail/wine-devel/2021-February/181667.html
Of course, the circumstances have changed since then, and it could be the case that going through wine-staging is not the most productive way forward anymore.
Yeah, I see... I don't think anything changed. I think it would be best if Zebediah would comment directly but I suppose the meaning of her older comment is that she's not against seeing it in Staging if there is a clear understanding that something along the lines of present implementation can go upstream. Maybe it might be a good way for some riksy patches to get some prior testing before the patches get finalized and go upstream but (correct me please if I am wrong) I don't think upstream maintainers recommended patches to go to Staging first or otherwise indicated that it is a shorter or preferred way for patches to go upstream.
I don't think I'd assert that patches, however large or small, *should* go through wine-staging as a "stepping stone" to upstream. I wouldn't see wine-staging as an end goal or even a necessary step. I'd rather look at it as a tool; essentially a way of getting broad testing. In essence, the same reason that staging branches exist in any project.
Thus I'm not sure that the sheer existence of a patch has helped its credibility upstream—it might have happened, but I haven't heard of it. On the other hand, I can name several patches which have benefited greatly from user testing while in wine-staging, such that a lot of bugs were flushed out by that time. ntdll-Junction_Points, Rémi's raw input patches, Andrew's winepulse timing rework, and my own server-default-integrity and ntdll-NtAlertThreadByThreadId are several such cases.
I can't speak for Alexandros, but if this is his goal in proposing the driver for wine-staging, I don't have any objections, at least on those grounds. And, frankly, when we're talking about an entire USER driver, I can anticipate that the testing that wine-staging provides would be quite useful.
I do have some other thoughts, but I'll have to defer them for a separate email.
Hi Zebediah (and Paul)! The primary reason for proposing the driver to wine-staging is that I was under the impression (which seems to be mistaken), that there was a strong recommendation to do so for this particular patchset, before proposing to upstream. As you mentioned, wine-staging could be a useful tool for broader user testing, which is indeed one of my goals. However, I think such testing could also be enabled by having the driver in upstream and allowing users to easily opt in at runtime (see my proposal below). Of course, as Paul mentions, a prerequisite for upstreaming is that upstream has decided that the direction of the driver is acceptable. This has been been one of my primary goals during the whole development effort, by implementing a wide range of features, leading to a quite capable driver at this point (within noted Wayland constraints). A big part of the work since the last report also aims to facilitate such an assessment of direction, by splitting and structuring the commits to make them more easily digestible and reviewable. Perhaps wine-staging could play a role in the assessment of direction, but, then again, the whole driver has been available and easily buildable from my repository from the start, for anyone to examine and try out. Given the above, it seems to me that the benefits of wine-staging could be gained through a different path, and in combination with the concerns about the overall cost of maintaining such a big patchset in wine-staging, I am now leaning more towards a direct-to-upstream approach. My proposal would be: 1. Establish that the direction of the driver is acceptable for upstream. Do people think we haven't reached that point yet (and, if so, how can we get there)? Who could provide a final acknowledgment? 2. After the 7.0 freeze, start upstreaming the driver. As noted, I structured the commits in the 'wayland' branch specifically for ease of review and upstreaming, so the rough plan is that I will be proposing chunks of commits from that branch (mostly in order) until all of it is upstream. 3. The Wayland driver will have a lower precedence than the X11 driver, so X11/Xwayland will continue to be used by default when available. This will make it easy for distributions to include the Wayland driver in their normal package builds without compromising their stable user experience, while still allowing all users to easily try the Wayland driver (e.g., by unsetting DISPLAY). This would allow for broader testing compared to wine-staging. 4. Development continues, with the benefit of being in upstream, which is more likely to attract additional contributions, compared to just being a patchset in wine-staging. What do you think? Thanks, Alexandros
On 12/12/21 19:13, Alexandros Frantzis wrote:
On Fri, Dec 10, 2021 at 06:46:46PM -0600, Zebediah Figura wrote:
On 12/10/21 14:30, Paul Gofman wrote:
On 12/10/21 23:05, Alexandros Frantzis wrote:
On Fri, Dec 10, 2021 at 09:44:23PM +0300, Paul Gofman wrote:
Hi Alexandros, Hi Paul,
Thanks for the feedback!
On 12/10/21 20:56, Alexandros Frantzis wrote:
In the mailing list discussions earlier this year it was recommended that we go through wine-staging as a stepping stone towards upstream. Do you recall which part of the prior discussion made such an impression? Staging used to be a testing ground for some patches, yes, but as far as I know no patchset was ever easier to get accepted upstream because of its presence in Staging. Nor that ever was a requirement for any patches to get upstream. So in this regard it would be probably more interesting to get some opinion if the direction the things are being implemented now is acceptable for upstream and Staging probably can't help with that. My understanding was based on a discussion earlier the year, see for example the thread at:
https://www.winehq.org/pipermail/wine-devel/2021-February/181667.html
Of course, the circumstances have changed since then, and it could be the case that going through wine-staging is not the most productive way forward anymore.
Yeah, I see... I don't think anything changed. I think it would be best if Zebediah would comment directly but I suppose the meaning of her older comment is that she's not against seeing it in Staging if there is a clear understanding that something along the lines of present implementation can go upstream. Maybe it might be a good way for some riksy patches to get some prior testing before the patches get finalized and go upstream but (correct me please if I am wrong) I don't think upstream maintainers recommended patches to go to Staging first or otherwise indicated that it is a shorter or preferred way for patches to go upstream.
I don't think I'd assert that patches, however large or small, *should* go through wine-staging as a "stepping stone" to upstream. I wouldn't see wine-staging as an end goal or even a necessary step. I'd rather look at it as a tool; essentially a way of getting broad testing. In essence, the same reason that staging branches exist in any project.
Thus I'm not sure that the sheer existence of a patch has helped its credibility upstream—it might have happened, but I haven't heard of it. On the other hand, I can name several patches which have benefited greatly from user testing while in wine-staging, such that a lot of bugs were flushed out by that time. ntdll-Junction_Points, Rémi's raw input patches, Andrew's winepulse timing rework, and my own server-default-integrity and ntdll-NtAlertThreadByThreadId are several such cases.
I can't speak for Alexandros, but if this is his goal in proposing the driver for wine-staging, I don't have any objections, at least on those grounds. And, frankly, when we're talking about an entire USER driver, I can anticipate that the testing that wine-staging provides would be quite useful.
I do have some other thoughts, but I'll have to defer them for a separate email.
Hi Zebediah (and Paul)!
The primary reason for proposing the driver to wine-staging is that I was under the impression (which seems to be mistaken), that there was a strong recommendation to do so for this particular patchset, before proposing to upstream.
As you mentioned, wine-staging could be a useful tool for broader user testing, which is indeed one of my goals. However, I think such testing could also be enabled by having the driver in upstream and allowing users to easily opt in at runtime (see my proposal below).
Of course, as Paul mentions, a prerequisite for upstreaming is that upstream has decided that the direction of the driver is acceptable. This has been been one of my primary goals during the whole development effort, by implementing a wide range of features, leading to a quite capable driver at this point (within noted Wayland constraints). A big part of the work since the last report also aims to facilitate such an assessment of direction, by splitting and structuring the commits to make them more easily digestible and reviewable.
Perhaps wine-staging could play a role in the assessment of direction, but, then again, the whole driver has been available and easily buildable from my repository from the start, for anyone to examine and try out.
Given the above, it seems to me that the benefits of wine-staging could be gained through a different path, and in combination with the concerns about the overall cost of maintaining such a big patchset in wine-staging, I am now leaning more towards a direct-to-upstream approach.
My proposal would be:
1. Establish that the direction of the driver is acceptable for upstream. Do people think we haven't reached that point yet (and, if so, how can we get there)? Who could provide a final acknowledgment?
Ultimately the decision is up to Alexandre. Based on his prior response it doesn't seem out of the question, but it also seems like it depends on whether the Wayland driver is better in any concrete sense than using the winex11 driver plus XWayland. E.g. does it provide access to features only available via Wayland? (Are there any? I vaguely remember that HDR is one, because apparently that one was too hard to retrofit into X11.) Or better rendering performance? Not being excessively ugly is probably also a prerequisite. I haven't yet got a chance to review the code to make a guess of this (although I'm planning to), although personally I don't have a lot familiarity with USER drivers and I wouldn't trust my judgement anyway. Jacek or Huw might be able to give a better review in this respect.
2. After the 7.0 freeze, start upstreaming the driver. As noted, I structured the commits in the 'wayland' branch specifically for ease of review and upstreaming, so the rough plan is that I will be proposing chunks of commits from that branch (mostly in order) until all of it is upstream.
3. The Wayland driver will have a lower precedence than the X11 driver, so X11/Xwayland will continue to be used by default when available. This will make it easy for distributions to include the Wayland driver in their normal package builds without compromising their stable user experience, while still allowing all users to easily try the Wayland driver (e.g., by unsetting DISPLAY). This would allow for broader testing compared to wine-staging.
4. Development continues, with the benefit of being in upstream, which is more likely to attract additional contributions, compared to just being a patchset in wine-staging.
Yes, this sounds quite reasonable to me ;-) Although upstreaming it in the middle of the win32u work may be an interesting proposition.
On Mon, Dec 13, 2021 at 01:18:49PM -0600, Zebediah Figura wrote: Hi Zebediah, Also, hi Alexandre (CCed), what are you thoughts about starting the upstreaming process for the Wayland driver as outlined in my previous email?
On 12/12/21 19:13, Alexandros Frantzis wrote:
1. Establish that the direction of the driver is acceptable for upstream. Do people think we haven't reached that point yet (and, if so, how can we get there)? Who could provide a final acknowledgment?
Ultimately the decision is up to Alexandre. Based on his prior response it doesn't seem out of the question, but it also seems like it depends on whether the Wayland driver is better in any concrete sense than using the winex11 driver plus XWayland. E.g. does it provide access to features only available via Wayland? (Are there any? I vaguely remember that HDR is one, because apparently that one was too hard to retrofit into X11.) Or better rendering performance?
Generally speaking, being much more likely to benefit from future developments is one of the advantages of the Wayland backend compared to using XWayland. More concretely, HDR is indeed one of the features that is currently being worked on in Wayland upstream and is unlikely to be available on X11. Another such development, which can have performance benefits, is allowing the compositor to dynamically notify clients when a different surface format/modifier would lead to more efficient presentation, e.g., a format/modifier pair suitable for direct scanout vs texturing of surface contents. This feature landed very recently as an official Wayland protocol extension (dmabuf-feedback). Concerning current rendering performance, I can't really comment concretely without performing more controlled and broad testing. There is the potential for some improvement by virtue of removing a whole layer from the stack, but I think that taking advantage of Wayland specific features (e.g., the aforementioned dmabuf-feedback) is more likely to have a notable effect. For what is worth, I haven't personally seen any noteworthy differences, but testing and optimizing performance hasn't been my focus so far.
Not being excessively ugly is probably also a prerequisite. I haven't yet got a chance to review the code to make a guess of this (although I'm planning to), although personally I don't have a lot familiarity with USER drivers and I wouldn't trust my judgement anyway. Jacek or Huw might be able to give a better review in this respect.
Thanks, looking forward to any feedback!
2. After the 7.0 freeze, start upstreaming the driver. As noted, I structured the commits in the 'wayland' branch specifically for ease of review and upstreaming, so the rough plan is that I will be proposing chunks of commits from that branch (mostly in order) until all of it is upstream.
3. The Wayland driver will have a lower precedence than the X11 driver, so X11/Xwayland will continue to be used by default when available. This will make it easy for distributions to include the Wayland driver in their normal package builds without compromising their stable user experience, while still allowing all users to easily try the Wayland driver (e.g., by unsetting DISPLAY). This would allow for broader testing compared to wine-staging.
4. Development continues, with the benefit of being in upstream, which is more likely to attract additional contributions, compared to just being a patchset in wine-staging.
Yes, this sounds quite reasonable to me ;-)
Although upstreaming it in the middle of the win32u work may be an interesting proposition.
This is indeed a complication, but as proposed by Jacek, the Wayland driver can be on the front line of the transition, and perhaps this could help exercise all the new infrastructure early with little risk to the more stable drivers. Thanks, Alexandros
Alexandros Frantzis <alexandros.frantzis(a)collabora.com> writes:
On Mon, Dec 13, 2021 at 01:18:49PM -0600, Zebediah Figura wrote:
Hi Zebediah,
Also, hi Alexandre (CCed), what are you thoughts about starting the upstreaming process for the Wayland driver as outlined in my previous email?
On 12/12/21 19:13, Alexandros Frantzis wrote:
2. After the 7.0 freeze, start upstreaming the driver. As noted, I structured the commits in the 'wayland' branch specifically for ease of review and upstreaming, so the rough plan is that I will be proposing chunks of commits from that branch (mostly in order) until all of it is upstream.
3. The Wayland driver will have a lower precedence than the X11 driver, so X11/Xwayland will continue to be used by default when available. This will make it easy for distributions to include the Wayland driver in their normal package builds without compromising their stable user experience, while still allowing all users to easily try the Wayland driver (e.g., by unsetting DISPLAY). This would allow for broader testing compared to wine-staging.
4. Development continues, with the benefit of being in upstream, which is more likely to attract additional contributions, compared to just being a patchset in wine-staging.
Yes, this sounds quite reasonable to me ;-)
Although upstreaming it in the middle of the win32u work may be an interesting proposition.
This is indeed a complication, but as proposed by Jacek, the Wayland driver can be on the front line of the transition, and perhaps this could help exercise all the new infrastructure early with little risk to the more stable drivers.
I expect we'd want to test the new interface against the X11 driver, which is a known quantity. Then once this works correctly and the interface has stabilized, we can introduce a new driver using that interface. It doesn't seem to make sense to upstream a new driver at the same time as the driver interface is changing. I think what Jacek was suggesting is that you adapt your driver to the win32u interface and track the upcoming changes, so that once win32u is ready and stabilized your driver is already making use of it, and can be upstreamed at that point without needing further changes. -- Alexandre Julliard julliard(a)winehq.org
On Tue, Dec 14, 2021 at 06:32:00PM +0100, Alexandre Julliard wrote:
Alexandros Frantzis <alexandros.frantzis(a)collabora.com> writes:
On Mon, Dec 13, 2021 at 01:18:49PM -0600, Zebediah Figura wrote:
Hi Zebediah,
Also, hi Alexandre (CCed), what are you thoughts about starting the upstreaming process for the Wayland driver as outlined in my previous email?
On 12/12/21 19:13, Alexandros Frantzis wrote:
2. After the 7.0 freeze, start upstreaming the driver. As noted, I structured the commits in the 'wayland' branch specifically for ease of review and upstreaming, so the rough plan is that I will be proposing chunks of commits from that branch (mostly in order) until all of it is upstream.
3. The Wayland driver will have a lower precedence than the X11 driver, so X11/Xwayland will continue to be used by default when available. This will make it easy for distributions to include the Wayland driver in their normal package builds without compromising their stable user experience, while still allowing all users to easily try the Wayland driver (e.g., by unsetting DISPLAY). This would allow for broader testing compared to wine-staging.
4. Development continues, with the benefit of being in upstream, which is more likely to attract additional contributions, compared to just being a patchset in wine-staging.
Yes, this sounds quite reasonable to me ;-)
Although upstreaming it in the middle of the win32u work may be an interesting proposition.
This is indeed a complication, but as proposed by Jacek, the Wayland driver can be on the front line of the transition, and perhaps this could help exercise all the new infrastructure early with little risk to the more stable drivers.
I expect we'd want to test the new interface against the X11 driver, which is a known quantity. Then once this works correctly and the interface has stabilized, we can introduce a new driver using that interface. It doesn't seem to make sense to upstream a new driver at the same time as the driver interface is changing.
I think what Jacek was suggesting is that you adapt your driver to the win32u interface and track the upcoming changes, so that once win32u is ready and stabilized your driver is already making use of it, and can be upstreamed at that point without needing further changes.
Hi Alexandre, Thanks for the reply! My thinking related to the win32u changes was that I would perform as much of the transition as possible before upstreaming (my understanding is that a chunk of the work can be done already), and then keep close track of changes as things progress. I agree that's not the same as testing an established driver, but perhaps it could provide some early feeback. It seems that the feeling is that this would in fact complicate the whole effort, in which case I am happy to continue tracking externally, providing any related feedback and waiting until stabilization to upstream. Excluding the currently ongoing driver transition, i.e., let's assume it was finished and the Wayland driver was up-to-date for it, what are your thoughts about the proposed upstreaming plan for the Wayland driver? Would you be willing to accept the driver upstream (assuming good quality code etc) according to that plan? Thanks, Alexandros
Alexandros Frantzis <alexandros.frantzis(a)collabora.com> writes:
Excluding the currently ongoing driver transition, i.e., let's assume it was finished and the Wayland driver was up-to-date for it, what are your thoughts about the proposed upstreaming plan for the Wayland driver? Would you be willing to accept the driver upstream (assuming good quality code etc) according to that plan?
I haven't looked at the code yet, but sure, if it's clean code, seems to work for people, and doesn't break too many tests, there's no reason that it couldn't go upstream. -- Alexandre Julliard julliard(a)winehq.org
On Tue, Dec 14, 2021 at 08:26:22PM +0100, Alexandre Julliard wrote:
Alexandros Frantzis <alexandros.frantzis(a)collabora.com> writes:
Excluding the currently ongoing driver transition, i.e., let's assume it was finished and the Wayland driver was up-to-date for it, what are your thoughts about the proposed upstreaming plan for the Wayland driver? Would you be willing to accept the driver upstream (assuming good quality code etc) according to that plan?
I haven't looked at the code yet, but sure, if it's clean code, seems to work for people, and doesn't break too many tests, there's no reason that it couldn't go upstream.
Hi Alexandre, That's great to hear! Thanks, Alexandros
Hi Alexandros, It's good to hear that the driver is progressing well. On 12/10/21 6:56 PM, Alexandros Frantzis wrote:
The vast majority (but not all) of the commits in the series affect only the driver itself. However, there is still a lot of surface area, mostly in terms of interfaces used to interact with Wine core, that could lead to broken code when upstream is updated. This has been more pronounced the last few weeks with the various changes in the driver interface.
I was responsible for those changes. This is just a preparation for a huge change that drivers will need to implement as a part of PE separation. While following interface changes shouldn't be too hard, doing the final separation will be more tricky. Let me roughly describe what will need to be done. A majority of the driver will ultimately live in Unix library (not PE-in-ELF like now) and will be executed behind syscall barriers. The main practical implication is that while it will have full access to Unix libraries, it will not be able to (easily) call PE libraries. This requires changes all over the place (see dlls/win32u for an example and "#pragma makedep unix" in general): - Instead of kernel32/kernelbase system functions, the driver can use ntdll.so directly. - Instead of kernel32 runtime functions, like memory allocators for memory not exposed outside Unix space, it will need to libc functions. - For synchronization primitives like CRITICAL_SECTION, it can use ptherad. - For gdi32 and user32, it can use win32u.so. win32u.so, however, is still a work in progress. While it should be already be able to cover gdi32 usage, some user32 are still missing in win32u. - The above are the more straightforward parts. Doing that will live some other calls that will be more tricky. Some parts of the driver may need to be in PE file, for example. We don't do that for in-tree drivers yet, mostly because win32u needs to be more complete before we can have a complete solution. But since your branch is a new and actively developed code, it may make your work easier if you take that into account sooner.
* Display mode changes (emulated with compositor scaling, rather than real display hardware mode changes).
This essentially sounds like "full screen" hack that Proton uses. Given that there apparently is a demand for such feature, I wonder if it would make sense to share such emulation between drivers. I imagine that this could be a null driver's behaviour that other drivers could choose to utilize.
There are some known cases where the driver doesn't work properly, that I think deserve an explicit mention since they may trip people up.
The first is when applications try to render to window created by another process. Although this not a typical scenario, it's how Chrome/Chromium and thus applications using CEF, including some game store apps, work. For now, the workaround is to instruct the application to use "in-process" GPU handling (with the "--in-process-gpu" command-line) or turn-off GPU rendering completely (typically with "--disable-gpu --disable-software-rasterizer"). For example, one can run GOG Galaxy with: "GalaxyClient.exe --in-process-gpu [--use-angle=d3d11]"
Yeah, we had those problem with winemac.drv for years. At some point I wrote a hack that used window surfaces backed by shared memory that could be used in child process and parent windows' process later copy that into the actual window surface. It works well enough for a number of scenarios, but it's not really enough for Vulkan/OpenGL. I would hope that a cross-driver solution could be found. winex11.drv also has some problems with its support for cross process rendering. At the time, we talked about an OpenGL-based compositor, although Vulkan would be probably the first choice those days. It seems to me that for cases when driver can provide support for Vulkan top level windows' surfaces, the rest could be implemented in win32u. Child windows Vulkan/OpenGL rendering could be rendered off-screen and then composed with the rest top level window. OOP rendering could probably be implemented on top of that by setting up a top-in-the-process window surface and additional IPC to parent window's process. I think that Windows has something like that and exposes some of it with DComposition APIs, so aligning such solution with that would be interesting. Anyway, I didn't look deep enough to be sure about any of that, but that's roughly how I imagine that this could be solved with a lot of work, but not much involvement on driver side. Thanks, Jacek
On 12/13/21 17:34, Jacek Caban wrote:
There are some known cases where the driver doesn't work properly, that I think deserve an explicit mention since they may trip people up.
The first is when applications try to render to window created by another process. Although this not a typical scenario, it's how Chrome/Chromium and thus applications using CEF, including some game store apps, work. For now, the workaround is to instruct the application to use "in-process" GPU handling (with the "--in-process-gpu" command-line) or turn-off GPU rendering completely (typically with "--disable-gpu --disable-software-rasterizer"). For example, one can run GOG Galaxy with: "GalaxyClient.exe --in-process-gpu [--use-angle=d3d11]"
Yeah, we had those problem with winemac.drv for years. At some point I wrote a hack that used window surfaces backed by shared memory that could be used in child process and parent windows' process later copy that into the actual window surface. It works well enough for a number of scenarios, but it's not really enough for Vulkan/OpenGL.
I would hope that a cross-driver solution could be found. winex11.drv also has some problems with its support for cross process rendering. At the time, we talked about an OpenGL-based compositor, although Vulkan would be probably the first choice those days. It seems to me that for cases when driver can provide support for Vulkan top level windows' surfaces, the rest could be implemented in win32u. Child windows Vulkan/OpenGL rendering could be rendered off-screen and then composed with the rest top level window. OOP rendering could probably be implemented on top of that by setting up a top-in-the-process window surface and additional IPC to parent window's process. I think that Windows has something like that and exposes some of it with DComposition APIs, so aligning such solution with that would be interesting. Anyway, I didn't look deep enough to be sure about any of that, but that's roughly how I imagine that this could be solved with a lot of work, but not much involvement on driver side.
I also believe that having a per-process graphics driver instance is a blocker for many things, and not only regarding cross-process rendering. This covers for instance, input focus and foreground window tracking, mouse and keyboard input event reconciliation between processes, or just simply that checking for host graphics driver events only when the app checks for its Win32 messages is not reliable enough in some cases (some apps are not actively checking their messages all the time). IMHO it would be better to have some system-wide (more likely per-desktop) host integration. And that would probably fit well with a compositor to better implement the rendering part. Cheers, -- Rémi Bernon <rbernon(a)codeweavers.com>
On Mon, Dec 13, 2021 at 05:34:30PM +0100, Jacek Caban wrote:
Hi Alexandros,
Hi Jacek!
It's good to hear that the driver is progressing well.
On 12/10/21 6:56 PM, Alexandros Frantzis wrote:
The vast majority (but not all) of the commits in the series affect only the driver itself. However, there is still a lot of surface area, mostly in terms of interfaces used to interact with Wine core, that could lead to broken code when upstream is updated. This has been more pronounced the last few weeks with the various changes in the driver interface.
I was responsible for those changes. This is just a preparation for a huge change that drivers will need to implement as a part of PE separation.
It was a relief to remove from driver all the registry related manipulations for the display setup. Thanks :)
While following interface changes shouldn't be too hard, doing the final separation will be more tricky. Let me roughly describe what will need to be done.
A majority of the driver will ultimately live in Unix library (not PE-in-ELF like now) and will be executed behind syscall barriers. The main practical implication is that while it will have full access to Unix libraries, it will not be able to (easily) call PE libraries. This requires changes all over the place (see dlls/win32u for an example and "#pragma makedep unix" in general):
- Instead of kernel32/kernelbase system functions, the driver can use ntdll.so directly.
- Instead of kernel32 runtime functions, like memory allocators for memory not exposed outside Unix space, it will need to libc functions.
- For synchronization primitives like CRITICAL_SECTION, it can use ptherad.
- For gdi32 and user32, it can use win32u.so. win32u.so, however, is still a work in progress. While it should be already be able to cover gdi32 usage, some user32 are still missing in win32u.
- The above are the more straightforward parts. Doing that will live some other calls that will be more tricky. Some parts of the driver may need to be in PE file, for example.
We don't do that for in-tree drivers yet, mostly because win32u needs to be more complete before we can have a complete solution. But since your branch is a new and actively developed code, it may make your work easier if you take that into account sooner.
Thanks for all the information. It helps put the changes into perspective. Moving in this direction earlier rather than later for the Wayland driver makes sense to me. Are all these changes safe to do before the full transition? Also is it possible at this point to mix and match calls, e.g., to win32u NtUser* and also to user32.dll (for any functions not yet in win32u), or can such a partial transition lead to issues?
* Display mode changes (emulated with compositor scaling, rather than real display hardware mode changes).
This essentially sounds like "full screen" hack that Proton uses. Given that there apparently is a demand for such feature, I wonder if it would make sense to share such emulation between drivers. I imagine that this could be a null driver's behaviour that other drivers could choose to utilize.
I haven't seen the details of how Proton deals with full screen scaling, but, at least in the Wayland driver, it's all done using Wayland specific functionality, so it's not clear to me at this point how much sharing is possible. In particular, in the Wayland driver the work of scaling is relegated to the compositor. The application renders normally, assuming whatever mode is active from the Win32 perspective, and the driver tells the compositor to scale the surface accordingly to provide the illusion of a mode change.
There are some known cases where the driver doesn't work properly, that I think deserve an explicit mention since they may trip people up.
The first is when applications try to render to window created by another process. Although this not a typical scenario, it's how Chrome/Chromium and thus applications using CEF, including some game store apps, work. For now, the workaround is to instruct the application to use "in-process" GPU handling (with the "--in-process-gpu" command-line) or turn-off GPU rendering completely (typically with "--disable-gpu --disable-software-rasterizer"). For example, one can run GOG Galaxy with: "GalaxyClient.exe --in-process-gpu [--use-angle=d3d11]"
Yeah, we had those problem with winemac.drv for years. At some point I wrote a hack that used window surfaces backed by shared memory that could be used in child process and parent windows' process later copy that into the actual window surface. It works well enough for a number of scenarios, but it's not really enough for Vulkan/OpenGL.
I think such an approach would be a somewhat viable option for Wayland, given that its presentation model is based on submissions of client allocated buffers, either SHM buffers for software rendering, or dmabufs (DMA buffers) for Vulkan/OpenGL. The driver could manually render to a (offscreen) buffer and then submit that itself, or pass it to another process (e.g., the one owning the window) for presentation. The driver would essentially need to reimplement much of the Wayland WSI swapchain/EGL swapbuffers functionality, including buffer allocation, handling of fences, frame callbacks etc. Then there is all the infrastructure around IPC of these buffers.
I would hope that a cross-driver solution could be found. winex11.drv also has some problems with its support for cross process rendering. At the time, we talked about an OpenGL-based compositor, although Vulkan would be probably the first choice those days. It seems to me that for cases when driver can provide support for Vulkan top level windows' surfaces, the rest could be implemented in win32u. Child windows Vulkan/OpenGL rendering could be rendered off-screen and then composed with the rest top level window. OOP rendering could probably be implemented on top of that by setting up a top-in-the-process window surface and additional IPC to parent window's process. I think that Windows has something like that and exposes some of it with DComposition APIs, so aligning such solution with that would be interesting. Anyway, I didn't look deep enough to be sure about any of that, but that's roughly how I imagine that this could be solved with a lot of work, but not much involvement on driver side.
Thanks, Jacek
Thanks, Alexandros
On 12/14/21 4:33 PM, Alexandros Frantzis wrote:
On Mon, Dec 13, 2021 at 05:34:30PM +0100, Jacek Caban wrote:
Hi Alexandros, Hi Jacek!
It's good to hear that the driver is progressing well.
On 12/10/21 6:56 PM, Alexandros Frantzis wrote:
The vast majority (but not all) of the commits in the series affect only the driver itself. However, there is still a lot of surface area, mostly in terms of interfaces used to interact with Wine core, that could lead to broken code when upstream is updated. This has been more pronounced the last few weeks with the various changes in the driver interface.
I was responsible for those changes. This is just a preparation for a huge change that drivers will need to implement as a part of PE separation. It was a relief to remove from driver all the registry related manipulations for the display setup. Thanks :)
While following interface changes shouldn't be too hard, doing the final separation will be more tricky. Let me roughly describe what will need to be done.
A majority of the driver will ultimately live in Unix library (not PE-in-ELF like now) and will be executed behind syscall barriers. The main practical implication is that while it will have full access to Unix libraries, it will not be able to (easily) call PE libraries. This requires changes all over the place (see dlls/win32u for an example and "#pragma makedep unix" in general):
- Instead of kernel32/kernelbase system functions, the driver can use ntdll.so directly.
- Instead of kernel32 runtime functions, like memory allocators for memory not exposed outside Unix space, it will need to libc functions.
- For synchronization primitives like CRITICAL_SECTION, it can use ptherad.
- For gdi32 and user32, it can use win32u.so. win32u.so, however, is still a work in progress. While it should be already be able to cover gdi32 usage, some user32 are still missing in win32u.
- The above are the more straightforward parts. Doing that will live some other calls that will be more tricky. Some parts of the driver may need to be in PE file, for example.
We don't do that for in-tree drivers yet, mostly because win32u needs to be more complete before we can have a complete solution. But since your branch is a new and actively developed code, it may make your work easier if you take that into account sooner. Thanks for all the information. It helps put the changes into perspective.
Moving in this direction earlier rather than later for the Wayland driver makes sense to me. Are all these changes safe to do before the full transition?
Yes, it should be fine.
Also is it possible at this point to mix and match calls, e.g., to win32u NtUser* and also to user32.dll (for any functions not yet in win32u), or can such a partial transition lead to issues?
Yes, mixing win32u and user32 is possible and should not lead to issues.
* Display mode changes (emulated with compositor scaling, rather than real display hardware mode changes).
This essentially sounds like "full screen" hack that Proton uses. Given that there apparently is a demand for such feature, I wonder if it would make sense to share such emulation between drivers. I imagine that this could be a null driver's behaviour that other drivers could choose to utilize.
I haven't seen the details of how Proton deals with full screen scaling, but, at least in the Wayland driver, it's all done using Wayland specific functionality, so it's not clear to me at this point how much sharing is possible.
In particular, in the Wayland driver the work of scaling is relegated to the compositor. The application renders normally, assuming whatever mode is active from the Win32 perspective, and the driver tells the compositor to scale the surface accordingly to provide the illusion of a mode change.
Thank for explanation, it sounds like it fits the driver in this case. (I should add a disclaimer that I have little knowledge about Wayland.) Thanks, Jacek
Hi, first of all, thanks for your work on this. On 10/12/21 18:56, Alexandros Frantzis wrote:
The first is when applications try to render to window created by another process. Although this not a typical scenario, it's how Chrome/Chromium and thus applications using CEF, including some game store apps, work. For now, the workaround is to instruct the application to use "in-process" GPU handling (with the "--in-process-gpu" command-line) or turn-off GPU rendering completely (typically with "--disable-gpu --disable-software-rasterizer"). For example, one can run GOG Galaxy with: "GalaxyClient.exe --in-process-gpu [--use-angle=d3d11]"
Could you expand a little bit on what is the problem here? My (admittedly, limited) understanding of Wayland's general philosophy is that it doesn't care about how the process computes what should appear in a window. It just expects a buffer with the pixel data in it, and it has some efficient way to move that buffer from the client to the compositor, which then does compositing and brings the result to the screen. But if you can efficiently move a buffer from a client to a compositor, it doesn't sound that much harder to move it from a client to another client and then to a compositor, thus basically allowing a process to draw on another process' window. What am I missing? One problem commonly mentioned about windowing drivers is that they are hard to test. My understanding of the reason is that they have to interact with external systems (X11, Wayland, native Windows, ...) that are hard to mock (especially, hard to mock in a way that preserves all the quirks we have to care about) and hard to configure so that their behavior is predictable and testable. Does a Wayland driver has a hope to make things any easier here? Thanks, Giovanni.
On Wed, Dec 15, 2021 at 09:55:39AM +0100, Giovanni Mascellani wrote:
Hi,
first of all, thanks for your work on this.
Hi Giovanni!
On 10/12/21 18:56, Alexandros Frantzis wrote:
The first is when applications try to render to window created by another process. Although this not a typical scenario, it's how Chrome/Chromium and thus applications using CEF, including some game store apps, work. For now, the workaround is to instruct the application to use "in-process" GPU handling (with the "--in-process-gpu" command-line) or turn-off GPU rendering completely (typically with "--disable-gpu --disable-software-rasterizer"). For example, one can run GOG Galaxy with: "GalaxyClient.exe --in-process-gpu [--use-angle=d3d11]"
Could you expand a little bit on what is the problem here? My (admittedly, limited) understanding of Wayland's general philosophy is that it doesn't care about how the process computes what should appear in a window. It just expects a buffer with the pixel data in it, and it has some efficient way to move that buffer from the client to the compositor, which then does compositing and brings the result to the screen. But if you can efficiently move a buffer from a client to a compositor, it doesn't sound that much harder to move it from a client to another client and then to a compositor, thus basically allowing a process to draw on another process' window. What am I missing?
You aren't missing anything, your description of how things work in Wayland is correct, and the core of the solution you describe is a possible way forward. The issue at the moment is mainly with the complexity of implementing such a solution, rather than with some fundamentally unsolvable problem. I don't think I will have a full picture of the details and pain points until I get the chance to focus my attention on this a bit more, and perhaps create some prototype implementation, but my current thoughts are: the process that does the rendering needs to deal with formats, allocate offscreen buffers, make them available to the application at the right points (e.g., GL MakeCurrent, vkAcquireImage) so that applications draw into them. Then at VkQueuePresent/SwapBuffers time we need to send them, along with any related fence objects, to the process that owns the window. The window-owning process will then need to present the buffer, but also keep track of when the buffer is released and then "return" it back to the rendering process. We might want to add additional features like supporting the dmabuf-feedback Wayland protocol for dynamic swapchain reconfiguration etc. We essentially need to reimplement a large part of the functionality provided by VkSwapchainKHR and EGLSwapBuffers in a way that works across processes, managing and synchronizing everything manually. Something similar would need to happen for the non-accelerated cases when using SHM buffers. Then there is the question of how the IPC to send the buffers and fences would actually work. Since both buffers and fences are represented as unix FDs, I was initially thinking that I would need to manually set up socket based side channels. I then found wine_server_fd_to_handle and DuplicateHandle, which along with a cross-process window message could in theory cover all our IPC buffer/fence needs. If I am not missing anything, and this is indeed possible, it could make things much simpler on the IPC front. Performing buffer passing in Wine is not the only way forward. Another solution would involve a new Wayland extension that would give us access to Wayland surfaces from different Wayland connections in a secure manner. In fact there is an existing protocol that allows some very limited interaction with such surfaces ("foreign surfaces"), namely changing parentage/ownership of toplevel surfaces. However, given that expanding the scope of such interactions to allow cross-connection/process buffer commits is somewhat contrary to the per-connection nature of Wayland objects, and that there is a client side alternative (i.e., what I described above) however complex it may be, such a protocol could be a hard sell to Wayland upstream.
One problem commonly mentioned about windowing drivers is that they are hard to test. My understanding of the reason is that they have to interact with external systems (X11, Wayland, native Windows, ...) that are hard to mock (especially, hard to mock in a way that preserves all the quirks we have to care about) and hard to configure so that their behavior is predictable and testable. Does a Wayland driver has a hope to make things any easier here?
Wayland is a mixed bag here. On the one hand it doesn't provide official mechanisms to inspect the state of most objects (let alone when they originate from another process or Wayland connection), or control some properties (e.g., global position). There is also the inherently asynchronous nature of the Wayland protocol, that, depending on what you are testing, may cause complications. On the other hand, it's at least conceivable (although not trivial) to create a custom test compositor that would provide tailored and predictable behavior and would expose or control state through some custom mechanism. For example, the Weston reference Wayland compositor implements an internal Wayland protocol extension allowing clients to control various state for its internal testing purposes. Furthermore, the protocol itself is relatively narrow and easy to work with, so mocking the used protocol subset through a custom interface in the code shouldn't be too hard. Finally, inspecting the protocol traffic at the wire level to extract meaningful state is also an option [1]. Thanks, Alexandros [1] See https://wayland.freedesktop.org/extras.html for some interesting tools that inspect Wayland protocol traffic.
participants (7)
-
Alexandre Julliard -
Alexandros Frantzis -
Giovanni Mascellani -
Jacek Caban -
Paul Gofman -
Rémi Bernon -
Zebediah Figura