https://bugs.winehq.org/show_bug.cgi?id=42284
Bug ID: 42284 Summary: Enable using Wine with Wayland and without X on Linux Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: shtetldik@gmail.com Distribution: ---
Currently, Wine on Linux is strongly dependent on X, and when used with the desktop environment with new Wayland display server, Wine is forced to run through XWayland, which so far remains a poor experience.
The whole Linux desktop is now strongly pushing the switch from X to Wayland, and many major applications are now in the process of enabling this switch.
Is there some plan for such effort in Wine? Is it even feasible? I couldn't find any bugs opened for it, so I'm opening one here to track this.
https://bugs.winehq.org/show_bug.cgi?id=42284
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |integration Version|unspecified |2.0-rc6 CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
John E john.ettedgui@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |john.ettedgui@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@fds-team.de
--- Comment #1 from Michael Müller michael@fds-team.de --- It is very unlikely that Wine is going to support Wayland in the same way as X. I worked on a Wayland driver for Wine some time ago, but discontinued the idea because Wayland lacks many features that are expected by Windows programs.
One problem is for example that a program can not specify the location of a newly created window. This doesn't sound very problematic at first, until you notice that drop-down / popup menus are also just normal windows on Windows. The solution that Wayland provides for this is not really compatible with the Win32 API. I therefore talked with some Wayland developers and there is no chance of fixing this in the future. It is part of their concept that applications should not have control over the window position and similar settings.
IMHO, it is not a good solution to remove features just because an application could abuse them. I can understand this for security relevant features, like grabbing the keyboard and mouse input from another window, but not for things like specifying the window position. It is like removing the possibility to delete files, because the user could accidentally click on the wrong file, instead of implementing a recycle bin. Adding a way to recover from situations in which programs misbehave would be a better solution, but this is just my opinion.
The opinion from the Wayland developers is that you should stick to XWayland. The best solution Wine could offer, would be a virtual desktop that uses native Wayland. Not sure if it is worth the effort though.
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #2 from Shmerl shtetldik@gmail.com --- (In reply to Michael Müller from comment #1)
The opinion from the Wayland developers is that you should stick to XWayland. The best solution Wine could offer, would be a virtual desktop that uses native Wayland. Not sure if it is worth the effort though.
Yeah, sticking to X doesn't sound like a good long term solution.
By making a virtual desktop, do you mean implementing a full blown Wayland compositor in Wine? I also thought that this is one of the options.
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #3 from Michael Müller michael@fds-team.de --- (In reply to Shmerl from comment #2)
By making a virtual desktop, do you mean implementing a full blown Wayland compositor in Wine? I also thought that this is one of the options.
No, I mean what you get when you enable the virtual desktop in the graphic tab in winecfg.
https://bugs.winehq.org/show_bug.cgi?id=42284
josh@hoblitt.com josh@hoblitt.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |josh@hoblitt.com
--- Comment #4 from josh@hoblitt.com josh@hoblitt.com --- Would it be possible map calls into GTK, QT, or equivalent toolkit that know how to draw directly on a wayland buffer?
Xwayland has worked for everything I've tried under it except screen capture applications that need low level X voodoo. I think the major reason for wine to want to move to native wayland support would be for performance reasons. I haven't seen any benchmarks that compare native wayland, vs Xwayland, vs Xorg on the same hardware so I don't know which way the winds are currently blowing. I would expect wayland [at least eventually] to come out ahead.
https://bugs.winehq.org/show_bug.cgi?id=42284
Constantine hi-angel@yandex.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hi-angel@yandex.ru
--- Comment #5 from Constantine hi-angel@yandex.ru ---
Would it be possible map calls into GTK, QT, or equivalent toolkit that know how to draw directly on a wayland buffer?
FTR wine-staging has "enable gtk3" tab, so it's probably already started.
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #6 from Vincent Povirk madewokherd@gmail.com ---
Would it be possible map calls into GTK, QT, or equivalent toolkit that know how to draw directly on a wayland buffer?
This would not solve the problem Michael described. These toolkits are able to correctly position drop-down menus because they know which main window the menu belongs to, and can request positioning relative to that. Wine does not generally have this information and would have to guess.
I don't think the problem is insurmountable, but then again I didn't do the work.
https://bugs.winehq.org/show_bug.cgi?id=42284
ax 34noff otaku@rambler.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |otaku@rambler.ru
https://bugs.winehq.org/show_bug.cgi?id=42284
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
Deve deveee@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |deveee@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
Maksym Kit kitmaxter@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kitmaxter@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
Yann Droneaud yann@droneaud.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yann@droneaud.fr
https://bugs.winehq.org/show_bug.cgi?id=42284
zefkerr zefkerrigan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zefkerrigan@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
Brane2 brane212@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brane212@gmail.com
--- Comment #7 from Brane2 brane212@gmail.com --- Wouldn't then optimal solution be to solve it in wayland compositor ?
I suppose folks would have to agree on some sort of standard interface to wine that could be implemented on all compositors...
https://bugs.winehq.org/show_bug.cgi?id=42284
darkdragon-001@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |darkdragon-001@web.de
https://bugs.winehq.org/show_bug.cgi?id=42284
Bernhard Friedreich friesoft@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |friesoft@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
https://bugs.winehq.org/show_bug.cgi?id=42284
Luke Bratch luke@bratch.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |luke@bratch.co.uk
https://bugs.winehq.org/show_bug.cgi?id=42284
jonwsb@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jonwsb@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
jchristi mancubus220@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mancubus220@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
Jürg Billeter j@bitron.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |j@bitron.ch
--- Comment #8 from Jürg Billeter j@bitron.ch --- Wayland clients have control over the position and size of sub-surfaces. Would it be feasible to use sub-surfaces for drop-down/popup menus?
https://bugs.winehq.org/show_bug.cgi?id=42284
tnelis@stammed.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tnelis@stammed.net
https://bugs.winehq.org/show_bug.cgi?id=42284
TestMode testmode11@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |testmode11@protonmail.com
--- Comment #9 from TestMode testmode11@protonmail.com --- (In reply to Michael Müller from comment #1)
It is very unlikely that Wine is going to support Wayland in the same way as X. I worked on a Wayland driver for Wine some time ago, but discontinued the idea because Wayland lacks many features that are expected by Windows programs.
Can you please share this initial driver code? Window positioning is not important for many apps and games. While using Wayland+Wine would allow getting rid off many small libx* or xorg libraries and will bring 1-5% performance improvement.
https://bugs.winehq.org/show_bug.cgi?id=42284
Vitaly Lipatov lav@etersoft.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lav@etersoft.ru
https://bugs.winehq.org/show_bug.cgi?id=42284
Sven Arvidsson sa@whiz.se changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sa@whiz.se
https://bugs.winehq.org/show_bug.cgi?id=42284
zzzzzyzz@hacari.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz@hacari.org
https://bugs.winehq.org/show_bug.cgi?id=42284
Hendrik Schröter h.schroeter@pm.me changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |h.schroeter@pm.me
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #10 from Shmerl shtetldik@gmail.com --- Is there any progress on this? A while ago, on one of the Wine conferences, Wayland support was mentioned as planned for the future work.
https://bugs.winehq.org/show_bug.cgi?id=42284
Alexander terminalnode@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |terminalnode@protonmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
tom@westslope.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tom@westslope.org
https://bugs.winehq.org/show_bug.cgi?id=42284
Oliver Klee dev+wine@oliverklee.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dev+wine@oliverklee.de
https://bugs.winehq.org/show_bug.cgi?id=42284
leonard@lausen.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leonard@lausen.nl
https://bugs.winehq.org/show_bug.cgi?id=42284
Mikhail mikhail.v.gavrilov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mikhail.v.gavrilov@gmail.co | |m
https://bugs.winehq.org/show_bug.cgi?id=42284
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
Evgenii Burmentev [:virus_found] vir.found@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vir.found@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
ilkka.prusi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ilkka.prusi@gmail.com
--- Comment #11 from ilkka.prusi@gmail.com --- (In reply to Vincent Povirk from comment #6)
Would it be possible map calls into GTK, QT, or equivalent toolkit that know how to draw directly on a wayland buffer?
This would not solve the problem Michael described. These toolkits are able to correctly position drop-down menus because they know which main window the menu belongs to, and can request positioning relative to that. Wine does not generally have this information and would have to guess.
I don't think the problem is insurmountable, but then again I didn't do the work.
Windows has GetClientRect() and GetWindowRect() API calls, first operates on relative coordinates (relative to parent-window) and second by screen coordinates. Things like menus are most often relative to window (and adjust when window size changes), but I'm certain there are bonkers kludge also which only operate on specific display resolution and uses only screen coordinates.
So for a large part of software the question of coordinates is non-issue, but there is the part about software doing things in weird ways (anyone looked at Windows 3.11 applications lately?). I'm guessing that it would not be a big miss if those that use direct screen coordinates were handled as "fullscreen" (meaning disabled resizing) and just assuming the coordinate is relative to the (faked) "fullscreen" window: likely software that uses directly screen coordinates cannot handle resizing of the window anyway. But of course there's always the chance of something breaking..
But I'm pretty confident you won't even need that hackery in the first place.
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #12 from zefkerr zefkerrigan@gmail.com --- (In reply to ilkka.prusi from comment #11)
(In reply to Vincent Povirk from comment #6)
Would it be possible map calls into GTK, QT, or equivalent toolkit that know how to draw directly on a wayland buffer?
This would not solve the problem Michael described. These toolkits are able to correctly position drop-down menus because they know which main window the menu belongs to, and can request positioning relative to that. Wine does not generally have this information and would have to guess.
I don't think the problem is insurmountable, but then again I didn't do the work.
Windows has GetClientRect() and GetWindowRect() API calls, first operates on relative coordinates (relative to parent-window) and second by screen coordinates. Things like menus are most often relative to window (and adjust when window size changes), but I'm certain there are bonkers kludge also which only operate on specific display resolution and uses only screen coordinates.
So for a large part of software the question of coordinates is non-issue, but there is the part about software doing things in weird ways (anyone looked at Windows 3.11 applications lately?). I'm guessing that it would not be a big miss if those that use direct screen coordinates were handled as "fullscreen" (meaning disabled resizing) and just assuming the coordinate is relative to the (faked) "fullscreen" window: likely software that uses directly screen coordinates cannot handle resizing of the window anyway. But of course there's always the chance of something breaking..
But I'm pretty confident you won't even need that hackery in the first place.
Who and why really need 3.11 applications for today? In my opinion, this is not a good reason not to add Wayland support for Wine. Moreover, Wayland support for Wine was announced by Alexandre Julliard at WineConf 2016, but for reasons unknown to us, no work on its implementation is still visible. Well, then when will the native Wayland support for Wine be implemented? Thank you.
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #13 from ilkka.prusi@gmail.com --- (In reply to zefkerr from comment #12)
(In reply to ilkka.prusi from comment #11)
(In reply to Vincent Povirk from comment #6)
Would it be possible map calls into GTK, QT, or equivalent toolkit that know how to draw directly on a wayland buffer?
This would not solve the problem Michael described. These toolkits are able to correctly position drop-down menus because they know which main window the menu belongs to, and can request positioning relative to that. Wine does not generally have this information and would have to guess.
I don't think the problem is insurmountable, but then again I didn't do the work.
Windows has GetClientRect() and GetWindowRect() API calls, first operates on relative coordinates (relative to parent-window) and second by screen coordinates. Things like menus are most often relative to window (and adjust when window size changes), but I'm certain there are bonkers kludge also which only operate on specific display resolution and uses only screen coordinates.
So for a large part of software the question of coordinates is non-issue, but there is the part about software doing things in weird ways (anyone looked at Windows 3.11 applications lately?). I'm guessing that it would not be a big miss if those that use direct screen coordinates were handled as "fullscreen" (meaning disabled resizing) and just assuming the coordinate is relative to the (faked) "fullscreen" window: likely software that uses directly screen coordinates cannot handle resizing of the window anyway. But of course there's always the chance of something breaking..
But I'm pretty confident you won't even need that hackery in the first place.
Who and why really need 3.11 applications for today? In my opinion, this is not a good reason not to add Wayland support for Wine. Moreover, Wayland support for Wine was announced by Alexandre Julliard at WineConf 2016, but for reasons unknown to us, no work on its implementation is still visible. Well, then when will the native Wayland support for Wine be implemented? Thank you.
Who and why really needs dosbox today (/sarcasm).. It is called emulation after all and I guess there are people who for some reason want to run all kinds of weird software.
I think there were some text adventures for 3.1/3.11 which used kindof scrollbar-system that looked like something from Windows-API but I'm not absolutely certain it wasn't just some toolkit that had same appearance..
https://bugs.winehq.org/show_bug.cgi?id=42284
Tobias Langendorf tobias.langendorf@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tobias.langendorf@googlemai | |l.com
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #14 from Shmerl shtetldik@gmail.com --- So, is anyone working on this, or are there any practical plans to actually work on this, or they were abandoned?
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #15 from Artem S. Tashkinov aros@gmx.com --- (In reply to Shmerl from comment #14)
So, is anyone working on this, or are there any practical plans to actually work on this, or they were abandoned?
https://github.com/varmd/wine-wayland
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #16 from Shmerl shtetldik@gmail.com --- (In reply to Artem S. Tashkinov from comment #15)
(In reply to Shmerl from comment #14)
So, is anyone working on this, or are there any practical plans to actually work on this, or they were abandoned?
I asked the developer, he doesn't seem to be collaborating with CodeWeavers on this. May be the effort can be shared?
https://bugs.winehq.org/show_bug.cgi?id=42284
maniikarabera@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maniikarabera@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=42284
postix postix@posteo.eu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |postix@posteo.eu
https://bugs.winehq.org/show_bug.cgi?id=42284
junglerobba@jngl.one changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |junglerobba@jngl.one
https://bugs.winehq.org/show_bug.cgi?id=42284
bodqhrohro bodqhrohro@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bodqhrohro@gmail.com
--- Comment #17 from bodqhrohro bodqhrohro@gmail.com --- Y'all focused on window positioning here, but how about more important things like global keybindings, clipboard, layout switching, screen capturing, tray icons, and so? Tiny things like LightShot or Punto Switcher may easily rely on lots of this simultaneously. Wayland just treats all that things out-of-scope and delegates their implementation to compositors with no standardization (and no enforcing to make this things available to Wayland clients at all, rather than to the compositor only).
There are some ongoing efforts on making Wayland protocol extensions, as well as independent technologies like PipeWire, but I doubt they ever will be supported by ALL compositors (especially by GNOME bigots that tend to ditch things just because they don't fit their philosophy). Yet the similar happened smoothly when EWMH emerged, but that was another time and another forces behind the community; just to mention that there were lots of competing *NIX systems (BSDs/Solaris/etc.), and thus standardization and interoperability was more important, but now GNU/Linux almost outperformed them all.
X11 is already a problem (for example, it doesn't allow drawing on foreign windows and inspecting their content like WinAPI does), but Wayland is a total disaster.
https://bugs.winehq.org/show_bug.cgi?id=42284
Neros contact@neros.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |contact@neros.fr
https://bugs.winehq.org/show_bug.cgi?id=42284
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=42284
alexandros.frantzis@collabora.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexandros.frantzis@collabo | |ra.com, | |leslie_alistair@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #18 from alexandros.frantzis@collabora.com --- Created attachment 71256 --> https://bugs.winehq.org/attachment.cgi?id=71256 Wayland driver staging patchset (over upstream f69d4a865f9)
Hi! As some people may already be aware of, I have been working on a Wayland for some time now. As discussed on the mailing list previously, wine-staging It has reached a point where it would benefit from wider exposure through wine-staging.
To this end, as per the wine-staging guidelines, I am attaching a patchset and I would like to request inclusion into wine-staging (CCed staging maintainer).
For additional information and discussion on this topic, I have sent an email to the wine mailing list (see: https://www.winehq.org/pipermail/wine-devel/2021-December/203035.html).
Thanks!
https://bugs.winehq.org/show_bug.cgi?id=42284
alexandros.frantzis@collabora.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
Amit Ambasta amit.prakash.ambasta@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |amit.prakash.ambasta@gmail. | |com
--- Comment #19 from Amit Ambasta amit.prakash.ambasta@gmail.com --- @Alexandros Would it be acceptable to start packaging the proposed patchset and providing bug reports, or should that be deferred until it is merged in staging?
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #20 from alexandros.frantzis@collabora.com --- (In reply to Amit Ambasta from comment #19)
@Alexandros Would it be acceptable to start packaging the proposed patchset and providing bug reports, or should that be deferred until it is merged in staging?
Hi Amit!
I would propose waiting for the related discussion in the ML (about the next steps for the driver) to reach a conclusion before proceeding with packaging the patchset in any wine-staging related manner. Of course, everyone is welcome to give the driver a go and let me know of any issues.
Thanks, Alexandros
https://bugs.winehq.org/show_bug.cgi?id=42284
Jens Staal staal1978@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |staal1978@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
Maciej Stanczew maciej.stanczew+b@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maciej.stanczew+b@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
Behzad A behzad.a_ir@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |behzad.a_ir@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
winetaste@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetaste@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=42284
Seth sethhphillips@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sethhphillips@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
Ker noa blue-t@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |blue-t@web.de
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #21 from Shmerl shtetldik@gmail.com --- What is the current status of this? Is it getting close to being upstreamed or included in staging at least?
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #22 from Shmerl shtetldik@gmail.com --- (In reply to alexandros.frantzis from comment #20)
I would propose waiting for the related discussion in the ML (about the next steps for the driver) to reach a conclusion before proceeding with packaging the patchset in any wine-staging related manner. Of course, everyone is welcome to give the driver a go and let me know of any issues.
It wasn't very clear from the ML what the conclusion is, besides general willingness to eventually accept it upstream.
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #23 from Shmerl shtetldik@gmail.com --- Is there some documentation how to build Wine Wayland branch from here?
https://gitlab.collabora.com/alf/wine/-/tree/wayland/
I tried (on Debian testing), but it's giving me this:
makedep: error: open /stable/viewporter/viewporter.xml : No such file or directory config.status: error: could not create Makefile
I suppose a bunch of Wayland related development packages are needed?
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #24 from zefkerr zefkerrigan@gmail.com --- (In reply to Shmerl from comment #23)
Is there some documentation how to build Wine Wayland branch from here?
https://gitlab.collabora.com/alf/wine/-/tree/wayland/
I tried (on Debian testing), but it's giving me this:
makedep: error: open /stable/viewporter/viewporter.xml : No such file or directory config.status: error: could not create Makefile
I suppose a bunch of Wayland related development packages are needed?
wayland-protocols package must be installed!
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #25 from Shmerl shtetldik@gmail.com --- (In reply to zefkerr from comment #24)
wayland-protocols package must be installed!
OK, I figured it out, I indeed needed wayland-protocols, but also libxkbcommon-dev and using --with-wayland when running configure.
I'll run some gaming tests with that build.
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #26 from Shmerl shtetldik@gmail.com --- Tried running Cyberpunk 2077 (GOG version, latest vkd3d-proton master in the prefix, Mesa-main / radv).
It's just getting a black screen. Nothing very telling in the error log either.
Used env:
export DISPLAY='' export WAYLAND_DISPLAY='wayland-0'
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #27 from Zeb Figura z.figura12@gmail.com --- Please discuss user support for (currently) out-of-tree patches elsewhere; wine bugzilla is not the place for it.
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #28 from Shmerl shtetldik@gmail.com --- (In reply to Zeb Figura from comment #27)
Please discuss user support for (currently) out-of-tree patches elsewhere; wine bugzilla is not the place for it.
Tried opening some issue here: https://gitlab.collabora.com/alf/wine/-/commits/wayland
But it requires Collabora Phabricator account, so not sure where exactly to discuss this then.
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #29 from Zeb Figura z.figura12@gmail.com --- (In reply to Shmerl from comment #28)
(In reply to Zeb Figura from comment #27)
Please discuss user support for (currently) out-of-tree patches elsewhere; wine bugzilla is not the place for it.
Tried opening some issue here: https://gitlab.collabora.com/alf/wine/-/commits/wayland
But it requires Collabora Phabricator account, so not sure where exactly to discuss this then.
If there's no more appropriate place, then the Wine forums would at least be an improvement over bugzilla.
https://bugs.winehq.org/show_bug.cgi?id=42284
John Marion john@jmarion.dev changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |john@jmarion.dev
https://bugs.winehq.org/show_bug.cgi?id=42284
Celeste Liu coelacanthus@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |coelacanthus@outlook.com
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #30 from Artem S. Tashkinov aros@gmx.com --- (In reply to Shmerl from comment #28)
(In reply to Zeb Figura from comment #27)
Please discuss user support for (currently) out-of-tree patches elsewhere; wine bugzilla is not the place for it.
Tried opening some issue here: https://gitlab.collabora.com/alf/wine/-/commits/wayland
But it requires Collabora Phabricator account, so not sure where exactly to discuss this then.
There's literally a single developer, have you tried emailing them?
Alexandros Frantzis <alexandros.frantzis (a) collabora.com>
https://bugs.winehq.org/show_bug.cgi?id=42284
gudvinr+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gudvinr+wine@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #31 from Shmerl shtetldik@gmail.com --- I was trying to test latest Wine version since some of the Wayland work was already merged, but somehow even notepad.exe isn't opening for me?
I'm using Debian testing WineHQ build (8.12) doing this:
DISPLAY='' WAYLAND_DISPLAY='wayland-0' wine notepad.exe
And I'm getting:
... 0158:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. 0158:err:winediag:nodrv_CreateWindow L"Make sure that your X server is running and that $DISPLAY is set correctly."
What is the right way to do it?
https://bugs.winehq.org/show_bug.cgi?id=42284
soredake broaden_acid002@simplelogin.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|broaden_acid002@simplelogin | |.com |
https://bugs.winehq.org/show_bug.cgi?id=42284
--- Comment #32 from Shmerl shtetldik@gmail.com --- Looks like this bit is missing for it:
https://gitlab.collabora.com/alf/wine/-/commit/4db0008a36fd424cac274447d8b45...
-
wine-bugs＠winehq.org -
WineHQ Bugzilla