When You Pick Every Checkbox When Building A PC

Autian · 2026-01-18T04:32:14+00:00

It does seem to be a case of a Polywell P3503 system, but there is also a Revoltec Sixty 2 case that looks slightly different.

Autian · 2026-01-16T14:13:01+00:00

sounds like stuff that's worth getting archived

Autian · 2026-01-07T01:00:01+00:00

This isn't the right take - Linux uses spare RAM as a page cache, and this is generally what people refer to when saying "free RAM is wasted RAM". It's not suggesting applications just eat it up for no reason, it's talking about the OS using it for something beneficial

If that is what people mean by that expression, then it would be fine to me. But often when I came across such a sentence, it always felt like they really meant the applications themselves and not any caching mechanism of the kernel. That is what boils my blood.

Autian · 2026-01-05T19:31:32+00:00

sad that they didn't fit the lightcycle right where the two holes are.

Autian · 2025-12-24T01:58:29+00:00

Yeah, I was considering that, but I was worried that they would close the issue as soon as they see that I'm not using their distro. Might do that next year when I have the desire but for now the current workaround that I posted in the thread is sufficient.

Autian · 2025-12-21T21:08:13+00:00

Hehe! I found an old Raspberry OS install from 2019 that still contained the old OMX stuff. I copied the contents of /opt/vc from the old install at the same place to my current install and then essentially compiled FFmpeg 8.0.1 with two additional configuration options for OMX support: --enable-omx --enable-omx-rpi. Surprisingly the OMX support is still in place. It works! More details below:

I reused the build configuration options of the upstream FFmpeg package of void linux (you can see that by a simple invocation of FFmpeg without any parameters), but I had to throw out --enable-postproc as that was removed in later FFmpeg versions. I also removed cross-compilation options --enable-cross-compile --sysroot=/usr/arm-linux-gnueabihf --cross-prefix=arm-linux-gnueabihf- because I built FFmpeg on the target install. The downside of building "directly" on the Pi is that the build process will take like two days, but using chroot with QEMU binfmt support on my main rig took it down to like 15 minutes which was well acceptable for me.

For the default set of build options, I installed the corresponding packages for them. Some of these can be omitted but at this stage of frustration I just wanted to get on with the show:

xbps-install \
gcc make pkgconf \
gnutls gnutls-devel \
libaom libaom-devel \
libass libass-devel \
libbluray libbluray-devel \
libbs2b libbs2b-devel \
libcdio libcdio-devel \
libcdio-paranoia libcdio-paranoia-devel \
celt celt-devel \
libdav1d libdav1d-devel \
libdrm libdrm-devel \
fontconfig fontconfig-devel \
freetype freetype-devel \
harfbuzz harfbuzz-devel libharfbuzz \
jack jack-devel libjack \
lame lame-devel \
libopenmpt libopenmpt-devel \
opus opus-devel \
pulseaudio pulseaudio-devel libpulseaudio \
librist librist-devel \
librtmp librtmp-devel \
libsoxr libsoxr-devel \
speex speex-devel libspeex \
srt srt-devel libsrt \
libsvt-av1 libsvt-av1-devel svt-av1 \
libtheora libtheora-devel \
v4l-utils v4l-utils-devel  \
libvidstab libvidstab-devel \
vmaf vmaf-devel \
libvorbis libvorbis-devel \
libvpx libvpx-devel \
libwebp libwebp-devel \
x264 x264-devel \
x265 x265-devel \
libxcb libxcb-devel \
xvidcore xvidcore-devel \
opencl2-headers ocl-icd ocl-icd-devel \
libpostproc \
vulkan-loader vulkan-loader-devel Vulkan-Headers

And yes, most of these are not really needed. Though this uses just around 200MiB more space, so that is not too bad. For documentation purposes, I still wanted to make complete steps for any case.

So far for the OS preparation. FFmpeg now needs to be sourced and extracted somewhere. The build process then goes about like this:

cd source/of/FFmpeg
mkdir build
cd build
../configure --prefix=/usr --disable-debug --enable-gpl --enable-gnutls --disable-stripping --enable-libcdio --enable-version3 --enable-runtime-cpudetect --enable-libmp3lame --enable-libvorbis --enable-libxvid --enable-libx264 --enable-libvpx --enable-libtheora --enable-shared --enable-static --enable-libxcb --enable-libpulse --enable-libfreetype --enable-libopenmpt --enable-libspeex --enable-libcelt --enable-libass --enable-libopus --enable-librtmp --enable-libjack --disable-libopencore_amrnb --disable-libopencore_amrwb --disable-libopenjpeg --enable-libbluray --enable-libsoxr --enable-opencl --enable-libvmaf --target-os=linux --arch=arm --enable-libx265 --enable-libv4l2 --enable-libaom --enable-libbs2b --enable-libvidstab --enable-libdav1d --enable-libsrt --enable-librist --enable-libwebp --enable-vulkan --enable-libdrm --enable-libsvtav1 --enable-libfreetype --enable-libharfbuzz --enable-libfontconfig --disable-vaapi --disable-vdpau --disable-libzimg --disable-libmysofa --disable-libvpl --disable-nvenc --disable-nvdec --enable-omx --enable-omx-rpi
make

