Wine Wayland Driver Takes Another Step Closer To Mainline

[Weasel]

No it because you are having the moronic design moment and failing to see the big picture. You have screen capture functionality in X11 right does this make sense when Nvidia and other GPU makers drivers are include their own screen capture GPU side that bypass X11 server and the bipass one is going to be faster.

Because that's NVIDIA specific and is also illegal, but the point is that malware doesn't care. Adding it to Wayland would have made it friendly to legit apps which have legit reasons to look at your screen. Most such apps are not going to go down the illegal, driver-specific route, because they're not malware.

Malware can do it anyway, so it's not like it gives a shit, if it has to jump through hoops. So Wayland devs refusing to add it is literally like DRM in games that shit on legit users, despite them being cracked for pirates.

Shits on legit users' convenience while pirates don't give a shit and have better experience than you do. And you're defending this? Absolutely cringe.

[oiaohm]

Because that's NVIDIA specific and is also illegal, but the point is that malware doesn't care.

AMD and Intel and others added direct from GPU to the Linux Direct Rendering Manager system.

https://ffmpeg.org/ffmpeg-devices.html#kmsgrab

kms grab implementations
Nvidia did the bipass first then everyone else copied making GPU drivers because its the best performing way to off load encoding and other things on the GPU.

Adding it to Wayland would have made it friendly to legit apps which have legit reasons to look at your screen. Most such apps are not going to go down the illegal, driver-specific route, because they're not malware.

xdg-desktop-portal is for legit applications. So legit applications can access the fastest paths without having to make wayland compositors or their main program CAP_SYS_ADMIN.

Yes xdg-desktop-portal with pipewire for screen capture allows using direct GPU screen capture on X11 as well.

Weasel you need to get your head around the requirements to use GPU accelerated screen capture and the increased performance that gives. Yes the permissions you have to hand out to allow GPU accelerated screen capture in you fairly much don't want to be doing this to any more software than you have to.

Yes modern X11 server not running as root of course could not implement GPU accelerated screen capture because it does not have the GPU access.

Malware can do it anyway, so it's not like it gives a shit, if it has to jump through hoops. So Wayland devs refusing to add it is literally like DRM in games that shit on legit users, despite them being cracked for pirates.

Yes if it jumps though hoops. Lets say people are instead use to setting CAP_SYS_ADMIN so different items work and Malware gets given this there are no hoops any more to jump though. People are going to want low latency GPU accelerated screen capture. Legit applications don't want poor performing.

Also having wayland protocol working out what application were and were not authorised to screencapture you end up remaking polkit but now you have polkit security logic on your main output loop. Big problem here Weasel polkit need to be able to display dialogs to get authorization at times. Wayland compositor stalled waiting for authorization is not going to be good.

Think about it weasel dbus completely fails due to some authorization issue the wayland compositor can operate without dbus to allow user to fix the mess.
Shoving everything into wayland protocol equals:
1) Needing to run wayland compositor at higher privilege.
2) More things in Wayland compositor to cause total failures.
Both 1 and 2 are increased security risks.
dbus was made for the job of having small services doing tasks at higher privilege than the application or the user.

Screencapture going forwards with GPU accelerated screen capture makes absolute no sense to be in the Wayland compositor. X11 protocol has screen capture because back in the day the video cards back then mostly did not have GPUs so accelerated screen capture did not exist.

[Berniyh]

I just want to see it burn.

Not going to happen. It's way too far in to stop this.
And if they do everything but your desired feature, it'll still be ok for way more than 99% of the users.
No way this is going to stop.

Mad?

No. But I still think it's really really pointless what you're doing.
But you're mainly wasting your own time, so … *shrug*

[Berniyh]

Shoving everything into wayland protocol equals:
1) Needing to run wayland compositor at higher privilege.
--snip--
Both 1 and 2 are increased security risks.

No, you don't necessarily need to do that. You can sandbox applications or part of the system without needing higher privilege.
Right now, such a thing is not implemented, so it's right to say that there isn't any "real" security advantage.
However, that doesn't mean that it needs to stay this way, it only means that it wasn't yet implemented (for Wayland specifically).

On smartphones, it's already implemented there. It could be that the desktop is heading in a similar direction in the future and Wayland could be part of it.
Maybe the Android approach (running every app in its own virtual machine) is going a bit too far and instead just separate the compositor from the rest.
Basically define rings which restrict access further, e.g.: level 0 (compositor) > level 1 (maybe something like Plasma) > level 2 (regular applications) > level 3 (restricted applications, e.g. maybe Flatpak by default or web browsers)

[oiaohm]

No, you don't necessarily need to do that. You can sandbox applications or part of the system without needing higher privilege.
Right now, such a thing is not implemented, so it's right to say that there isn't any "real" security advantage.
However, that doesn't mean that it needs to stay this way, it only means that it wasn't yet implemented (for Wayland specifically).

On smartphones, it's already implemented there. It could be that the desktop is heading in a similar direction in the future and Wayland could be part of it.
Maybe the Android approach (running every app in its own virtual machine) is going a bit too far and instead just separate the compositor from the rest.
Basically define rings which restrict access further, e.g.: level 0 (compositor) > level 1 (maybe something like Plasma) > level 2 (regular applications) > level 3 (restricted applications, e.g. maybe Flatpak by default or web browsers)

