I remember when I was a kid messing with Windows 95/98, I had this intuitive feeling of what was happening under the hood. Just like how you describe your theory. Honestly you’re probably on the right track. In theory on linux you can actually dive into the source code and try to figure out what’s actually happening, but that’s intimidating AF. Hard to say if the problem is between wine and the Direct Rendering Manager (DRM), X11, Wayland, KDE, or the GPU driver…

I had a kind of similar problem with my display not outputting when it was connected. I had to use a DRM file in /sys and udev script to fix it, wrote a blog about it. If your monitors are still messed up after a reboot, it sounds like this won’t help you though.

Also you made me lol to “wine strikes me more as an emulator”. It totes is. The “Wine Is Not an Emulator” name is a joke, the original name was “WINdows Emulator”, which they changed to avoid Microsoft’s lawyers.

That is simultaneously ridiculous and amazing. Blindly clicking the buttons to enable the screen definitely proves you’re getting familiar with the OS.

Why do you think wine/Bricklink messed it up in the first place?

I’ve always geeked out about fan curves and monitoring, though I readily admit for most PCs leaving the default BIOS curve works fine enough.

I just used the free chat with Claude, it created and tracked the files in its own webchat thingy. Being a kernel module, I was happy to manually check, copy/paste, compile, then run the code for each iteration.

Porting postmarketOS to a phone sounds like it may require some amount of manual running and explaining results back to the chat. Ultimately the output only starts to get functional when it hits reality and needs to keep adapting to feedback.

I wrote a blog on the process that more focuses on the journey and technical details of the controller chip.

I used a very similar method in a similar situation to albb0920. They describe it as vibe coding too.

The exact chip that handles everything is undocumented, but similar ones in the same series have datasheets. A maintained version of the linux driver handily collated all of the available datasheets and configurations used by different motherboards. Between that and my microcontroller/hardware experience, that side of things wasn’t too bad.

What I didn’t know anything about was writing an Illumos driver. I used the chatbot with a free claude account, compiling and running the code manually myself. I was impressed that it was able to build out the boilerplate and get something going at all. Course it took a few tried to get something that compiled and worked somewhat correctly. At some points I needed to look through the generated code and point out exactly what what wrong, but at least it would address it.

Code running in the context of the kernel is definitely not something I would have autonomously executing by a LLM. The end result is absolutely not something I would want put into the official Illumos source.

This from the company that started the netbook trend with the $400 eeePC in 2007…

Looks like it has an ARM CPU, a RK3588. Similar ballpark to a Pi 5 in CPU performance.

Installing another OS would be technically possible but not easy, you’d need a Linux kernel with the RK3588 drivers already in it. Then there are differences between it and other RK3588 SBCs that could cause problems.

Much like you wouldn’t want to install anything other than raspbian on a Pi, you’d be best off with ugreen’s OS even if others are technically possible.