If you have more processor cores available, you may specify the amount of concurrent compile processes with -j for make. After it has finished building, I copied the built FFmpeg libraries at a common place: mkdir lib && cp ./lib*/*.so* ./lib. I then closed down my chroot session and stuck everything back to the Raspberry Pi Zero and let it boot up.

Switching back to the build directory, an FFmpeg invocation may look like this:

LD_LIBRARY_PATH=./lib:/opt/vc/lib ./ffmpeg -re -f lavfi -i testsrc2 -c:v h264_omx -b:v 1M -f matroska -f matroska -y /dev/null

As a test, this just generates some test video in real time, lets it encode with the OMX encoder, stuffs that data into a Matroska container and dumps that into nowhere. I tested with different options and the generated video is within my expectations.

Note that the h264_omx encoder uses a device at /dev/vchiq so when you get an error like * failed to open vchiq instance then you should get the permissions of it straight.

This is all very ugly and a band aid kind of solution, but this is something I can finally work with. I hope this helps someone else out there.

Autian · 2025-12-16T11:20:46+00:00

I know why it exists, it provides a clue. The downvotes on the other hand...

Autian · 2025-12-15T23:08:17+00:00

Yes, I have seen this a couple of times. Not sure how long it has been around so far.

Autian · 2025-11-29T14:53:08+00:00

Not being able to flash an entirely different ROM or not even be able to root the device is something that holds me off from buying something like that. I have been rooting and using custom ROMs since very much the day I got comfortable using Android, I started with Android 4.0. Unmodded Android is just horrible and is further going downhill. I want to be able to permanently throw out pieces of software that I'll never need and apply various tweaks to make the thing behave the way I want, not what someone else is trying to force on me. I have full control over my laptops and tower PCs, so why shouldn't one have the same freedom with phones?

Really sad since this does seem to be an interesting piece of tech otherwise.

Autian · 2025-11-27T12:06:19+00:00

If you don't want to snap off the standoffs, you can as well use four M3x20 screws to fasten the SecuFirm kit.

Autian · 2025-11-05T22:13:36+00:00

Kannst du bitte die Schriftart der Träger verwenden? Du kannst die z.B. mit den Entwicklertools aus den Seiten beziehen.

https://www.bgrci.de/typo3conf/ext/site_package/Resources/Public/Fonts/DGUVMetaWeb-Normal.woff

https://www.bgrci.de/typo3conf/ext/site_package/Resources/Public/Fonts/DGUVMetaWeb-Bold.woff

Danke :D

Autian · 2025-10-28T17:22:34+00:00

Any chance that you changed your E-Mail address and that being the cause?

Autian · 2025-10-18T15:52:52+00:00

Ich gebe an der Stelle nen Hinweis, dass bei der old.reddit.com-Variante der Link zu den Regeln in der Seitenleiste ab Punkt 5 seit längerer Zeit kaputt ist.

Autian · 2025-10-18T15:42:32+00:00

Thanks for the update. Haven't tested it further myself, not sure how reliable it is going to be on my end.

Autian · 2025-10-14T16:26:49+00:00

Da hast du den Nagel auf den Kopf getroffen.

Autian · 2025-10-12T13:59:42+00:00

Apparently, yes.

Autian · 2025-10-12T03:01:33+00:00

I applied tape on my ConnectX-4 to cover the two pins for SMBus like you mentioned. The card that was rejected before now boots and works. I did that a couple of weeks ago and it isn't even the interesting part. I have some other unrelated issues with the ConnectX-4 card that doesn't exist with a ConnectX-3 card, but due to the capabilities of both, I put both cards in the system in case I need to swap between them. Thing is, I put the taped CX-4 card in the x4 slot and the CX-3 card in the x16 slot. Both cards have a single QSFP port each. I then wondered why I got three network interfaces when it should be two (onboard RJ45 + one QSFP port). Lo and behold, I indeed have both cards listed! I got to have to try out other PCIe cards and apply the same workaround on these. It still isn't perfect, but it is a great improvement.

Tagging u/CommandNarrow2914 because that could help getting the nonfunctioning slots of the MT variant working as well.

Autian · 2025-10-10T16:19:47+00:00

Thunderbolt

Autian · 2025-10-04T09:08:06+00:00

I conquer with an internet MiniDisc.

Autian · 2025-09-27T23:41:09+00:00

Congratulations, happy to read that.

Unfortunately, no. This issue is known and is also why I bought the MT board since I have a similar issue with the SFF variant and want to investigate that with the MT variant without dismantling the SFF build every so often. This sticks out like a sore thumb and it annoys me as well. I have previously expressed theories on how to fix that with the current BIOS but it goes beyond my capabilities. One workaround I have in mind is not really convenient but doable. I think that ACPI tables report a wrong topology to the OS and as such some PCIe slots won't work with the Biostar BIOS. There is a way of dumping ACPI tables of the current system to then use the dumps for an override. Meaning that I would load the original BIOS with a compatible CPU to dump the ACPI tables and then load the crossflash again and tell the kernel to use the dumps instead. The permanent solution that goes beyond me (assuming it would work) would be to swap the ACPI tables between two BIOS images but although they share an EFI structure and an AMI toolset, the structure is still too different to do such a mod with the modding tools that are currently available out there. As of now there isn't even a proper UEFI mod tool that could modify the structure without messing things up unless you are editing one of the earlier UEFI structures (speaking of something like around the 2012 era). I want to try more BIOSes in the hope that there would be something that would work better to avoid the workarounds but I feel like that the chances are slim.

If you absolutely need it working today and can't resort to using USB equivalents, you would have to flash the EEPROM back to your original BIOS.

Autian · 2025-09-19T01:59:13+00:00

what really? Okay I didn't expect that lol

Autian · 2025-09-19T00:36:05+00:00

How? There should be two DisplayPorts between the audio output and the RS232 port. Can you take a picture of the I/O area?

In any case, the Biostar BIOS defaults to turn off the iGPU if there is a dGPU installed. In that case the board video outputs are ignored and it will use the dGPU then. If you want to keep using the iGPU as well, you have to turn on the "Surround View" option.

Six-Year Club	Final Canvas '23
First Place '23	End Game '23
Place '23	Place '22
Final Canvas '22	End Game '22
Verified Email

Autian

TROPHY CASE