My "Linux Challenge"

Update (01/02/2022): Happy New Years. I realized there was a typo in my section about the OpenRaster spec. On further investigation, I found some info about the status of the spec which required me to rewrite chunks of that section as well as the conclusion.

Linus Tech Tips did a Linux Challenge a while back where they tested to see if they would be able to use a Linux-based OS as their daily driver for a month.

This caused some discussion among the community (some good, some bad), but my perspective is that the hurdle to jump to Linux is the lowest it’s ever been.

Based on the increased Linux support for applications as well as the drastic improvements in WINE, I tried to make the jump again… and failed.

This is a log of the issues that I encountered as well as my attempts to resolve them. I also include some criticisms where I believe it’s due, but my goal is to fix these issues rather than to continue whining about them.

Art/Drawing

I like to do digital drawing. I’m not very good at it, but I like to practice and make simple designs. Art is one of those things which requires practice, and I need to stop doing crazy stuff like this so I can actually practice.

Anyway, the majority of the software that I know of for 2d drawing are Proprietary and Windows-only… so there’s my first hurdle.

Absolutely Proprietary

I use Krita for most of my quick sketches and designs. I’ve started to use CLIP STUDIO PAINT for higher-effort projects. My friends use FireAlpaca, Medibang Paint, and Paint Tool Sai. I sometimes use those apps in order to convert between formats with the exception of Paint Tool Sai (it’s complicated).

All of those applications with the exception of Krita are proprietary and don’t have Linux builds available.

So, I either need to figure out a way to get those running on Linux or I need to figure out some way to pass files between different applications.

OpenRaster

My initial plan was to get interchange working and call it a day. My application of choice was Krita at the time, so all I really needed was to be able to exchange files with friends.

Most drawing applications use PSD files as an interchange format, since Adobe Photoshop was (and arguably still is) the general standard for 2D art at the time.

The only issue with this is that there’s no official spec that’s publically available, which means every non-Adobe application is basically winging it and hoping it works.

Krita has a decent explanation for this in their docs (link), but I prefer the more vivid explanation that my friend sent to me.

At this point, I’d like to take a moment to speak to you about the Adobe PSD format. PSD is not a good format. PSD is not even a bad format. Calling it such would be an insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format. Having worked on this code for several weeks now, my hate for PSD has grown to a raging fire that burns with the fierce passion of a million suns. If there are two different ways of doing something, PSD will do both, in different places. It will then make up three more ways no sane human would think of, and do those too. PSD makes inconsistency an art form. Why, for instance, did it suddenly decide that these particular chunks should be aligned to four bytes, and that this alignement should not be included in the size? Other chunks in other places are either unaligned, or aligned with the alignment included in the size. Here, though, it is not included. Either one of these three behaviours would be fine. A sane format would pick one. PSD, of course, uses all three, and more. Trying to get data out of a PSD file is like trying to find something in the attic of your eccentric old uncle who died in a freak freshwater shark attack on his 58th birthday. That last detail may not be important for the purposes of the simile, but at this point I am spending a lot of time imagining amusing fates for the people responsible for this Rube Goldberg of a file format. Earlier, I tried to get a hold of the latest specs for the PSD file format. To do this, I had to apply to them for permission to apply to them to have them consider sending me this sacred tome. This would have involved faxing them a copy of some document or other, probably signed in blood. I can only imagine that they make this process so difficult because they are intensely ashamed of having created this abomination. I was naturally not gullible enough to go through with this procedure, but if I had done so, I would have printed out every single page of the spec, and set them all on fire. Were it within my power, I would gather every single copy of those specs, and launch them on a spaceship directly into the sun.

PSD is not my favourite file format. - paracelsus (link)

You’d think that this is such a weird occurence that nobody would encounter an edge case.

…

I’m still trying to document the minimal steps required to reproduce, but I did in-fact encounter such an edge case. The error message provided by Krita was so unusual that I still haven’t figured out what’s really causing the error.

So yeah, it’s possible to encounter this issue in the wild.

The OpenRaster format seems to be the perfect solution. The format is mainly designed for interchange, so there isn’t really any application specific stuff in there to worry about.

I was starting to move from Krita to CLIP STUDIO PAINT at the time, so getting Open Raster support in there would be the best case scenario. I reached out to CELSYS (publisher of CLIP STUDIO PAINT) about adding Open Raster support and… they said they’ll look into it. I’m not expecting any progress on that front, but at least I tried.

