Quoting: ripper81358I tried it and it worked on my end with Kubuntu 22.10 and Plasma 5.27. As of now some Apps are only working with it when installed as native packages. There seems to be a problem with universal packages (Snaps and Flatpaks) in some cases.

Developers of Electron based Apps should upgrade to newer Electron releases and enable pipewire. Pipewire runs on Wayland and X11. There are also other reasons besides linuxspecific stuff to keep Electron up to date. Older Electron releases have a very long list of security issues. This should have been fixed for a long time.

Looking at how browsers need constant and swift updates to avoid hackers,it's pretty obvious Electron apps should be using an OS-provided electron component that gets updated regardless of any effort by each electron-based app dev... but then they'd probably break all the time because those apps usually do hackish things instead of strictly adhering to standards and use browser-component version freezing as if it were a valid solution to those breakages and not a menace.

View this comment - View article - View full comments

Quoting: Linas

Quoting: MayeulC

Quoting: LinasSomething like that should really be built into Wayland.

I'm not sure if you mean screensharing or that video bridge? [...]

Should it be in XWayland? Maybe, but this modular solution is good as well.

What I mean is that there should be a way for legacy apps to continue functioning, including screen sharing. Otherwise we end up with a chicken and egg problem where people cannot switch to Wayland if their apps don't work, and apps won't support Wayland if nobody uses it.

They already can (this app is in fact proof of that), but in X.org any app could see any other app (or the entire user's screen for that matter) at any time, without explicit user consent.

It was actually barely impossible to block an app from seeing others even if you actively tried to... and that's the gaping security hole that strongly motivates the switch to Wayland.

You'll notice that the new app's dev comments on their blog that they could've even made it entirely automatic, so any app could see any other app without asking the user anything, if their solution was designed slightly different... but they chose to design it in a way that both makes things easier and still keeps you safe from silent snooping.

View this comment - View article - View full comments

Quoting: minidou

The problem is that currently in the likes of Discord, MS Teams, Slack, Zoom and others that you run through Xwayland, you may end up with a black screen and no windows listed — this should solve it.

I don't understand which case this will help that xdg-desktop-portal-wlr doesn't handle.

If you read the details you'll see their app is a convenient GUI for a non-expert user to be able to leverage what already exists (xdg-portals, pipewire, etc) through a system tray minimalist app

how do you leverage xdg-desktop-portal-wlr at the moment?

View this comment - View article - View full comments

Quoting: TheRiddickIs Zink doing performance fixing on a per Game basis? if so it may take them a few hundred years to catch up. lol

They are, but most often than not it's not really for 1 game, just a more general improvement noticed because it affects 1 game more so that is what is noticed and triggers the effort to fix/improve it

Same thing as happens with WINE, where fixed bugs are even listed in changelogs in the version they notice a reported issue was fixed, not in the version that actually fixed it (because they often only notice a change helps game Y much later than it was made to help another issue in game X)

View this comment - View article - View full comments

Quoting: slaapliedjeHa, at this point there are too many wrappers with various names. For some reason I was thinking Zink was a macOS thing, and was surprised to see the article here initially. Since macOS doesn't actually have Vulkan support directly, I was thinking translating Vulkan to OpenGL makes more sense there.

https://www.phoronix.com/news/Zink-macOS-OpenGL-Vulkan [External Link]
That's likely where I got that idea.

Native OpenGL support on MacOSX and iOS has been deprecated years ago (meaning they won't outright remove it but they won't improve it nor fix it when it breaks)

Vulkan over OpenGL is very hard because it's a more flexible API that more closely resembles how a modern GPU works internally, while OpenGL is more abstracted and high-level, so it does a lot of stuff in the background for each command... easier to ask it to do X but harder to optimize (and damn hard to make it do exactly each thing you can do in vulkan without crazy wasteful workarounds). OpenGL over Vulkan isn't easy, but it sure is much much easier than that.

MacOSX and iOS also have no Vulkan support, but their Metal API is quite similar to Vulkan so there is MoltenVK to translate Vulkan to Metal... and this works quite cleanly with mostly zero overhead, the entire vulkan featureset and no big quirks.

It works so well that using Zync to provide OpenGL over Vulkan over MoltenVK over Metal works pretty much as expected when Zync is just running over Vulkan... and it is something pretty useful to have there because of OpenGL being deprecated.

For continuously developed apps like an Office Suite Apple's pressure over app devs seems reasonable (eg: making every app use the best APIs available and etc), but for gaming it's an impossible long-term proposition (because old games frequently don't even get simple updates, much less entirely rewritten).

What makes it a bit less impossible are exactly the efforts of 3rd-party opensource devs like the ones behing Zync, MoltenVK and etc.

In that realm it's hard to not admire the stuff that's modular, stackable, fully compliant to open standards, cross-platform, open to new maintainers so the torch is passed along and almost never goes out, etc.

View this comment - View article - View full comments

"spark a debate" is not necessarily bad for Valve either, quite the contrary!

it doesn't even matter too much if the scrapped assets are horrible or better than the final ones, this can only increase interest in those aging games and increase their lifespan...

...unless they're Blizzard and the game assets somehow turn into extra proof of an office harassment culture, then it's a real problem for them, but so far this has never been the case with Valve AFAIK :huh:

my point is that this kind of feels like those certified 100% organic "leaks" of GPU and CPU specs one week before the official announcement

View this comment - View article - View full comments

Yeah, this is superbad for Valve... all those old and unused game resources for games that sold zillion copies or are F2P are sure to convince people to de-buy the game or play the resources without the games... lol

I just expect Valve will make fun of it and turn this into positive marketing for their games division, not that they need any help keeping people engaged

View this comment - View article - View full comments

will they enable this to work between desktop clients or just desktop >> deck ?

View this comment - View article - View full comments

gamescope is under Valve's direct control and is the piece of tech behind the Steam Deck's "Gaming Mode" (the one where Steam and every game you play run fullscreen)

It's not surprising that this was where they put the initial effort, but I expect GNOME's mutter and KDE's whatever-it's-called will move to support it soon too

A lot of work is in parts of Linux that are used by all DEs in all distros, so things should be much easier to close the gap once it's all upstreamed

ps: using HDR in monitors without good backlight intensity variation per screen region or pseudo-HDR where not even software-controlled backlighting exists is IMHO a trap... you end up with faded colors, almost totally blackened and whitened areas, or with ugly wide stripes of bright and dark across the monitor/tv...

View this comment - View article - View full comments

Quoting: BlackBloodRumOne of many reasons why you shouldn't use Epic Store, nor trust their EAC or EOS. :happy:

But people were told and warned many times in the past, but continue to do so thus at this point they cannot complain about it :grin:

I know what you mean, but really it's important to be clear: yes they can and should complain, even if previously aware of the issues, because...
1) Epic broke laws to do it
2) Epic lied about what was being done
3) It's not trivial to detect this sort of thing on your own
4) The crushing majority of people echoing complaints about Epic's disregard to privacy fail to link the complaint to a credible source, so it looks like the claim is crazy unreal when in fact Epic actually did something crazy horrible in real life
5) Most people don't delve into privacy issues enough to actually understand the extent nor the damage damage, even after "being told" it happens... It's not necessarily because they would be OK with it if they actually grasped the full scope of it, but often just because they have enough other serious things on their mind... IMHO this is especially true when talking about issues embeded in their leisure activities

That's why strong enforcement by a specialized taskforce is indispensible and can yield such surprising results when it finally materializes.

View this comment - View article - View full comments