Patreon Logo Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal Logo PayPal. You can also buy games using our partner links for GOG and Humble Store.
Latest Comments by tuubi
SC Controller driver and UI version 0.4.5 is out, last release for a while
27 Sep 2018 at 10:52 pm UTC

Quoting: slaapliedjeBeing paranoid because you might use the wrong pronoun to address someone is rather kind of silly once you think about it...
Apparently there's one thing we can agree on. It is a really silly thing to be paranoid about, and merits some self-analysis on the part of the sufferer.

My suggestion: Let's adopt Finnish as the official language of the Internet. We have no gendered pronouns to trigger this preposterous phobia.

I'll pretend you didn't write the rest of your post because it's simply too sad to contemplate.

SC Controller driver and UI version 0.4.5 is out, last release for a while
27 Sep 2018 at 6:18 pm UTC

Quoting: slaapliedjeI'm not sure how the agenda is hidden, it's pretty plain. When contributors, even of software that isn't directly part of the source code (like the SC controller that just integrates with the kernel) decide to stop developing because of it, it's already caused damage. Whether intentional or not.
He paused development to make a statement. The price of progress I guess. Maybe he'll come around when this storm in a teacup blows over.

SC Controller driver and UI version 0.4.5 is out, last release for a while
27 Sep 2018 at 5:53 pm UTC Likes: 4

Quoting: baccilus
Quoting: baccilusIs there anything in the world that can convince you that this CoC has hidden agendas?
No
I'll pretend that wasn't an attempt at sarcasm and answer: Sure there is. Or could be. Evidence would go a long way. So far we've seen nothing but heated speculation and dire predictions. On the other hand we've got thousands of projects that somehow failed to implode after adopting the same CoC.

I agree that the author of the template document obviously has a personal agenda of inclusiveness, and it's not hidden in any way. You're building them up to be an evil mastermind, when they're simply an activist who happened to write a set of guidelines for contributor conduct that was widely embraced by a whole bunch of software communities of their own free will. A tiny fraction of community members disagree (I assume) because they feel like they shouldn't be required to be respectful to people they don't like, regardless of context, and a larger minority disagrees for... various reasons that don't make much sense to me.

Steam Play set to get DXVK 0.72, Wine fixes for .NET and windowing issues
27 Sep 2018 at 5:41 pm UTC Likes: 1

Quoting: the3dfxdude
Quoting: lqe5433Wine is only working with X.org, and X.org will be replaced with Wayland really soon, so I don't see the point of this. Games should use SDL2 on Linux, or Wine needs to use Wayland.
That's the desktop-gaming oriented popular media opinion. I see linux usage in many companies, and there is no way Wayland will replace Xorg anytime soon. Xorg will continue to be the defacto standard for many years because that is where the real money is. Valve will likely continue to support the largest platform for market share as well.
I don't think either of these assessments is accurate. Most companies that use Linux simply do not care beyond the obvious: Things should work reliably and securely. Not many businesses depend on Xorg directly. This doesn't mean there's not a lot of work to do and a lot of inertia to overcome.

I can think of Redhat as one of the companies that actually do care, and they're rather enthusiastically pushing for Wayland, with Canonical now in the same boat. I don't remember any big company being against this development yet, but I might have missed something.

Steam Play set to get DXVK 0.72, Wine fixes for .NET and windowing issues
27 Sep 2018 at 3:33 pm UTC Likes: 3

Quoting: callcifer
Quoting: tuubiSince when is a Windows compatibility layer such an important concern that display server protocols should start accommodating its quirks?
Wine isn't a compatibility layer, it's the compatibility layer. When it comes to Linux adoption on the desktop it's one of the single most important pieces of software, ever.
I get why you'd say that, and I think Wine is a really cool piece of software, but it's still something I've never depended on for anything important. It was certainly not a factor in my adoption of Linux on the desktop all those years ago. Maybe the DE devs (or their employers) aren't that bothered about Windows software either.

Remember, Linux isn't a coherent community working for a single goal. We're a bunch of people and organisations with different priorities. That said, I bet a company of Valve's resources should be able to influence this, maybe by providing their own (fork of a) DE/compositor that's a better fit for Wine or simply by starting a discussion with the relevant developers.

Quoting: callcifer
Quoting: tuubiCan't speak about the DE folk, as I don't know what this would require of them. If it was mentioned in your IRC log, I'm sorry but it's too much of a wall of text to pore through.
What's required is for them to let windows position their own children. Not one DE developer managed to articulate why exactly that would be a security problem.
Wayland client windows don't know their own position on the desktop, so why should they be able to influence that of others? By my understanding of the Wayland design, if a (child) window needs special handling as a part of the UI, it shouldn't be a generic window but a surface directly controlled by the client. That's simply how the protocol was designed and I know it's different from what we're used to. This is a form of enforced sandboxing and a security feature.

