My "Linux Challenge" Follow-Up

I’ve had a lot of updates. So much that I actually wrote 2 entire posts.

I was about to write up a 3rd follow-up, only to realize that I never published the other ones, so I’m going to try and condense 3 posts into one.

Art/Drawing

OpenRaster

I ditched the mdp2ora converter in favor of a custom plugin to import MDP files into Krita (link).

I was also planning to build a reference implementation for an MDP Decoder using Qt5, but I don’t know enough about Qt to get something building properly.

FireAlpaca

So, I sent an email to one of the devs for FireAlpaca about the MDP spec, and they actually replied for some reason. I was using DeepL for the correspondence and I’m assuming they were using similar translation software. Somehow, communication was really smooth and we were able to make some progress.

As of now, the MDP file format is documented on GitHub (link). There are a couple of things that are missing, like tile decoding and the MDI XML spec, but it’s better than nothing. This spec also provided information on archive compression that I didn’t know about (e.g. archives can be compressed using Zlib, Snappy, or FastLZ).

I mentioned that I’d be open to test a Linux build of FireAlpaca if they ever make one, but I understand that Linux support requires a lot more work and minimal return.

WINE and wintab32

After getting the Krita Tablet tester running in WINE (tip: disable ANGLE), I was able to determine that wintab32 doesn’t work at all. The tablet events aren’t being captured by WINE, so X11 ends up falling back on mouse inputs.

This is a regression in wintab32 and should be handled as such. Given how they haven’t really responded to the reports so far, I don’t think it’s going to be fixed any time soon (link).

My gut feeling is that this can be easily fixed by rewriting the wintab section of winex11.drv to use libinput instead of X11 XInput (link).

It might be easier to integrate the change in wine-wayland first (link), since libinput is supposed to go hand in hand with the Wayland ecosystem.

I think I mentioned my idea of overriding DLL’s for Qt5 to link to the native Linux version. The good news is that I’ve determined that this is theoretically possible using winemaker. The bad news is that this is extremely complicated and tedious to do, and it only gets harder as the library gets more complex. Qt is an extremely complex library.

I might approach CodeWeavers about this issue after purchasing one of their licenses, but I don’t know when that’s going to happen.

QEMU

I still have no idea where to start on this one, but I feel like I might need to write a new driver for QEMU, because usb-wacom-tablet just simulate a tablet via mouse input. I guess this would require me to implement a custom device for QEMU as well as to get it to link to libinput, which sounds like a lot of effort that I don’t have time for.

I also found something related to a virtio-tablet-pci device, but I feel like this requires even more research. At a cursory glance, this doesn’t handle things like pen pressure… which means I’m back to square one.

Based on XQEMU (link), adding pen pressure support should be as simple as binding to libinput and writing a hardware drier, but “simple” is a relative term.

Discord

The Steam Deck is ready to be shipped out, and the Discord Issue on Linux (link) remains unfixed.

I will not be resuming my Discord Nitro subscription until Go Live Audio is fixed on Linux.

I’m also considering deleting my account entirely (there are multiple reasons for this, not just Linux support).

I don’t believe that this will make an impact, but I might as well make my priorities clear.

Genshin Impact

miHoYo added more anti-cheat measures rather than fixing their current approach (these measures were bypassed hours after being released), so it seems like they’re doubling down on their “security theatre” approach.

I’ve stopped playing Genshin Impact. This is for a multitude of reasons, including HoYoverse’s response (or lack thereof) to my legal inquiries.

This actually wasn’t because of Linux support or anti-cheat (although those did reinforce my decision). It boiled down to the fact that I no longer enjoy the game.

I might jump back into the game, but it’s going to require a lot of changes which I don’t think is feasible given how they haven’t shown any interest in fixing things at this point.

mhyprot3.sys

Just as I was considering getting back into the game, I noticed that a new driver called mhyprot3.sys is present in the game files. The most concerning part is that this new driver hasn’t been announced in any update / patch notes that I can find, which makes me concerned.

There’s a small possibility that they’re working with the Proton team to get mhyprot3.sys working on Linux without patching, but I’m not optimistic.

There’s an even smaller possibility that they’re taking a better approach to anti-cheat by focusing less on client-side inspection and more on server side validation. This is extremely unlikely since they wouldn’t still be using a kernel driver if that was the case. Also, the new driver is larger than the old one, which means that it’s more likely that they’re doubling down on their existing approach.

Conclusion

I’ve given up on making the jump to Linux for now, but I’ve also tested the usability and support related to multiple products that I use.

Most of them failed spectacularly, which is why I’m slowly discontinuing my reliance on these services.

• I made a small donation to the WikiMedia Foundation via the PayPal Giving Fund.
• I purchased the Digital Atelier Bundle from the Krita Shop to support development.
• I still haven’t purchased a license for CodeWeavers, as that requires a bit more budgeting, but I still plan on doing so.