I reached out to devs behind FireAlpaca and haven’t recieved any response, so it’s probably easier to implement support myself.

The MDP file format used by FireAlpaca and Medibang Paint doesn’t have a public spec, so I’m working with some friends to reverse engineer the spec (link) as well as make a converter to OpenRaster.

When I tried to find out more about the Open Raster spec, I discovered that it’s kinda in a weird state of limbo as part of a migration. The Open Raster spec seems to be abandoned since the org/repo admin (Andrew Chadwick) has gone silent and nobody else has access to fix things (link).

I tried to reach out publicly (link) as well as attempt to help out with documentation (link).

I later discovered that OpenRaster spec was taken over by the KDE foundation after what I assume were multiple failed attempts at communication (link)

I’m going to reach out one more time once this post goes live, but to Andrew Chadwick, if you’re reading this I suggest either deleting the org or pointing to the new repo to avoid confusion. Feel free to reach out to me there’s any way I can help.

WINE and wintab32

During that deep dive, I started using CLIP STUDIO PAINT more and more (I own a license), so I wanted to try and get it running via WINE.

CLIP STUDIO PAINT has it’s quirks when running in WINE because of how it does phones home every now and then (akin to online DRM), but I encountered an even greater issue which affects all 2D drawing applications running via WINE.

As of the time of writing, the latest staging build of WINE doesn’t properly implement wintab32, which means that you don’t get pen pressure when using a graphics tablet.

Based on the Bug entries, this was most likely broken multiple major version releases ago, and nobody was able to verify / debug that it was broken.

I posted my notes on one of the many bugs reports for this issue (link), but I wasn’t very hopeful. That wasn’t really working out, so I reached out to CodeWeavers, who offer a product called CrossOver, which is based on Wine. They usually merge any changes they make back into Wine, so their main selling point is support.

So… here’s the deal. I didn’t want to pay for something that wasn’t going to solve my issue. I engaged their support to determine whether the wintab issue was fixed in CrossOver and hasn’t been merged into Wine yet. We determined that CodeWeavers didn’t have any changes that would fix this issue at that time. I gave them a bunch of technical details and they weren’t really prepared for that level of depth. They redirected me to the Wine IRC channel, which is fair since I never actually paid for the product.

After a further deep dive, the issue seems to be related to how Qt5Gui.dll uses wintab32.dll instead of Windows Ink. This got me thinking whether it’s possible to write a shim so that the app would just run using native Qt5 .so files instead of using the .dll files. I haven’t moved forward with this idea, but it seems like the easiest solution to my problem.

I wasn’t able to get the issue resolved, but this was the best support I’ve experienced so far for this project. CodeWeavers support for non-customers is better than a lot of the support that I’ve recieved so far as an actual customer. I’m probably going to purchase a 1 year support license from CodeWeavers for CrossOver based on this experience alone.

QEMU

I’m going to try doing a USB passthrough to a ReactOS VM running via QEMU and see if wintab works. If that doesn’t work, I’ll try doing the same thing with Windows 10 Ameliorated.

QEMU has an emulated usb-wacom-tablet input device which should do the trick. The only issue is that it’s undocumented.

I haven’t actually started on this yet and would appreciate any assistance as I have no idea where to start on this.

Discord

I use Discord to chat with people as of recently. It’s a decent service and I’m currently paying for Discord Nitro, as I like supporting things that I like and find useful.

I only have a couple of complaints with Discord. The one that’s relevant to this post is the sub-par Linux Client Support.

I have a lot of friends who game on Linux, and audio streaming still doesn’t work for them. This is a known issue (link) and it’s going to affect more users with the surge of new Linux users after the release of the Steam Deck.

This was briefly touched upon in LTT’s video (link)

This probably isn’t a high on their priority list because the Linux user base doesn’t make up enough of their profit margin. The issue with this is that people who do use Linux don’t like paying for Nitro when a chunk of the features don’t work.

All the solutions that I’ve heard to fix this involve alternative clients and/or other changes which break Discord TOS. I don’t like breaking any TOS, even if the TOS is scummy, but it’s getting really hard to wait for Discord to fix this when the founder decides to start messing around with Web3 integration when one of the already existing features still doesn’t have proper support.

The fast and easy solution is for Discord to change their screencapture logic to match mainline electron specifially for Linux and disable their custom window selection stuff so it all operates the same way that mainline electron does (something involving WebRTC and PipeWire, idk).

Jenshin Genshin Impact

