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 Ardje
The SMACH Z gaming handheld has switched to AMD Ryzen & Vega, pre-orders start soon
7 Mar 2018 at 11:24 am UTC

Quoting: JuliusHave been doing that with my GPD-Win for some time now :p
So if you have no problems with the GPD-Win, can you tell me which kernel and config you are using?
I only use the hansdegoede tree from github as that fixed a few things, but the microsd controller is such a pain... Missing hardware interrupts continuosly, stalling access to the microsd on a regular interval. It might be even bugs in the bios, or just bios settings.

The microsd card itself is fine, as it works without problems in an odroid xu4. But then again, ARM platforms usually don't need to do all kinds of weird ACPI and bios stuff... Everything is in the dtb (which BTW is part of the openboot "standard" used for Suns).

Work is under way to get proper Steam Controller support in the Linux Kernel
5 Mar 2018 at 3:20 pm UTC Likes: 1

Quoting: jensJust to be sure: FOSS and drivers upstream is cool and definitively the better way, just not the only way. There are different ways leading to Rome. I'm more pragmatic than others it seems, that's just all. Since Linux is supposed to be so much about freedom, why isn't Valve free to support their products te way they want? Valve is not forcing anybody to use their products. It works for them (and for me). People should simply choose different products and move on if they don't agree instead of cursing Valve continuously for their approach.

(English is not my native language, could be that I got your statement and the irony in it completely wrong. If my response makes no sense, then this is most likely the case.)
I do think good supported driver source eventually is the only way.
But I am pragmatic: sometimes a shortcut is easier so you know what to do for a real driver.
As the same pragmatic it usually is a good business choice to not buy hardware that has no (good) open source support. This pragmatic rule came after sinking a few thousand $ into the hardware vendor requesting them to port the driver.
Things are easy on ARM: you have opensource support, or we won't buy. Some things are not completely opensource but a large percentage of an exynos platform is opensource. At least much more than a PC.

The SMACH Z gaming handheld has switched to AMD Ryzen & Vega, pre-orders start soon
5 Mar 2018 at 1:58 pm UTC

[quote=elmapul]
Quoting: Ardje
Quoting: KeyrockThe intel SoC in the GPD-WIN has very bad (intel) support for linux. The GPD-WIN2 seems to be more pc-like and less embedded, so I have higher hopes for that. It's easier to run linux on an ARM than on a GPD-WIN :-).
I assume (without fact checking) that the AMD support is better for linux.
if you run on arm you lose all your steam games, what is the point?
The point is, is that it is a hell of a lot of work to get the GPD-WIN to work (despite Hans de Goede putting an enormous amount of work in it), let alone play games.
The specific intel SoC was not intended to run Linux and therefore all support and work arounds for it is rather new. It really is not a generic PC.
But that intel SoC is at least much more of a PC than their CE5315 and equivalents... Try to compile a kernel for that.
Anyway: as I said: it's easier to run linux on ARM than it is to run it on that specific intel SoC with full usable hardware support. And for the thing I was trying to do (run Mixxx), it probably is what I will do, as an ARM can still outperform that SoC.
The WIN2 however seems to be more PC like, and hence probably has less things to work around.
Anyway: iff my odroid had opengl support (and not gles only), it might have been faster than the WIN using qemu or eltechs exagear.

The SMACH Z gaming handheld has switched to AMD Ryzen & Vega, pre-orders start soon
5 Mar 2018 at 1:02 pm UTC

Quoting: KeyrockI wish them luck, but I think the SMACH Z is going to be dead on arrival. The price is just WAY too high for a handheld.
The price is the same as the GPD-WIN2. Lower even if you order now from indiegogo. The SoC specs are way above the GPD-WIN2.
The difference is that the GPD-WIN2 is an openpandora on steroids: keyboard, x-box type game controller.
The SMACH-Z only has the steam controller like controllers. If they really work like steam controllers, it is well worth the difference.
The intel SoC in the GPD-WIN has very bad (intel) support for linux. The GPD-WIN2 seems to be more pc-like and less embedded, so I have higher hopes for that. It's easier to run linux on an ARM than on a GPD-WIN :-).
I assume (without fact checking) that the AMD support is better for linux.

Work is under way to get proper Steam Controller support in the Linux Kernel
2 Mar 2018 at 12:00 pm UTC Likes: 1

