Wine 4.0 Release Preparations Begin For Much Improved Windows Games / Apps On Linux

[oiaohm]

I don't see the problem. That's just being practical. Every sane API has chance to fail and inform you with some error code, and you should always expect it to fail and not deliver when writing code.

Except X11 IPC is not sane the protocal state that it can eat a message at any time. By protocol the X11 server does not have to send you an error code if it eats your request. Sending back a invalid valid is also valid by protocol.

I don't see that, care to quote that bit? FYI, only Michael and Vincent are devs in that bug report.

https://github.com/wayland-project/wayland-protocols/blob/master/stable/xdg-shell/xdg-shell.xml

Really anti-wayland people have not read the standard. Above was added in 2013. Before 2013 there was a absolute problem. Michael referencing early attempt of wayland with wine the early attempt was before 2013 and before xdg-shell.

xdg-shell was added to wayland in 2013. Notice the xdg_positioner bit. This functions exactly the same as the X11 windows positioning system. The only thing that is missing is the root window. xdg-shell also include the means to request maximized surface and better hidden maximized and this basically the same as a X11 root window. Difference is you have to create the root window per application if you want X11 like behaviour.

When it comes to coding applications there is not very much difference between X11 and wayland. If you are using relative positions based on the root window of X11 to have eveything work your application will have to create its only root window because wayland no longer provides this as a default item.

If you read Vincent response when he looked at it currently it seams possible with Wayland just he has not done it yet.

[Weasel]

Except X11 IPC is not sane the protocal state that it can eat a message at any time. By protocol the X11 server does not have to send you an error code if it eats your request. Sending back a invalid valid is also valid by protocol.

That's sane. The server could be overloaded, it could be suffering from DoS or otherwise the system could simply be overloaded or not able to cope.

A well-written application that follows such specs MUST be prepared to not receive something back because of the protocol being sane.

Obviously a lot of apps are written badly and will always expect something back because it happens in 99.9% of cases. That's the problem with people who want "simple code" or "easy code" and why we have so many security exploits (not related to buffer overruns).

https://github.com/wayland-project/w.../xdg-shell.xml

Really anti-wayland people have not read the standard. Above was added in 2013. Before 2013 there was a absolute problem. Michael referencing early attempt of wayland with wine the early attempt was before 2013 and before xdg-shell.

xdg-shell was added to wayland in 2013. Notice the xdg_positioner bit. This functions exactly the same as the X11 windows positioning system. The only thing that is missing is the root window. xdg-shell also include the means to request maximized surface and better hidden maximized and this basically the same as a X11 root window. Difference is you have to create the root window per application if you want X11 like behaviour.

When it comes to coding applications there is not very much difference between X11 and wayland. If you are using relative positions based on the root window of X11 to have eveything work your application will have to create its only root window because wayland no longer provides this as a default item.

Won't the app's root window be above all other windows when it's active? How do you place an app's popup on top while its root window is at the bottom? Other app windows must be directly behind your popup, which means above your root window (on X11 everything is above the root window because it is shared by all apps).

It might surprise you but people have multiple application windows on the screen at once, it's called multi-tasking.

We don't use DOS that much these days where everything is full-screen, sorry.

[oiaohm]

That's sane. The server could be overloaded, it could be suffering from DoS or otherwise the system could simply be overloaded or not able to cope.

A well-written application that follows such specs MUST be prepared to not receive something back because of the protocol being sane.

X11 protocol states its allows to return nothing or return random garbage or return valid answer. You hope for return nothing or valid answer. You really hope X11 protocol does not go for random garbage this is how you end up getting window position answers out x11 servers that are not on screen even that the window you are looking at is 100 percent on screen.

Won't the app's root window be above all other windows when it's active? How do you place an app's popup on top while its root window is at the bottom? Other app windows must be directly behind your popup, which means above your root window (on X11 everything is above the root window because it is shared by all apps).

It might surprise you but people have multiple application windows on the screen at once, it's called multi-tasking.

This is not understanding wayland.

https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_surface

wl_surface part of default wayland protocol allows ghost windows. These are windows with no boarders that are 100 percent transparent to everything include input. Yes the reasons for wl_surface::set_opaque_region and wl_surface::set_input_region.

