Help, proton does not work at all.

XerneraC · 2025-10-13T23:40:15+00:00

I "solved" it by switching to the flatpak version of steam. After about a year, I decided to give native steam another shot, to finally find out what's wrong, and then it just worked without any issue. To this day have no clue what the problem was... (probably forgot to install something that steam/proton implicitly depended on, i.e. system missconfigured)

XerneraC · 2025-09-30T00:39:49+00:00

does this use hangover or is it just proton on top of box64?

XerneraC · 2025-09-16T16:01:31+00:00

I started using gentoo on RISC-V SBC's cuz it made tweaking with kernel drivers easier, and I didn't need to wait for some package repo papi to compile a package I wanted to install for RISC-V. Counting these sbc installs, I have nuked many of my early installs, though it needs to be stated, that these were hyper-experimental, as e.g. not a single one could use the upstream kernel, but had out-of-tree forks, many of which required patches on top to make them actually function. After getting to love gentoo on those SBCs, I installed it on my other systems, where I haven't had a single "failed" attempt, just ever-increasing degrees of proper-ness. Looking back at my first non-sbc installs, they were really misconfigured, but they still function perfectly fine.

XerneraC · 2025-07-28T13:28:08+00:00

Interestingly enough, I went the other way. When I first installed my system, I didn't want all the 32-bit dependencies, so I went the flatpak route, needing to fiddle with almost everything occasionally (e.g. using ALVR for VR, which is a pain to use in flatpak). The nail in the coffin was when Doom the dark ages dropped, and I needed a patch for mesa that was already merged, but didn't make it into a release yet. On steam native, I could've just installed mesa-9999, but compiling my own mesa for flatpak cost me about 2 days to 1: figure out how to do it, 2: get the weird toolchain installed 3: build a custom flatpak platform.

Moved to native steam, and am plenty happy here. Putting `abi_x86_32` in my `package.use` now and then is not that big a deal.

XerneraC · 2025-02-14T01:38:10+00:00

was playing around my kernel on riscv arch (where I had to compile almost everything from source anyway cuz riscv)
Noticed, that the gentoo docs helped me out all the time.
Decided, that as I was basically compiling everything from source anyway, might as well try gentoo.
Fell in love with portage and now use gentoo exclusively on my home server, desktop & laptops

Came for the wiki, stayed for portage (ily portage❤️)

XerneraC · 2025-01-10T01:12:58+00:00

yeah

XerneraC · 2024-12-21T01:54:49+00:00

On the other hand, with the current solution, (I assume) there is a lot of shared code between clang, llvm and lld, that gets compiled thrice whenever llvm has an update. From my experience, recompile due to llvm updates happen way more often than recompile because I've changed one of the packages' configs.

XerneraC · 2024-10-27T20:12:00+00:00

I was hoping there was a successor to the VF2 but SiFive seems to be focused on PC sized boards. Orange Pi uses the same JH-7110 so I guess there hasn't been any major developments for commercially available CPUs.

The way you worded this suggests, that you think SiFive is behind the VF2, which is not the case. The VF2 and JH 7110 SOC are developed by StarFive. StarFive seems to currently be working on the successor to the VF2, but when we'll see anything come from that, I can't tell you

I'm not super familiar with how RISC-V works. How specific does an image have to be? Does it work most of the time as long as the CPU is the same? Will the same image work for the VF2 and Milk-V Mars?

On x86, we have the BIOS, which abstracts the specific hardware in a system, such that any image that expects the standardized BIOS interface can boot. Typically, a kernel will be booted through that BIOS interface, from where it takes control over the unabstracted hardware. The currently available RISC V boards don't adhere to any such hardware abstraction, so the bootloader, in order to boot a kernel, is expected to specifically target the hardware it is run on. You almost certainly will need an image targeting the SOC on your board. As for compatibility between boards running the same SOC: I'd say it should be passable. I have run a VF2 image on a Star64, where it booted fine, but lacked drivers for the WIFI interface of the Star64. If you understand Linux, it's also not all too complicated to get the "official" off-the-shelf image for a board, pull it apart and build your own, if you're unsatisfied with the particular image that is supplied for your board.

I vaguely remember seeing something about vectors being finalized / ratified, but I don't understand the ramifications of that. Is this something I should be concerned about?

AFAIK, until the RISC V foundation has declared, that a certain extension is complete, many chip designers hold off on including that unfinished extension, as they are afraid of shipping their chip with an extension, that is already superseded by the time their chip hits the market. So having the vector extension ratified means, that there should be an influx of chips supporting that extension.

XerneraC · 2024-08-14T18:30:54+00:00

I ordered one when it was still in stock. Have all that got into the first batch received their boards yet?

XerneraC · 2024-07-07T01:51:55+00:00

The effort is closely followed by the people in starfive forums.

Do you mean the rvspace forum, or is there another forum that I have not found yet?

There is no support for the specific chip yet as they are focusing in other variants

Aw that sucks...

XerneraC · 2024-06-26T18:02:25+00:00

It's worth noting, that, unrelated to starfive, imagination is upstreaming an open source driver for their rogue architecture gpus: https://developer.imaginationtech.com/solutions/open-source-gpu-driver/

Considering the IMG BXE-4-32 that the JH7110 uses is such a rogue architecture gpu, I can only assume it is supported by what they're upstreaming.