Android compositor also has a limited protocol. With the items needing to lift privilege being done over binder.

Berniyh Wayland protocol being limited and compositor only aligns for how android does it.

Flatpak portal system though sandbox is xdg-desktop-portal over dbus.
wayland design
applicaiton -> wayland compositor.
application -> dbus-> privilege dbus service.
This mirrors android
application -> surface flinger(android compositor)
application -> binder-> privileged binder service.

Wayland protocol/dbus protocol combination is the same as what smart phones do if you don't attempt to shove everything in the Wayland protocol.

[unic0rn]

I understand your point, but running Xorg apps via Xwayland in a container in a VM on a Wayland host is not really an Xorg-free desktop. It's just over-engineered Xwayland.
Cause at the end of the day, Xwayland is just another Wayland client running on a Wayland host that happens to implement the X11 protocol. Otherwise any other Wayland compositor would be considered an Xorg-free desktop.

Truth be told, we probably won't see Xwayland go away any time in the upcoming years, it's here to stay..

overengineered - for sure, but at least that has a point (security).

obviously there's a drawback too (performance penalty), hopefully more devices will get accelerated vulkan under crostini soon, at least opengl works reasonably well.

from my perspective it's just way more usable and actually feels like a wayland host should feel. there are drawbacks for sure, due to virtualization (lack of vulkan under crostini on most devices, lack of hardware accelerated video decode), but those are problems under VMs on regular linux hosts as well. mostly it acts in a reasonable and user-friendly way.

also, proper fractional scaling cannot be overstated.

it just feels like a different approach, where the OS is designed in such a way as to make everything as usable as possible. sommelier is a great example, providing fractional scaling support.

compare that with the neverending shitstorms amongst userbase and not-invented-here attitude of developers on the regular linux distro side, and it's clear why some people have little faith in linux desktop in general, and linux desktop using wayland in particular. some things just require way more cooperation between different teams than linux community is capable of.

[NateHubbard]

They won't since it works perfectly fine on X11.

Mad at facts? You clowns ask what's wrong with Wayland and why people don't use it. I answer. You want to be hidden from the answer? Bury your head in the sand, you think that's going to change facts?

Ignorance befitting of Wayland trolls.

I'm not the one that's mad. I'm the one that doesn't care about this.
I was just saying that whoever wants to run that windows app on linux is going to be the ones to have to deal with it. People like me aren't going to.

[Vermilion]

And don't get me started that Wayland is only usable if you're using Gnome.

Please stop repeating this misleading info over and over. Give Sway a try, or anything wlroots based for that matter.

I suggested wlroots based projects to you before but you don't accept their existence, probably because it doesn't match your narrative, or maybe you have a personal grudge against Sway's developer for closing your issue on gitlab.freedesktop.org (#233).

Regards, a happy Sway user.

[avis]

Please stop repeating this misleading info over and over. Give Sway a try, or anything wlroots based for that matter.

I suggested wlroots based projects to you before but you don't accept their existence, probably because it doesn't match your narrative, or maybe you have a personal grudge against Sway's developer for closing your issue on gitlab.freedesktop.org (#233).

Regards, a happy Sway user.

Sway?

1. In my XFCE systray I have this:

• CPU/WiFi temperatures
• GPU temp/power consumption and operating parameters
• CPU operating frequency
• Bitcoin exchange rate from two different sources
• Clipboard applet
• Screenshotter applet
• IO monitor for my SSD
• CPU use monitor
• Network IO monitor
• My IP address and country (I use VPN a lot)
• Bluetooth/NetworkManager applets
• Battery status monitor
• Outside temperature and weather condition applet
• Keyboard layout applet
• Lots more, I'm just tired of typing.

2. XFWM has multiple features which aid window management: keep on top, pin to all virtual desktops, launch a new instance of an app, move to another workspace (virtual screen).
3. I need normal desktop notifications, not something as basic as Mako.
4. I have directories, files and application launchers (all of which I use regularly) on the desktop.
5. Multiple easy to use/remember shortcuts.
6. Applications which start automatically on logging in.
7. Automatic session locking (via a timeout or when I close the laptop lid).

Do not BS me with "Sway" as a replacement for XFCE/Gnome/KDE. I need a fucking full-featured desktop environment, not a puny window manager/compositor.

I've trialed Wayfire (the most full featured Wayland compositor) and it misses 90% of the features I need. It's basically abandoned now.

I'm not against Sway or your workflow. I just have different very important requirements.

[smitty3268]

A ton of Windows application have menus. If you resize the main window to be small enough, menus must be rendered far outside the main window. Check the attached screenshot.

Would be great if enlightened Wayland experts here explained how it can be "easily" achieved under the Wayland compositor.

I'm not up to date on how the wayland WINE implementation works, but my understanding was they just create an invisible root window that covers the whole screen. Then they can render win32 apps inside that however they want, with full control over everything. It means WINE has to handle all that code itself rather than relying on X to do it for them, but I don't think it's that difficult.