Frogging-Family / wine-tkg-git

The wine-tkg build systems, to create custom Wine and Proton builds
893 stars 163 forks source link

[Question] Dualsense input through Steam and Wine #784

Open gabriele2000 opened 2 years ago

gabriele2000 commented 2 years ago

Basically I noticed that, with the new beta update of steam, I can use the improved basic rumble (that comes with the latest firmware). The thing is: what if I want to run WINE-tkg and not Proton? In WINE I have the "standard" basic rumble, which is super-aggressive, like always on maximum.

Is there a way to make WINE behave like steam on the input side?

Tk-Glitch commented 2 years ago

Steam-input isn't part of Wine, so it's most likely not something we can directly handle, at least not in the way Steam does it. That being said, if Steam is running, you can tweak the desktop profile in the controlled settings, which should get picked by any app you run and as long as Steam is running in the background.

gabriele2000 commented 2 years ago

Steam-input isn't part of Wine, so it's most likely not something we can directly handle, at least not in the way Steam does it.

Ok I undestand. Still, is it possible to use the improved haptic on WINE without Steam running? Since it's related to the controller firmware, in theory it should be possible or am I missing something crucial?

Tk-Glitch commented 2 years ago

I think I found the culprit. The feature was enabled in SDL2 less than a week ago (https://github.com/libsdl-org/SDL/commit/b0e827fb65eaff7d48cac0f87978c96179811789), and isn't part of any point release just yet. Since Wine will use the OS shipped SDL2 lib, the feature isn't available to it. You could build and use sdl2-git and lib32-sdl2-git from the AUR if you're on a pacman distro to get the feature or just wait for the next SDL2 update.

gabriele2000 commented 2 years ago

I think I found the culprit. The feature was enabled in SDL2 less than a week ago (libsdl-org/SDL@b0e827f), and isn't part of any point release just yet. Since Wine will use the OS shipped SDL2 lib, the feature isn't available to it. You could build and use sdl2-git and lib32-sdl2-git from the AUR if you're on a pacman distro to get the feature or just wait for the next SDL2 update.

Awesome! I'll try when it finally updates itself (I tried to compile it, apparently I miss a shitton of headers and no luck)

By the way, I'm gonna ask you a favour, if you want to help me. Basically I want to use Wine-tkg builds from Kron4ek and they're awesome, they has your patches and they're just wow! So, I've asked him to try to compile wine with the PROTON_BATTLEYE_RUNTIME env var support but I guess it's not enough. Why? Proton-ge-custom... I don't know how it works, I want to have one Wine for everything and I'm a noob with configuring the builds, plus I'm on Pop!_Os and I read your disclaimer about 32-bit libraries.

https://github.com/Kron4ek/Wine-Builds/issues/68

Fox2Code commented 2 years ago

It's not enough because of how steam handle anti-cheats, to be simple steam run wine in a specific linux container, so even if you set the right argument in PROTON_BATTLEYE_RUNTIME (Which only steam is supposed to do), the anti-cheat will fails to load as the container does not match what the anti-cheat expect because wine-tkg does not run inside the steam container.

TL;DR Proton-tkg run inside steam container, Wine-tkg does not, and anti-cheats can only run inside steam container.

gabriele2000 commented 2 years ago

It's not enough because of how steam handle anti-cheats, to be simple steam run wine in a specific linux container TL;DR Proton-tkg run inside steam container, Wine-tkg does not, and anti-cheats can only run inside steam container.

So, basically Steam is taking the monopoly? No thanks

Fox2Code commented 2 years ago

Well, you can try to use steam runtime container, or do something similar enough that anti-cheat don't complain.

I think steam runtime is based on Ubuntu 12, but I didn't dived further into that so I'm not sure.

It would probably be possible to replicate steam runtime with only open source components.

gabriele2000 commented 2 years ago

It would probably be possible to replicate steam runtime with only open source components.

I hope one day I'll be able to just use Wine, because it's turning out that steam-gaming is dangerously being tied to Steam, at least those who use anticheats.

Though, I remember that one day, a year ago, I used system-wine through a variable, inside steam, but I don't remember which ine it was

Tk-Glitch commented 2 years ago

So, basically Steam is taking the monopoly? No thanks

Steam is offering an environment tolerable enough for anticheat companies to accept working on and offering Wine compatibility. That's slightly different imho. Considering lackluster Wine security and the fact that what should be running at kernel level runs in userspace, making those anticheats check for a specific "trusted" environment (provided by Valve in this case) only makes sense. Without Valve being trusted by those companies, their anticheat being supported in Wine simply wouldn't have happened, or at least not for another decade or two of Wine development (and even then, they would probably have Wine detected and blacklisted). In the future and if Linux gains enough momentum as a gaming platform, anticheat companies might -eventually- consider opening up and injecting money to make their own "trusted environment", but that will take time.

Right now we have the Valve-provided environment available to us and people are already exploiting it to run non-steam EAC games such as Fall Guys. That's not something I'm willing to offer support for myself (it has nothing to do with my current projects) and you'll find guides on reddit and other sources as to how to make it work.

Though, I remember that one day, a year ago, I used system-wine through a variable, inside steam, but I don't remember which ine it was

Proton is just a Wine build launched through a python script + a few game compat hacks, QoL additions and a couple Steam client specifics (to make it work transparently with the Linux Steam client). It's not the exotic thing you seem to think it is. You can build proton-tkg against upstream wine and without the Steam client specifics (using the _steamclient_noswap="true" and optionally the _protonify="false" options) to effectively make use of upstream wine in the Steam client if that's what you want (of course it'll break Steam games without those interactions, but non-steam games don't need those).

gabriele2000 commented 2 years ago

Steam is offering an environment tolerable enough for anticheat companies to accept working on and offering Wine compatibility.

Steam is the same client that KILLED hundred of GB's worth of data because one simple thing called "appmanifest" was missing or somehow "damaged" and even editing it didn't make steam go "oh the game is actually there, no need to WIPE IT and redownload it". Don't get me started about the "entire downloads of workshop items" (Arma 3 mods and stuff, 100GB+ of things) bug. Just a week ago I installed The Cycle on Steam and the client just wiped it because... because I CHANGED PROTON... wtf man? Redownload it?

-Steam UI was updated but only the Library UI

-Friend list is detached from the main client so I can disconnect from it RANDOMLY but Steam is still picking up internet, maybe even downloading stuff. Double connections, nice.

That's why I'm playing it through Heroic, it won't EVER mess my installation folder and I can use Proton-ge, Proton experimental and stuff... win-win Oh, and I can import games without too much hassle.

Proton [...] Is not the exotic thing you seem to think it is.

I know it's not Dark Magic(tm). Still, that few QoL, hacks and stuff matters a lot since they're so tiny yet they solve HUGE problems... as far as I know, they won't contribute to plain WINE at all, but correct me if I'm wrong.

I know I could compile everything from the tkg builds and one day I'll really do it, I have a school exam in a few days so I can't really concentrate on it like I want to do.

Thanks a lot for the clarification anyway, I just have a lot of hate for Steam and no-half-life-3 company, ffs I wanted it

LATE EDIT: I'll use Wine for everything that's outside Steam (90% of my games and programs) and Proton-ge (when it works, otherwise Proton Experimental) Still I'd like just one, better and faster, version of Wine... Why? Comfort

Tk-Glitch commented 2 years ago

Steam is the same client that KILLED hundred of GB's worth of data

I've lost about 2 TBs of games to the - now fixed - proton unlinking issue (which motivated the creation of a tool to handle it with proton-tkg https://github.com/Frogging-Family/wine-tkg-git/blob/master/proton-tkg/proton-tkg.sh#L600) so I'm well aware. Clearly there's more to fix and QoL options to add, but that takes time.

as far as I know, they won't contribute to plain WINE at all, but correct me if I'm wrong.

They do and they also are the largest income for Codeweavers (the company building Wine).

Thing is, Proton addresses some issues in hacky, user-oriented ways, while Codeweavers wants to do it in a full correct way in Wine even if it takes a decade more. Of course the "hacks" and QoL enhancements that don't exist on Windows are invalid for Wine upstream, only the clean implementations. That's how we got Proton. Both positions are valid depending on what you want to do, but for gaming, Valve's effort simply made something that was - let's face it - unpractical and overall terrible actually a decent option vs Windows.

You can hate them, but without them wine-tkg-git wouldn't be a thing as wine-tkg's initial release was a port of the (unknown by the public at the time) Esync project to wine-staging (Esync being funded by Valve, and developed by a Codeweavers employee). Let alone DXVK/VKD3D-proton, Fsync (and its upstreaming in kernel 5.16), ACO for mesa's RADV etc.

The Steam client has its flaws and the Wine integration with Proton wasn't the smoothest ride, for sure. Yet without Valve most Linux gamers would still either dual boot or use a VM with passthrough. The Steam client issues are such a small thing compared to the game changing "comfort" (to re-use your terms) that we got even outside Steam - for free.

I can only be grateful to them for making things that much better, even if there's still a long way to go..

..And even if there's no Half-Life 3..

..Yet?

Thanks a lot for the clarification anyway

You're welcome!

gabriele2000 commented 2 years ago

I've lost about 2 TBs of games to the - now fixed - proton unlinking issue

Nah man, just the classic bug that redownloaded your entire workshop subscriptions and the faulty mess that appmanifest are (a text file that if you delete it, Steam goes brrr)

They do and they also are the largest income for Codeweavers (the company building Wine).

Hmm, I knew that... -wine was the main project -crossover was "paid wine" plus more hacks Then I discovered that codeweavers contributed A LOT in the wine project, like 90% of commits?

Now I'm discovering that codeweavers are actually 100% Wine and not just the "paid Wine" version (which I thought it was a kind of fork)

Thing is, Proton addresses some issues in hacky, user-oriented ways, while Codeweavers wants to do it in a full correct way in Wine even if it takes a decade more.

That explains A LOT (and honestly it pisses me off a bit)

Valve's effort simply made something that was - let's face it - unpractical and overall terrible actually a decent option vs Windows.

Heh, I still can't open Devil May Cry - HD Collection for ntdll.GetPathFromUrl not implemented

You can hate them, but without them wine-tkg-git wouldn't be a thing

I hate that it's the little things that causes a lot of problems overall... by the way, the Steam Deck is really cool for me, maybe overpriced (and the SD slot for expanding the storage, well... unusual but hey, a fast SD is a thing I guess)

I can only be grateful to them for making things that much better, even if there's still a long way to go..

Your explanation changed my view a lot actually... I won't see Valve as bad as I thought it is. Still, I hope that wine devs will wake-up one day and maybe: -say goodbye to mailing lists, we're in 2022 -DXVK, VKD3D, DXVK-NVAPI inside wine, NOW -pipewire -wayland, I'm almost, I wanna see it before I'll be 25 please, even it in three years I guess they'll make it.

..And even if there's no Half-Life 3..

..Yet?

I guess Half-Life Alyx was their redemption and I want to play it someday... but damn, what happened to Gordon Freeman? Did he finally learn how to talk?

Thanks a lot for the clarification anyway

You're welcome!

I swear if I seemed a little arrogant and stuff, I apologize.

I'm a big fan of your project, for me THIS is the wine that should be upstreamed.

Tk-Glitch commented 2 years ago

Your explanation changed my view a lot actually...

Sometimes, bad experiences can make it hard to take a step back. I'm glad I was able to give you food for thoughts :)

I swear if I seemed a little arrogant and stuff, I apologize.

No worries, I was sincere. I understand your frustrations.

I'm a big fan of your project, for me THIS is the wine that should be upstreamed.

Well I'm glad you like it, it was made to be useful, right? :frog: I'm thankful to all the people working on Wine, Proton, and contributors to frogging family projects. My work is pretty much a big thank you to them.

gabriele2000 commented 2 years ago

AWESOME! So am I right to think that SDL and Steam input are actually the same in term of capabilities?

Il gio 23 giu 2022, 16:15 Etienne Juvigny @.***> ha scritto:

I think I found the culprit. The feature was enabled in SDL2 less than a week ago @.*** https://github.com/libsdl-org/SDL/commit/b0e827fb65eaff7d48cac0f87978c96179811789), and isn't part of any point release just yet. Since Wine will use the OS shipped SDL2 lib, the feature isn't available to it. You could build and use sdl2-git and lib32-sdl2-git from the AUR if you're on a pacman distro to get the feature or just wait for the next SDL2 update.

— Reply to this email directly, view it on GitHub https://github.com/Frogging-Family/wine-tkg-git/issues/784#issuecomment-1164462600, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC47ERMIZB5MGVMKAORVFTTVQRWOLANCNFSM5ZERMANA . You are receiving this because you authored the thread.Message ID: @.***>