X11 socket to fallback to x11#75
Conversation
Though pull request will detail this a tad more: https://docs.flatpak.org/en/latest/sandbox-permissions.html#standard-permissions
To account for our changed default permissions, Wayland sector must be tweaked. This accounts for applications moving over to Wayland by default.
|
🚧 Test build enqueued. |
|
🚧 Started test build. |
For us to avoid a cursed mixture of Wayland and XWayland.
|
🚧 Test build enqueued. |
|
❌ Test build was cancelled. Help
|
|
🚧 Started test build. |
|
🚧 Test build enqueued. |
|
❌ Test build was cancelled. Help
|
|
🚧 Started test build. |
|
✅ Test build succeeded. To test this build, install it from the testing repository: Built for aarch64 and x86_64 architectures. |
|
From a feature standpoint we also support VRR and HDR better which although not really super huge for VRR in this type of application IS a great benefit with HDR. This is because x11 and thus XWayland are incapable of HDR. |
|
We also avoid issues with the whole "allow system to scale applications" vs allowing applications to scale themself. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
We also can match Electron behavior of default Wayland by doing this with fallback to X11 I realized I got off topic in previous 2 comments so marked them as such, they should be created as a new issue upstream if such doesn't exist |
The default behavior is auto now per https://www.electronjs.org/blog/electron-38-0#removed-electron_ozone_platform_hint-environment-variable
|
🚧 Test build enqueued. |
|
🚧 Started test build. |
If anything is broken in testing against it it's these flags, but I believe there should be no issues. In a moment I'll try a a test against this and if input still works in login screen I'll mark reply to this indicating such.
|
🚧 Test build enqueued. |
|
❌ Test build was cancelled. Help
|
|
🚧 Started test build. |
Regarding the "to use wayland instead"
|
✅ Test build succeeded. To test this build, install it from the testing repository: Built for aarch64 and x86_64 architectures. |
Yep, testing this it works in full on my system. We should be able to merge this. |
|
@Vendicated Since you were the one to do stuff with Wayland and x11 initially, thought you might want to check this. |
Now an if statement is used to be more accurate against the session and how application is running against it, if we're using native x11 it says so while if using X11 against Wayland via Xwayland it says so too.
|
🚧 Test build enqueued. |
|
🚧 Started test build. |
|
✅ Test build succeeded. To test this build, install it from the testing repository: Built for aarch64 and x86_64 architectures. |
Just made em more accurate and surefire. As in some cases we could have no socket granted if Wayland were we to only have x11-fallback.
|
🚧 Test build enqueued. |
|
🚧 Started test build. |
|
✅ Test build succeeded. To test this build, install it from the testing repository: Built for aarch64 and x86_64 architectures. |
|
Relevant electron post: https://www.electronjs.org/blog/tech-talk-wayland |
2 participants
Currently Vesktop gains access to both Wayland and x11 at the same time, which should not be the case.
Our default behavior SHOULD be to use Wayland only by default then fallback to x11 if it's the only present session.
From my own testing I have found better compatibility with voice calls including screenshare in such using this method and we boost user security.
Furthermore, we become more compliant to what is recommended within Flatpak's own sandbox permissions: https://docs.flatpak.org/en/latest/sandbox-permissions.html#standard-permissions
Finally: We no longer have to deal with XWayland issues. A similar issue covers this with: godotengine/godot-proposals#11583 (comment)
As a side benefit, I believe this will improve how secure Vesktop appears against some Flathub application managers, as we can reduce the "uses a legacy windowing system" warning.