Replace GE_WAYLAND with direct source

[nokia8801]

First of all, I get that rebasing might be hard when it comes to external patches. But I unfortunately don't agree with the things said here.

5be8536

The patches might be broken, I can't comment on that.

But when they're working, upstream winewayland and this patched winewayland is a night and day difference. Literally. First of all, the dev behind the patches fixed raw mouse input on Wayland and it feels so much better than upstream winewayland. This is necessary for competitive gameplay.

There are many more changes when it comes to mouse and input, like keyboard layouts, etc.

So I propose that instead of relying on GE-Proton for these patches, we get them from the source, which is this repo and dev.

https://github.com/Etaash-mathamsetty/wine-valve

This where GE gets them anyways.

I have no clue how this would be done though. Maybe ask @Etaash-mathamsetty for help? I remember them saying that the GE_WAYLAND stuff here in TkG was pretty old anyways, and that was months ago. So I don't think it's good to have such old patches anyways.

I tried building wine with this repo using _custom_wine_source= but unfortunately it always errors out when applying patches. It also still tries to use staging even though I have _use_staging="false".

Thoughts?

Maybe this could be a new wine-tkg profile/preset instead of patches.

[Tk-Glitch]

My comment was only about the upstream bases. Nor GE nor Etaash are using wine upstream, and the winewayland patches for valve trees are separate and not concerned by this change (see https://github.com/Frogging-Family/wine-tkg-git/blob/master/wine-tkg-git/wine-tkg-patches/hotfixes/GE/GE-for-proton10/05-proton-ge-wayland-patch.patch).

[Tk-Glitch]

Regarding building proton EM directly through proton-tkg script, that will need quite a few tweaks but ultimately I'd like to allow that, along with GE or any other proton fork. Right now we depend on the "valve" versioning for valve trees and any other will simply break at various levels. We need to make the proton script and the whole valve/non-valve separation handling more capable than the limited checks we do right now.

[Etaash-mathamsetty]

I can maintain a seperate version that consolidates everything into more upstreamable commits based on top of upstream wine. That is all work that has to be done anyways so might as well get started once I wrap up modifiers support

[Tk-Glitch]

If you feel like it Etaash, sure thing. What about staging also? The plan is to get them in down the line anyway, right? Upstreamed I mean.
Time to prepare for the EM toggle 🐸