I am well aware users want to run multi applications.

A ghost window done wl_surface wayland takes no input cannot been seen and can be made not able to be active yet you can place all your windows relative to it.

This wl_surface could be the very thing your application displayed it splash screen on while your application was starting up.

Stacking order between surfaces under wayland can be done totally independent to what you used to X\Y position. So it does not matter if your root window that is a ghost window on wayland is in the front or in the back.

Client side rendering the default of wayland makes it really simple to create ghost windows. No input anywhere on window and don't render boarder and don't allow active.


Weasel the concept of a windows that does and does not exist at the same time is something kind of unique to wayland. The fact you can create these ghost windows under wayland means that all need to save some memory is extension that allows compositor to pass around a ghost window for each display.

The big thing here is wayland does not join all the different displays into 1 big root window.

A wine virtual desktop window done with a Wayland window could be 100 percent input transparent. The only downside here is that the application using this solution under wayland is stuck to 1 monitor screen in a multi monitor setup. For majority of applications this is not a problem. The other downside is extra ram usage.

The root window requirement of X11 to be in complete at the back is not in fact required to relative positioning on a system like wayland where the window can be invisible to user and take no input at all instead pass all input to what ever is behind it as if it not there.

[Weasel]

X11 protocol states its allows to return nothing or return random garbage or return valid answer. You hope for return nothing or valid answer. You really hope X11 protocol does not go for random garbage this is how you end up getting window position answers out x11 servers that are not on screen even that the window you are looking at is 100 percent on screen.

Citation needed for "random garbage".

This is not understanding wayland.
https://wayland.freedesktop.org/docs...pec-wl_surface

wl_surface part of default wayland protocol allows ghost windows. These are windows with no boarders that are 100 percent transparent to everything include input. Yes the reasons for wl_surface::set_opaque_region and wl_surface::set_input_region.

I am well aware users want to run multi applications.

A ghost window done wl_surface wayland takes no input cannot been seen and can be made not able to be active yet you can place all your windows relative to it.

This wl_surface could be the very thing your application displayed it splash screen on while your application was starting up.

Stacking order between surfaces under wayland can be done totally independent to what you used to X\Y position. So it does not matter if your root window that is a ghost window on wayland is in the front or in the back.

Client side rendering the default of wayland makes it really simple to create ghost windows. No input anywhere on window and don't render boarder and don't allow active.

So what is the point of not allowing to query absolute window positions for security if you can bypass it so easily? This means Wayland still sucks since you have to jump through hoops while it's trivial for malware.

Something obviously tells me you're dead wrong but I've no interest in wasting time with a protocol designed by stubborn morons.

[oiaohm]

Citation needed for "random garbage".

Random garbage answer is legal because X11 is a protocol allows over network with damaged packets. Having desktop interface design to work over network and allowances of miss behavours of that written into the protocol is not good.

So what is the point of not allowing to query absolute window positions for security if you can bypass it so easily? This means Wayland still sucks since you have to jump through hoops while it's trivial for malware.

First thing always remember X11 does not have the ability to query absolute window positions. You have relative positions. So absolute window positions is talking about adding a feature that X11 does not have to wayland and that way it was rejected out of hand. Since X11 protocol never need absolute positions why does wayland protocol?

Yes X11 use global relative positions so that windows managers can control where applications put stuff.

Not having a root window by default and easiest path being pure relative positions to your own windows is not a security thing.

Its a simple problem.
Your program is doing a pop up over it window. You use real absolute position or global relative position(x11 root window). User happens to be dragging window while you attempt to draw pop up guess what pop up fails to appear above window.

Yes creating own ghost window under wayland also risks suffering for the above problem.

Not all the changes in wayland are because of security. Some are to attempt to get programmers out of using paths that cause graphics errors like pop up windows appearing in the wrong places.

Due to X11 being a little bit unpredictable on window position most native Linux applications have been using relative addressing between applications own windows this is why GTK deciding on wayland to return 0.0 for every window position request effects less than 5 percent of gtk applications.

