After several months of work, we are excited to announce a first proposal for a Wayland driver for Wine. At this point the proposal is in the form of an RFC (Request For Comment), in order to explore how to best move forward with the upstreaming and further development of the driver.
The Wayland protocol is by design more constrained compared to more traditional display systems like X11 and win32, which brings a unique sets of challenges in the integration of Wayland with Wine. Since Wayland’s window model is not based on a single flat 2D co-ordinate space, as X11’s was, the Wayland protocol doesn’t allow apps to control their absolute position on the screen. Win32 applications heavily rely on this feature, so the Wayland driver uses a few tricks to accommodate many common cases, like transient windows (menus, tooltips etc).
This is an important first step in ensuring Wine performs optimally on Wayland systems, and considering the importance of Wine for the Linux desktop due to projects like Proton, this really needs to be sorted before a full move to Wayland can be made.
I read through this and did a little digging to discover why people made the design decision of Wayland that you cannot specify absolute screen coordinates. From what I can discover the reason is security. I’m puzzled how this design design was made in the first place or why the constraint is hardcoded and what this has to do with security. I’m completely baffled by this and have a loathing of hacky workarounds so wondering what they were thinking when they did this.
Supports GDI and OpenGL/Direct3D ok. But why the lag on Vulcan?
I don’t know the ins and outs of this at an architectural level but I will take their word that having a faster path for Wine to talk directly to Wayland is a good idea. But this is beginning to raise other questions. I don’t know enough to know but rolling everything up aren’t the Wayland people unecessarily painting themselves into too many corners?
P.S. What’s Proton?
Proton ( https://en.wikipedia.org/wiki/Proton_(software) ) is Valve’s fork of Wine that they include with Steam.
Thank you!
There is more than one reason for the relative position over absolute screen coordinates.
1) is the common considered security one. Not having absolute screen coordinates application cannot go lets put a small almost not see able window over another programs input to capture something. But this is only the start.
2) is moving windows. This is the one commonly overlooked. Using absolute positions every time the compositor moves the window it need the application todo something to update all the absolute position data it has. Wayland relative positions you can move a window if it size has not changed application does not have to do anything why because all the positions the application had were relative so nothing to the application changed even that the Window moved.
3) fun one relative positions opens up for compositors to display the same window twice or more without having todo anything major-ally strange. Think about it you draw the application output twice on screens at two different locations the application does not need to know as long as the compositor knows and hands over the correct relative information with Wayland.
4) suspend and resuming of applications in future. Again this is when you resume application the position on screen it prior had many not be where the user wants it.
Win32 and X11 are 2d set of absolute positions. Wayland is something different. Wayland is a tree of relative positions. Tree of relative positions is for security and for making moving windows around require less processing.
Yes there is a lot of complaining that Wayland cannot do X when it really a case Wayland is a different model so the way you solve particular problems require a different solution.
Please note 2d set of absolute positions has its nightmares.
1) all monitors are joined up into 1 huge flat item.
2) If you are X11 all monitors are jointed up into 1 huge image to be maintained at all times.
Now here is the fun you have 3 monitors 1 2 3 on you desk on one computer. You unplug 2 and remove it what should happen now. Remember in absolute positions if 2 size is subtracted from the absolute postions under a 2d set of absolute positions all the applications on screen 3 would have to be moved in the direction of screen 1. Now you plug screen 2 back in. Reverse the process.
Ever wonder why at times you would see Linux people doing conference presentations and their laptop splat out badly with X11. Yep the image be allocated and the allocation failure equaled X11 server death.
Tree of relative positions with wayland some thing can have a relative position to X monitor. So only the applications on 2 monitor when you do that have any alteration when 2 monitor disappear and comes back in the above example. Tree of relative positions is more friendly for multi monitor setups. This is not security thing here. Wayland is newer so its designed for what the current environment said would be the future where people having 2 to 3 monitors would come more common. Issues from leads falling out of monitor and having to plug them back in would also come more common and you really don’t want to be causing a CPU spike moving applications you really did not have to in the first place other than because of the limitations 2d set of absolute positions mandate.
2d set of absolute positions as a solution for windows placement is not problem free. Wayland tree of relative positions requires a different thinking process to use.
There are a lot of complains that Wayland cannot do X when its really we cannot see how to do Y but we used X feature in the past to-do it and we are not looking for another solution to how to-do it. Lot of cases when you look at Y that they want to do there is ways inside wayland or drivers to-do it.
Thanks for the explanation. I appreciate that took a lot of writing but I’m not convinced. On the security issue I’d rather hear from a security expert who can discuss everything “in the round”. I need more than an assertion about one narrow example. If people can wangle between relative and absolute positions they can do it the other way too can’t they? Any compositor will be barfing its output to a frame buffer so issues of memory use are a moot point?
Its been years (over a decade) since I did anything with code so system calls and graphics and all the mechanics are very hazy. I cannot recall ever having a problem switching between absolute and relative co-ordinates whether in Win32 or OpenGL. There’s always built in stuff or you write your own library code to wangle this stuff any way you like. I didn’t do much work with Linux or Direct3D (read near zero) before stopping work on cross-platform stuff and GUIs but (someone correct me if I’m wrong) Win32 contains functions to translate between absolute and relative? It’s been so long I had to look it up:
https://stackoverflow.com/questions/18034975/how-do-i-find-position-of-a-win32-control-window-relative-to-its-parent-window
My basic problem from what I know about Wayland isn’t about doing it this way or that way but Wayland being a contrarian solution in search of a problem. Difference for difference sake and messing everybody about from the top level all the way into the guts of the driver for no real reason.
I also don’t use Linux. Not entirely by choice but we are where we are. I also never have and likely never will participate in Linux developer conferences so the issue of dodgy screens on X11 will never arise.
‘Any compositor will be barfing its output to a frame buffer so issues of memory use are a moot point?’
This is not the compositor barfing out its the X11 server baffing out due to having to maintain by X11 protocol that complete image of all screens has to be maintained. The problem is a device can be disconnecting and reconnecting a few hundred times a second. When you are allocating memory at that rate lot of memory can disappear quickly.
‘Win32 contains functions to translate between absolute and relative? ‘
Yes it does but does it work right with a badly time monitor drop and reconnect the answer is no because its working from absolute 2d value system and if a monitor disappears the absolute values change. There is a race condition there. If you hit it that another question.
2d absolute system runs into trouble as we get more monitors.
Hard reality at the hardware level with AMD and Intel at least everyone is done relative to monitor not some global absolute 2d system. So the X11 and windows is doing quite a bit of heavy lifting to turn what most hardware does into a 2d absolute system.
“Difference for difference sake and messing everybody about from the top level all the way into the guts of the driver for no real reason.”
That the part that is wrong. Wayland relative positioning is closer to the open source graphical drivers way of doing things. Its really simple to miss that 2d absolute position in X11 is created in abstraction layer on top the open source drivers so 2d absolute position is not in fact a feature of the in Linux/freebsd kernel open source graphics drivers. So yes 2d absolute has to be converted to a relative position tree for the GPU with X11 at least with open source drivers. Nvidia binary blob and hardware might be different with their twinview stuff but they would be the only party if any party has this 2d absolute position in hardware..
Yes the fact that X11 2d absolute position is abstraction layer kind of explains how Xwayland able to work without a lot of extra code.
I’m still not convinced. Look, I honestly don’t get what you’re getting at. You’re mixing so many abstractions and assumptions it’s all a word salad to me. I’m out.
HollyB The key point is AMD and Intel GPU are not operating on a 2d absolute position system. Neither is your arm mali gpu…. for all the gpu you find in arm SoC chips.
The only party that might be is Nvidia. Even that is not likely.
2d absolute position system is not linked every case where you can look at what features GPU have 2d absolute position system is not part of the low level hardware any more.
Wayland relative tree system is in fact closer to what the hardware really uses.
Sorry what I wrote is not assumptions. Lot of people are not aware that 2d absolute position system in X11 and Windows could be 100 percent of a time abstraction on top of a relative tree system. This is absolute the case of AMD, Intel, ARM Qualcomm. .. Fairly much everyone who is not Nvidia. Nvidia could be as well. If what implemented in the open source Nvidia is to go by the Nvidia GPU does not have 2d absolute position as feature.
Wayland having applications operate more like how most GPU hardware really works.
oiaohm,
I think you are cross talking because HollyB is referring to programming APIs and you are referring to the X11 protocol that a programmer wouldn’t typically use directly. The vast majority of programming APIs use relative coordinates (relative to the window/viewport) and those coordinates typically get converted to the underlying protocol by the toolkit. On windows using the win32 GDI graphics contexts use relative coordinates as well, OpenGL coordinates are relative, etc. The programmer doesn’t need to specify absolute screen positions to output graphics because relative coordinates make complete sense when rasterizing within a window.
However with that said, it does make sense to specify window positions on screen and practically all APIs allow this. So if a new protocol comes along and breaks window positioning functionality, that’s what HollyB sees as problematic and he’s got a valid point.
“However with that said, it does make sense to specify window positions on screen and practically all APIs allow this. ”
Alfman it depends on how you read this. Wayland does allow specifying absolute position on a single screen. By requesting a full screen object and relative positioning from that. This is the difference under wayland you remain relative always. Due to this being a relative system you request a full screen as a application and wayland compositor can decide to return something that is not a full screen and you as application has no way to know has happened.
2d absolute position system that you find Windows and X11 applications using if you have multi monitors they are all glued into a single flat plane. This is what wayland is not doing.
“The programmer doesn’t need to specify absolute screen positions to output graphics because relative coordinates make complete sense when rasterizing within a window.”
This is true that the programmer does not need to. Problem wine and Xwayland has is because 2d absolute position existed programmers have being using these positions for popup windows and the like instead of the relative coordinates parts.
Something else is important. Every time someone has requested Wayland protocol have 2d absolute positioning the lead developer of wayland has asked for a functional example of something that cannot be done in relative positioning. This means you must have attempt doing it as relative position and prove its not workable. No one so far has made example proving the need.
There is a big difference between a need and a want. Developers are use to using 2d absolute position so they want it. Do the developers really need it so far no one has proven that. Has wayland ports showing application developers badly over use 2d absolute positions hell yes.
Does miss use of 2d absolute positions cause errors hell yes. Everyone at some point would have seen the case of move a window and a popup to the window appears where the windows was. This is a 2d absolute position usage caused bug.
The hard point here will be like 99% percent of the time you should be using relative positioning. The 1% where you are not Wayland appears to be able to-do just requiring you to jump though extra hoops. But lets say we look at a win32 or X11 application before wayland what you find is 70% positioning is done by 2d absolute position. There is a big problem here. The gpus don’t process 2d absolute positions this is pushing processing on to the cpu.
Please note I said X11 application before Wayland this is important as applications get ported to Wayland there X11 form starts using realtive positioning more to the point there are now quite number of applications that use to use 2d absolute positioning with X11 that don’t use it at all any more. There is a lot of evidence so far that if you give developers 2d absolute positions they will abuse it instead of using relative positions where they should. The fact developers will abuse this feature does ask the question if it should be removed if they don’t really need it.
oiaohm,
That’s precisely the point. Some feel that this is an undesirable / unnecessary limitation. You are entitled to your own opinion, but just remember that it doesn’t invalidate other opinions.
@Alfman
Yes I feel there’s a few technical problems and a bit of crosstalk.
Also the last time I looked in the mirror I’m a Miss not a Mister.
“That’s precisely the point. Some feel that this is an undesirable / unnecessary limitation. You are entitled to your own opinion, but just remember that it doesn’t invalidate other opinions.”
Problem here Alfman. Is that no one has really proven that removing 2d absolute position system is a limitation on what you can do.
When you are scaling a low dpi application for a high dpi application on Windows you have faked over the 2d absolute position system as well.
It it really functional to have a 2d absolute position system any more particularly when scaling applications is coming a required feature with hidpi monitors.
Wine faking up it own 2d absolute position system so not using global makes scaling the wine applications simpler.
https://github.com/Plagman/gamescope
This is stuff that is really simple to forget. How may times do you want to duplicate up a 2d absolute position system.
There is a long list of technical problems using a 2d absolute position system. Does not help that its not what GPU use. People would not think that scaling a low dpi application to hidpi in a solution that expects 2d absolute position to work results in basically duplicating the 2d absolute position system over and over again.
There is a serous need to answer the question is 2d absolute position system in fact need at all. Or should we just use a totally relative system.
“undesirable / unnecessary limitation.”
The reality here is
1) no one has proven that its a limitation to what you can do not having 2d absolution position system in Wayland.
2) The claim undesirable straight up ignores all the defects developers using 2d absolute positioning causes like pop up windows on a moving window appearing in the wrong place. You can just as simple claim that 2d absolute positioning is undesirable.
You have to remember human nature is to resist change even when long term its going to be good for them.
@oiaohm
Honestly? You’re not communicating you’re talking AT people. With one simple web search I found an essay on absolute versus relative positioning systems and the pros and cons. If you want to have a discussion on this single point please explain yourself and stop beating people around the head with a stick and assuming they have psychological faults. And stop telling ex Win32 and graphics programmers what intermediate function calls and a GPU does or does not do. On top of this I’m also having problems understanding your English and getting the impression it’s not your first language.
I don’t use Linux. I have no emotional or other investment in Linux beyond the minimum. I have no dogs in the X11 and Wayland fight. If you want to win people like me over you need to communicate.
“On top of this I’m also having problems understanding your English and getting the impression it’s not your first language.
English is my first language.
“With one simple web search I found an essay on absolute versus relative positioning systems and the pros and cons.
That would most likely not cover the cons of 2d absolute positioning. This is a beast in it own right. A lot of the essays about absolute vs relative positioning are really written in the context of only have 1 monitor so skip over a huge stack of cons to absolute positioning. They would not have been talking about multi monitors or moving windows in most cases. Sorry this is not a simple web search away unless you have been insanely lucky.
I bet essay did not cover that you can duplicate absolute positioning with relative positioning. But you cannot replicate proper relative positioning with absolute positioning this is a very interesting limitation right.
There is a reason why when you get to low level graphical there is no 2d absolute positioning any more and at that level there is only relative positioning..
@oiaohm
Well if you’re such an expert on what I know or don’t know or have or haven’t read and such an expert on the whole topic please do explain. Please bear in mind I’m not listening any more but others may find it entertaining.
“Well if you’re such an expert on what I know or don’t know or have or haven’t read and such an expert on the whole topic please do explain. ”
There is a reason why I can guess what you have read. There problem you cannot google search for good documentation on a pure relative position desktop environment.
https://www.w3schools.com/css/css_positioning.asp
Like everything in css_positioning there might be a absolute word used there but its all relative positioning that is if you are looking at it as relative tree positioning.
The reality is any good paper comparing absolute and relative properly is going to say that relative tree can do absolute. That absolute is a subset of relative and has zero functional advantages over relative. You will not find this in a google search you will find it in GPU design idea theory papers from the 1990s.
Here a horrible little fact. Lets say I did a relative that there was a box covering all the monitors. 0.0 happened to be at a conner. Guess what this is 2d absolute positioning since you are just doing your positions relative to that box. Remember relative tree positioning like wayland each branch point in the tree can have unlimited number of objects connected to it.
This is the mega fun 2d absolute positioning can be done as a subset of relative tree positioning as this is just a relative tree with a single node with everything using the same starting node. The question is should you provide this. Lot of cases the answers is no.
@oiaohm
Wrong! Let it go . Seriously. Not listening. <-This.
oiaohm,
You’re focusing way too much on semantics. Obviously even “absolute coordinates” are relative to something. In an HTML page, each element is relative to it’s offset parent. But at the same time we have “absolute” coordinates, which are actually relative to the body, and the body is relative to the window, and the window is relative to the screen, etc. Arguing over “absolute” versus “relative” does not advance the discussion nor does it address the crux of the problem.
This is easily dis-proven:
https://www.enlightenment.org/_legacy_embed/group__Ecore__Wl__Window__Group.html#ga8f22e64974d91e9cd6a93927b11a7072
Your opinion may be that that window positions are not important, but not all reasonable people will share your opinion.
https://wayland-client-d.dpldocs.info/wayland.client.protocol.wl_shell_surface_set_transient.html
Alfman if you look at the wayland protocol what you got from enlightenment is simply provable as not true limitation.
There is a clear problem with the enlightenment operations. Notice that thee is no parent to address relative to in the enlightenment ones. Is this a case the enlightenment developers took the simple way out by claiming its something Wayland protocol cannot do when its something it can yes they did.
Being a relative tree positioning system you always have to state when positioning something what you are going to be relative to. If what you are positioning relative to is the full screen you are absolutely positioning like the old school stuff.
If you happen to be a low DPI application on a high-dpi screen when you asked the wayland compositor for a full screen surface it gave you a scaled one now you do the same operation and you position as per scaled coordinates not the monitor ones. Same kind of thing happens under Windows with low DPI vs high-dpi applications under windows.
Developer deciding not to jump though the hoops to implement something does not mean it cannot be done.
Wayland protocol does allow “specific window placement to be set” the big but here is it must be done in a relative way. As in you must have a surface to declare offset against. If you want to position absolutely on a screen you need to have a full screen surface that is not scaled there are ways to request with wayland. The thing is wayland is design that the compositor can scale application so wayland compositor can give application that requested a full screen surface a scaled full screen surface instead.
Alfman the enlightenment have not provided a true example that what they claimed cannot be done under Wayland. There is a in the face example that you missed that should have made you straight up call the enlightenment developers out for bogus. None other than Xwayland. Xwayland X11 windows positions are fully done using Wayland standard protocol relative operations yes “wl_shell_surface” operations. There is no specialist extension for Xwayland to work placing windows under Wayland. So there is a 2d absolute position running on top of the wayland protocol without needing any changes in the Wayland protocol to-do it. The fact there is one example does not mean other cases like Wine cannot do this as well.
The only specialist extension to Wayland for Xwayland is to deal with input devices.
Big thing here Alfman is you need to take the problem on differently. Those coming from using a absolute system like X11/Windows are not going to look for how to get X surface not scaled to position against this is not their logic of course the trap here is this is the logic you need dealing with Wayland to absolute position to screen.
Wayland relative tree positioning requires a different thought pattern. Also the wayland developers are telling application developers information windows api documentation and the like would gloss over. Like the fact wayland documentation tells you that your position is relative so it could be scaled but Windows documentation in the same location would say its a absolute position no mentioning of scaling or that the value is local to your application but when you low dpi application windows application gets placed on a High dpi monitor it gets scaled so that 10 pixels being 100 pixels on screen is not what you asked for right because applications been scaled up that what really happened. The reality is wayland protocol told you scaling was a possibility so you could not depend on 10 pixels on screen being 10 pixels on screen.
Wayland protocol is insanely truthful about what could happen. This has lead to some very bad miss interpretations of the protocol leading to people claiming that Wayland cannot do something when it absolutely can.
oiaohm,
Sorry oiaohm, you are wrong, it’s not just enlightenment. I tested top window placement in gtk and qt on the latest version of ubuntu and window placement functionality is broken using normal methods. If you think it is possible, go ahead and provide a link to working code and I’ll take a look but to be clear I’m not going to take your word over the facts.
In trying to discover what Wayland was about (and yes I have a clue about X11 and windows and OSX and D3D and OGL) and system architecture and driver models etcetra I discovered this link. Honestly? Grow up people.
https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
HollyB driver models are not part of Wayland because Wayland is reusing with open source drivers the same driver models X11 was. Of course those models turn out not include some features you would expect because the hardware does not have those features any more..
https://en.wikipedia.org/wiki/File:Wayland_display_server_protocol.svg
Notice EGL 99% of the driver stuff is totally outside wayland. EGL is a relative position based system as well.
HollyB graphical drivers for wayland are basically EGL/Vulkan with no X11 or other platform unique extensions.
Wayland drivers are basically the same ones you use when you use X11 modeset mode.
This is the point there is very little system architecture to Wayland its kept as min as possible. Wayland you are closer to the hardware than Windows, OS X or X11. This also means the real traits of the hardware of being like relative tree system instead what has been expected the 2d absolute position system.
Yes when you convert to absolute positions with opengl those are platform particular extentions to opengl not platform neutral opengl. Wayland brings you close to platform neutral.
I recall how I studied at the school and we had to write an irritating theory that I never personally liked instead of practicing continuously. I might tell from my own viewpoint that it is easier to entrust these works directly to the specialist. I know where to find them. I’ve been written http://homework-writer.com/ and no issues have been there. That is why I hope that someone else can help, because there is a lot of this kind of work now in every department. And this time, for instance, it is easier to invest wisely on auto education.