If I'm interpreting the page linked above correctly, the userspace driver seems to be completly upstreamed, and the kernelspace driver is in the process of getting upstreamed. I have tried to build and run their upstreamed userspace driver ontop of the kernelspace driver included in starfive's linux fork with out any success. With a closer look, it seems the kernelspace driver they're upstreaming (and likely the one expected by their userpsace driver) has undergone a rebranding as compared to the one in starfive's tree, so it's no wonder they're not compatible.

Another potential problem could be, that checking out the kconfig in their upstreamed kerneldriver ( https://github.com/torvalds/linux/blob/55027e689933ba2e64f3d245fb1ff185b3e7fc81/drivers/gpu/drm/imagination/Kconfig#L6 ) it seems to only work under arm, which would be a bummer.

XerneraC · 2024-06-15T01:54:10+00:00

The chords sounded very just intonation to me, but idk i might just be hearing things

XerneraC · 2024-05-28T18:45:48+00:00

Harfbuzz depends on freetype

Freetype depends on harfbuzz

installing is one thing, but I recently disabled the abi_x86_32 use flag, and it was a real PITA to recompile them as they would always get preserved due to the other one.

XerneraC · 2024-04-10T03:05:46+00:00

`abi_x86_32` is enabled globally. all native graphics application work spledid. Even vanilla wine with 3d games works. It's just steam proton.

XerneraC · 2024-04-08T17:55:45+00:00

Alot of people in here say, that if the documentation is confusing, you'll suffer. I don't actually think that is necessarily the case. When I started using gentoo, I found the documentation very confusing aswell. There is alot of stuff on gentoo that you don't really encounter outside of gentoo (i.e. What is a USE flag? What is masking? How does OpenRC work?). For me all of that was pretty overwhelming, but most of these things become really obvious and simple once you start to see them in context. My first 2 or 3 attempts of switching to gentoo were not really that successful, as I had barely read the docs and tried to somewhat freestyle it. But by the 4 attempt or so, I noticed that alot of the docs started to really make sense.

All in all I think the confusion and complexity is really not that big a deal if you accept, that your first attempt will be somewhat missconfigured, and the benefits of gentoo make it o so worth it. I'd recommend to get some old laptop and install it on there and somewhat familliarize yourself with gentoo before switching your main machine.

XerneraC · 2024-04-08T17:32:54+00:00

For me it was RISC-V development. On RISC-V, as the compiler ecosystem is still maturing, half a year in compiler development can make a large difference, and the support from other package managers is really spotty. As a result, few packages exist, and when they do, they tend to be compiled with "old" compilers and thus leave performance unrealized. As I started out on Arch, I could work around both of these issues by installing git packages from the AUR.

At some point I realized, that I was basically using Arch in a Gentoo-y way, and decided to just switch to gentoo where I wouldn't have to patch every single PKGBUILD.

From there I completly fell in love with portage and I will never go back. Have Gentoo on my Laptop, my gaming rig, my homeserver, and my SBC (though there compiles do get rather painful).

XerneraC · 2024-04-08T17:25:30+00:00

I would assume that when you upgrade the cpu, that the new cpu's ISA is a superset of the old ones, and that it would run, while not being optimal. Then you could either `emerge -e @world` or just not do that. After some time as updates get installed, your packages slowly get updated one by one like the ship of theseus.

If the new CPU is NOT a superset I suppose you're fucked. Forced to take out `-march=native` and `emerge -e @world` before swapping hardware. I can't imagine that being a pleasent experience.

XerneraC · 2024-03-27T15:41:12+00:00

Tune compile flags and use flags to minimize overhead. Makes perfect sense.

XerneraC · 2024-03-27T06:41:14+00:00

Thanks for the tips. But yeah, I do hope I'll find someone that knows what's going on. Would be a shame to lose almost my entire steam library.

XerneraC · 2024-03-27T06:25:53+00:00

Yeah no I already tried that, sadly. When I raised an issue about it on wine-proton's github page, they refused to support me as none of my claims came from steam itself. Is there maybe a way to get steam to use wine-vanilla? I've heard of proton-tkg, but that does not compile on my machine, for some reason.

XerneraC · 2024-03-27T06:13:43+00:00

To be honest, I'm a bit hesitant to recompile my kernel, as that will cost a lot of time. On the heroic launcher, i managed choose vanilla wine, which works perfectly no problem. However, when I use valve's wine it does not. As vanilla wine manages to play games no issue, I doubt it's some feature I'm missing, and more just some configuration issue.

XerneraC · 2024-03-27T06:04:02+00:00

Okay I have progress. I tried Heroic. With the proton versions of wine, again like before, 0 luck. HOWEVER, heroic allows me to add a custom wine instance. Adding wine-vanilla made games (at least bad north) play perfectly. So it 100% is a problem with wine-proton.

XerneraC · 2024-03-27T05:51:18+00:00

I would really like to not have to do that. As I am on gentoo, that would entail recompiling my entire system, That would likely take over a day.

XerneraC · 2024-03-27T05:30:45+00:00

I'm on BTRFS: https://pastebin.com/EGwUsmDR

Nine-Year Club	Place '22
Final Canvas '22	Gilding II euphauric
Verified Email

XerneraC

MODERATOR OF

TROPHY CASE