Also if you had read the Xwayland extentions to wayland to help X11 applications work you would have also found something horrible in X11 protocol you request position for your window relative to the root window guess what WM is free to place your window where ever it feels like with what ever size it feels like. This is requirement for tiling windows managers under X11. Really what people think are fixed x/y addressed under X11 are do you feel lucky addressed based on what WM is in usage.

The security change is not root window relative addressing being gone. What was taken away for security is the the ability to see the other windows/surfaces of other applications unless you have been given permission. Yes you can be given permission if application/compositor passes you a file handle of the surface.

Global relative position(x11 root window) was not included in wayland due to the graphical issues of miss placed windows it causes. Of course this does not mean Wayland does not include in protocol the tools to-do application global relative positions instead to give the same placement results with the same downsides.

[Weasel]

Random garbage answer is legal because X11 is a protocol allows over network with damaged packets. Having desktop interface design to work over network and allowances of miss behavours of that written into the protocol is not good.

Do you know the meaning of "citation"? Guess not.

First thing always remember X11 does not have the ability to query absolute window positions. You have relative positions. So absolute window positions is talking about adding a feature that X11 does not have to wayland and that way it was rejected out of hand. Since X11 protocol never need absolute positions why does wayland protocol?

Stop arguing semantics. X11 has the root window.

Yes X11 use global relative positions so that windows managers can control where applications put stuff.

Not having a root window by default and easiest path being pure relative positions to your own windows is not a security thing.

Its a simple problem.
Your program is doing a pop up over it window. You use real absolute position or global relative position(x11 root window). User happens to be dragging window while you attempt to draw pop up guess what pop up fails to appear above window.

If you want the popup to be "above" the window then YOU MOVE IT YOURSELF with the window.

The other way around, you can't do. What if you want a popup to stay there even when the window is moved? (aka the real definition of a popup)

[oiaohm]

Do you know the meaning of "citation"? Guess not.

I do know the meaning of citation you made a claim about wayland without proper citations first. Put those up first and I will rip those apart.

The reality here I am not going to put your information in order. If you had properly compared wayland and X11 you should have all these citations already. So you asked me give you a citation on something you should have already had before claiming wayland was wrong.

If you want the popup to be "above" the window then YOU MOVE IT YOURSELF with the window.

This results in a race. As the compositor moves the window you program need to update position. This is wasting cpu time.

You have the following mess.
1) WM moves windows
2) WM informs application window has moved.
3) Application informs WM that popup need to be moved as well has had to calculate new position.
4) WM moves popup
4) Return to 1 until window stop moving.

Yes the event loop moving the pop window is eating into the applications allocated cpu time. Also you wasting lots of time in communication.

Wayland compositor.
1) Wayland compositor is moving window. Wayland compositor sees attached popup moves them with it. This does not have movement stutter.

You watch under windows and X11 as popup that are meant to be over the window by chasing the window across the screen and stuttering behind why do we have to have this artefact.

Notice something here applications does not need to process window movement events unless it wants to.

Reduced communication. Application has to tell the wayland compositor what are pop ups so this works the application only need to-do once possible millions of times per popup. If you don't want the popup effect use transient/normal window do note with client side rendering wayland windows don't have to have boarders.

The other way around, you can't do. What if you want a popup to stay there even when the window is moved? (aka the real definition of a popup)

This is not the real define of a pop up. Always use relative was first done in the first platform to have pop up windows. X11 protocol does not know what a popup is or provide the functionality to implement a original define popup window.

By the way its X11 toolkit botched implementation of pop up due to X11 limitations that creates what you incorrect call the real definition of a popup. Wayland has the original define of pop up that is not a hack around limitation of protocol. The original define of popup has the popup window staying with the window that created it as it moved.

Under wayland you can do the other way around. Don't use a popup use a transient or normal window create that will stay there even when the window is moved.

Wayland include popups and transient windows. Wayland protocol include everything to implement them all correctly.

[Weasel]

I do know the meaning of citation you made a claim about wayland without proper citations first. Put those up first and I will rip those apart.

They were put up already, the bug report YOU linked.