[quote=Shmerl]
Quoting: ArdjeSee above, it's not an excuse not to upstream the driver. Proper example: amdgpu.
So you expect us linux users to wait about 10 years before there is even a proper idea how to incorporate a product into the linux kernel?
Because that's how long it took before amdgpu came to be, or even longer... And amdgpu is about a fully established and fully defined API between applications and the hardware...
There still is no clear path for the steam controller.
You can follow a design path for years and finally reach a product and conclude it was a waste of time because it doesn't work as you have now realised, or you can play with the device, reiterate the way you want to use it, and only after that look at how the kernel should be modified to incorporate support for that.
As I said: look at what valve is doing for steamvr, they are modifying and patching and updating RADV and any other *open* (I think they are now looking at amdvlk too) drivers to what they think how VR should work, and push those patches upstream, even to Kronos to adjust the specs, and the linux kernel to fix how one should look at displays.
They are going full experimental on VR, but there is still 0 working product.
They can actually do that, because they get some idea how things should work using the windows platform.
The steamcontroller was working from day 1, but by keeping the full functionality in the steam client for now, they could keep on experimenting.
Ideas seems to be stable now, and Valve helps or hints in the development of the kernel drivers.
I still wonder how, because you still need a middle layer to convert the controller input to something the application groks. And I wonder how the the force feedback API will look like... Like an alsa PCM device (*that's* how much you control you can do)? Or like a rumble pad (dumb).

Work is under way to get proper Steam Controller support in the Linux Kernel
1 Mar 2018 at 8:56 am UTC

Quoting: ShmerlWhy can't Valve make such driver and use it directly after that?
Because Valve is not expecting you to run the latest and greatest bazinga kernel on your old debian install.
What they did fits perfectly into the confined spaces of a stable desktop environment.
Everything else they do is alpha an requires you to run bleeding edge, as such they also do not advertise it as ready.
You need bleeding edge for full VR support for instance. They are constantly hacking and updating mesa/radv/anything.
But the steamcontroller is a stable product, intended for linux desktops running a stable distribution.
That's how simple it is.
EDIT:
And another thing:
When the steamcontroller became available, Valve had done some serious reworks on how to use it. Even this day I doubt it would be a good idea to set the use of this controller in stone (i.e.: the kernel). It's still not clear what is the best approach to use it. What is clear however is that Valve's tactic to rebind and make menus and other things for generic emulation of other controllers is at least 1 good approach. Binding the controller I/O dataformat also means no more firmware updates to support yet another great idea.
And great ideas to enjoy gaming even further is I think the reason Valve exists.

Playing Prey on Linux in 2018
15 Feb 2018 at 9:31 am UTC

Quoting: PatolaNice article! Can you do X2: The Threat for Linux next?
I think I can give you one for X3, from LGP:
Despite the shirt being funny, it *never* *ever* worked. (I had the signed box :-) ).
Fortunately X3 and X Rebirth is on steam with full working linux support from Egosoft.

Playing Prey on Linux in 2018
15 Feb 2018 at 9:26 am UTC Likes: 2

Oh... fsck! I gave away my dvd thinking I could get an online version. (I gave away all my physical media to whomever wanted it).
Prey was to me one of the better story FPS's.
Meeh! How can I obtain a copy now :-(.

Valve has boosted their Linux ranks by hiring another developer to work on open source graphics
9 Feb 2018 at 8:53 am UTC Likes: 1

I hope that Valve continues developing steamos under the radar. What we don't need right now is a public competitor for Windows 10S. Without competitors, Microsoft will only shoot itself in the foot like it did with IE. Of course the penalty and work needed to comply was very small, and Microsoft could hold on to monopolizing the browser "market" long enough to wipe out substantial part of the "competition".
So if we want to get the market healthy, we should refrain -for now- posing steamos as a viable alternative. We as users can though, but Valve shouldn't promote it as that (for now).

Valve has boosted their Linux ranks by hiring another developer to work on open source graphics
8 Feb 2018 at 3:55 pm UTC Likes: 6

Hmmm, it is time I do some more donations to Valve by buying some games.
Exactly this is the reason I switched from GOG to Steam...
I know that on Steam a substantial part is used for linux development. And at the same time I get to play games too.