I play a game called Genshin Impact. There are many issues with everything surrounding the game, but I enjoy playing the game. I also played Honkai Impact 3rd up until very recently. I also played Tears of Themis for a week or so. I’ll probably play Honkai: Star Rail once it exits Closed Beta.

There are a lot of things that I could say about this game and the company behind it (PR, support, community engagement, basic QA testing) which were present in the original version of this post, but I edited out most of my comments on miHoYo as they are currently showing a willingness to respond to feedback. There are many technical issues with the game that I could go on about, but I’ve already reported those issues to miHoYo directly and they aren’t really relavant to this discussion. I might need to branch off to provide some background information, but I’m going to try to limit this to Genshin Impact on Linux.

This was briefly touched upon in LTT’s video (link)

So… lets get started.

mhyprot2.sys

miHoYo has a custom Anti-Cheat Kernel Driver named mhyprot2.sys. miHoYo has been using this for all of their PC releases to date (Honkai Impact 3rd, Genshin Impact, and probably Honkai: Star Rail). Due to its nature as a platform-specific kernel driver (Windows only as of now), this prevents Genshin Impact from running on WINE.

At the time of release, mhyprot2.sys would always be running on your machine (similar to Riot Games’ Vanguard) without any way of closing it. mhyprot2.sys also had a major bug that allowed for arbritrary code execution at the kernel level. miHoYo has responded by patching the previous bug while also unloading the Anti-Cheat when the game isn’t running.

My personal stance is that mhyprot2.sys doesn’t really make sense for this type of game. miHoYo has released Genshin Impact on the Epic Games Store (a botched release, but a release nonetheless), which opens up the possibility of miHoYo getting access to Epic Games’ Easy Anticheat (EAC).

Security Theater

Security theater is the practice of taking security measures that are intended to provide the feeling of improved security while doing little or nothing to achieve it. - Wikipedia

Oh yeah, there’s one more issue with mhyprot2.sys that I forgot to mention.

It doesn’t work.

I haven’t tested this myself, as I like to stick to the straight and narrow, but I saw a friend demo playing Genshin Impact running on Linux via WINE / Proton with the anti-cheat patched out. It isn’t perfect, but it’s pretty close to native at this point.

I will not be linking to any details nor will I be providing instructions on how to do so, as I believe miHoYo will end up issuing mass bans on Linux users instead of trying to fix the underlying issue.

miHoYo is definitely aware that their approach to security is flawed, but it still functions well as security theater.

They could make their own Linux build, switch to EAC (which has opt-in Proton support), or work with the Valve to get their anti-cheat working with Proton.

Conclusions

I encountered a lot of roadblocks when trying to switch to a Linux-based OS as my daily driver.

I really don’t like whining about things like this. I feel like it’s more productive to try and work towards solutions. So, here are the issues that I’ve encountered on this journey:

• WINE doesn’t implement wintab32 Pen Pressure
• It might be possible to use native Qt5 with WINE
• OpenRaster spec appears to be dead
• Go Live audio is broken in Discord Linux Client
• Genshin Impact doesn’t work via Proton (without removing anti-cheat)

Most of these issues are out of my control. That being said, the best course of action I have is to vote with my wallet.

I will be making donations to Krita (via shop purchase), WINE (via CodeWeavers), and Wikipedia (via the WikiMedia Foundation).

I will be switching from Discord Nitro to Discord Nitro Classic as I don’t feel like paying for features that don’t properly work on Linux. If Discord doesn’t fix the Linux Go Live audio issue before the end of February 2022 (current planned launch date of the Steam Deck), I will be cancelling my subscription completely and will encourage others to do so as well. I will also be cancelling my subscription if Discord makes any annoucement related to Web3 before the Linux Go Live audio issue is fixed.

I will not be giving any such deadlines for Genshin Impact, as I’m not capable of making any impact on their decision making. What I will say is that the release of the Steam Link will probably line up with my jump to Linux on my Personal PC. The Android version of Genshin Impact doesn’t perform very well and doesn’t have controller support as of writing this, so I’m not going to be playing that consistently. If it’s too much of a hassle to play the game, I’ll probably stop playing. Not playing the game reduces the likelyhood of me continuing to support the game monetarily.

If any of the persons / entities mentioned in the article would like to work towards solutions, feel free to reach out.

Note: To miHoYo / Cognosphere, please don’t use Machine Translation if you don’t have anyone who’s proficient in English. I have some friends who know basic Chinese might be able to help me out.