I don't give a single fuck about your CLAIMS, nor what you "rip apart" with your endless babbling. You claimed it gives back random garbage in the protocol -- PROVE IT. Show citation.

Your claims have zero meaning, you understand this, right?

This results in a race. As the compositor moves the window you program need to update position. This is wasting cpu time.

You have the following mess.
1) WM moves windows
2) WM informs application window has moved.
3) Application informs WM that popup need to be moved as well has had to calculate new position.
4) WM moves popup
4) Return to 1 until window stop moving.

Yes the event loop moving the pop window is eating into the applications allocated cpu time. Also you wasting lots of time in communication.

Ok? Moving the popup with a window is an extremely fringe case so at least it's possible to do.

Do the other way around with Wayland (keep popup in same place while you move the window).

You watch under windows and X11 as popup that are meant to be over the window by chasing the window across the screen and stuttering behind why do we have to have this artefact.

Because popups are not supposed to move with the window. You realize even a dialog box is a popup, right? (and no I don't care about the opinion of Wayland devs)

I've never heard of such stupidity to have the dialog box move with the window behind it. That's plain retarded. If you want it to move with the window, you make it a CHILD WINDOW of the window. What happens if you move the dialog box itself, does the window behind it move as well? So retarded.

This is not the real define of a pop up. Always use relative was first done in the first platform to have pop up windows.

Dialog boxes are popups in Windows, which puts you in even deeper shit.

[oiaohm]

They were put up already, the bug report YOU linked.

No the bug I linked did not reference the X11 protocol or wayland protocol. Not exactly what the problem was at least. You presume it was impossible.

So you have admitted that you have done no research.

Ok? Moving the popup with a window is an extremely fringe case so at least it's possible to do.

Its not extremely fringe. Motif started doing it for all you pop up off the menu bar. There are still a lot of programs out there with menu bars or equal who want this behaviour.

Something to remember X11 and Wayland support 2 or more mouse pointer being on screen at exactly the same time.

wl_subsurface::set_position does this one. (this was in the first version of the wayland protocol).

Do the other way around with Wayland (keep popup in same place while you move the window).

This is also doable. Use xdg_shell:xdg_positioner.

The protocol does not include two methods for setting window position relative to each other for no reason. xdg_shell and wl_subsurface. Motif included 2 as well.

Because popups are not supposed to move with the window.

Not 100 percent true. The first form of popup ever made moves the window when popup is moved. Its the second form ever made that leaves window in place.

Reality you do want both forms they have their places.

You realize even a dialog box is a popup, right? (and no I don't care about the opinion of Wayland devs)

The Wayland protocol include more ways to position stuff.

I've never heard of such stupidity to have the dialog box move with the window behind it. That's plain retarded.

There are some windows programs that do. The dialog is their splash screen if you move the splash screen and window is not full size it moves the window as well. What you call retarded developers do from time to time.

Motif also defined it dialogs with anchors and without anchors.

If you want it to move with the window, you make it a CHILD WINDOW of the window. What happens if you move the dialog box itself, does the window behind it move as well? So retarded.

This is only true when wl_subsurface::set_position was the only way to position a CHILD WINDOW. Using the subsurface option makes all the surfaces be processed as one entity when the compositor moves them. By the way wine virtual desktop does this under X11 trapping the mouse actions then moving the sub windows itself.

wl_subsurface::set_position provides all that is need to implement wine virtual desktop.

xdg_shell:xdg_positioner gives you multi entities for the compositor to process.

Depend on the method you chose to position with depends on what happens. Providing the options means you don't end up in horrible race conditions.

Dialog boxes are popups in Windows, which puts you in even deeper shit.

I gave you the link to the protocol I made intentional mistakes. If you had read the protocol instead of presuming stuff you would have worked that out.

Wayland protocol covers all the different usage cases.

[Weasel]

No the bug I linked did not reference the X11 protocol or wayland protocol. Not exactly what the problem was at least. You presume it was impossible.

Are you retarded? This is the first paragraph from the bug https://bugs.winehq.org/show_bug.cgi?id=42284:

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.

And FYI Wayland is a protocol.

Anything else you said is useless since it's your and the stubborn Wayland devs' shitty opinion about what a popup should be.