Steam Play set to get DXVK 0.72, Wine fixes for .NET and windowing issues
27 Sep 2018 at 2:22 pm UTC Likes: 2

Quoting: callcifer
Wayland wouldn't have gained this much traction
On the desktop? 90%+ of Wayland usage is on not-desktop, like car infotainment systems. On the desktop, anyone using Nvidia is by necessity on X11 which, according to this very website, is almost 70% of users. So if anything has traction on desktop, it's X.
All major desktop toolkits working on Wayland support and distributions aiming to make it the default sure seems like traction to me. Of course I'm not expecting X to go away completely any time soon. Speaking of Nvidia, I expect they will come up with support as soon as their workstation clients demand it.

Quoting: callcifer
clearly not required to implement crucial features if current Wayland-compatible toolkits make do without it and have not complained about this. [...] Of course it's understandable that Wine could use a more Windows-compatible feature set and their frustration isn't unfounded.
It doesn't matter one bit what "Wayland compatible toolkits" are doing. Wine runs Windows programs. That's its entire reason of existence. As long as Windows uses windows to implement menus and dropdowns, Wine needs to do that too. So the responsibility in fixing this lies not with Wine people, but with the protocol and DE folks who, as you can see, are not interested in solving it.
I don't follow your reasoning. Wine has a problem, so Wayland needs to fix it? Since when is a Windows compatibility layer such an important concern that display server protocols should start accommodating its quirks? Can't speak about the DE folk, as I don't know what this would require of them. If it was mentioned in your IRC log, I'm sorry but it's too much of a wall of text to pore through.

Steam Play set to get DXVK 0.72, Wine fixes for .NET and windowing issues
27 Sep 2018 at 1:58 pm UTC Likes: 1

Quoting: callcifer
but if you know where a window is positioned, you can scrape its contents or whatever.
These are completely orthogonal features. Saying "put this window over there" in no way implies "also give me its contents".

Furthermore, these are not arbitrary windows we are talking about - there is a parent/child relationship here and there are no security implications whatsoever in giving a parent window full control (yes including contents) over its children. After all, this is how all the other OSes work.
If they just copied what other OSes did, how could they innovate? Wayland wouldn't have gained this much traction if it was just a more modern X. It is simpler, cleaner and more secure than what it was designed to replace.

Besides, you ignored the point that the parent-child window relationship is clearly not required to implement crucial features if current Wayland-compatible toolkits make do without it and have not complained about this. A single Wayland client can manage its surfaces as it deems necessary, but it has no way to influence those of other clients and it cannot expect to manage the desktop. The fact that this is different from Windows and MacOS is hardly a bug. Of course it's understandable that Wine could use a more Windows-compatible feature set and their frustration isn't unfounded.

Feral Interactive are teasing something for Linux next week
27 Sep 2018 at 12:57 pm UTC Likes: 3

Quoting: Guest
Quoting: tuubi
Quoting: Guestpolluting our social media
How dare they put something of little informational value in our putrid sea of toxic waste! :><:
So let me get this straight: Just because social media are already a putrid sea of toxic waste, we should add more on top of it?
A bit of marketing is like a drop in the ocean: It simply doesn't make a difference.

Quoting: GuestThese announcements are wasted energy and just NOISE. They don't increase Feral sales, they don't help Linux gaming, they do nothing but generate useless internet traffic and waste everyone's time.
I believe the contrary statements in this single thread debunk your theory. Some people obviously enjoy these messages, which means it's not a waste of their time.

Steam Play set to get DXVK 0.72, Wine fixes for .NET and windowing issues
27 Sep 2018 at 12:53 pm UTC Likes: 1

Quoting: callcifer
Quoting: tuubiI know it's inconvenient, but that "lol" is uncalled for. It's a bit over the top for most users, but not allowing access to other windows is a legit and actually rather obvious security measure.
This is not about "allowing access to other windows". The only concern here is whether a parent window should be able to dictate where a child window appears.
This does come down to the same technical decision. Don't know if this is their exact reasoning, but if you know where a window is positioned, you can scrape its contents or whatever. Of course they could add a workaround of some sort to the protocol (rememeber, wayland is a protocol, not a piece of software), but they choose not to. They probably think this is something that needs to be solved higher in the stack.

Remember that various Linux toolkits manage to provide pop-up menus that work fine with Wayland. It's just that Windows does it in an incompatible way, and Wine has to emulate that behaviour.

Steam Play set to get DXVK 0.72, Wine fixes for .NET and windowing issues
27 Sep 2018 at 12:26 pm UTC Likes: 1

Quoting: callciferUnder Wayland, however, windows are not allowed to position each other ("for security", lol) so it won't work.
I know it's inconvenient, but that "lol" is uncalled for. It's a bit over the top for most users, but not allowing access to other windows is a legit and actually rather obvious security measure. As far as I understand, this can be worked around for legacy applications on a higher level but it isn't straight-forward.