Main » Discussion » (Mis)adventures on Debian ((old)stable|testing|aghmyballs) » New reply
    New reply
    Post help

    Presentation

    [b]…[/b] — bold type
    [i]…[/i] — italic
    [u]…[/u] — underlined
    [s]…[/s] — strikethrough
    [code]…[/code] — code block
    [spoiler]…[/spoiler] — spoiler block
    [spoiler=…]…[/spoiler]
    [source]…[/source] — colorcoded block, assuming C#
    [source=…]…[/source] — colorcoded block, specific language[which?]
    [abbr=…]…[/abbr] — abbreviation

    [franpared] [franpaorange] [franpayellow] [franpablue] [franpagreen] - you know what these are.
    [color=…]…[/color] — set text color
    [jest]…[/jest] — you're kidding
    [sarcasm]…[/sarcasm] — you're not kidding

    Links

    [img]http://…[/img] — insert image
    [url]http://…[/url]
    [url=http://…]…[/url]
    >>… — link to post by ID
    [user=##] — link to user's profile by ID

    Quotations

    [quote]…[/quote] — untitled quote
    [quote=…]…[/quote] — "Posted by …"
    [quote="…" id="…"]…[/quote] — ""Post by …" with link by post ID

    Embeds

    [youtube]…[/youtube] — video ID only please
    Thread review
    tomman While the freeze approaches Debian (and I wear my Cirno hat), let's cover another unrelated feature: getting visual novels (and other games) to properly playback videos under Wine/Proton.

    I've been lately tinkering with Proton, since there is no way in hell I'm gonna install Agent Cortana Windows 10/11 (or any later version) on my metal for as long as I'm alive, and I have a moderately sizeable game library I would like to play someday. Proton is not just "Wine and a cut-down Steam for Windows client", it's evidently more than that:

    - DXVK as its default DirectX 9+ implementation (instead of Wine's stock OpenGL implementation), for increased performance at the cost of compatiblity with older GPUs (Haswells need not to apply, for example)
    - A bunch of bundled libraries so it won't even bother using your system libs (beyond Mesa)
    - Per-game prefixes that can be nuked and repaved at will without losing game savedata (as long as the gamedev has explictly opted in into cloud saves and properly told Steam which files to sync/backup!)
    - Per game switchable Wine/Proton versions, including the option of installing 3rd-party builds (the most popular one being GloriousEggroll's proton-ge-custom), so if a game works best with an ancient Wine version, you have the option
    - And of course poorly documented switches, options and workarounds, and next to no error messages because this is 2025, where we Move Fast And Break Disintegrate Things.

    Anyway, a pet peeve of mine and popular pain point on Wine after all these years have been games playing external video files. In the past this involved installing codec packs, media format runtimes, and even large parts of DirectX... and even with all that the experience would be unstable at best. But Wine has greatly improved there, and these days video playback is something that usually works out of the box, thanks to GStreamer. All you need is a clean prefix, and having a more or less complete GStreamer install in your system - for reference, these are the single most important packages in Debian for this use case:
    gstreamer1.0-libav # interface to the ffmpeg-based A/V codecs - you absolutely need this!
    gstreamer1.0-plugins-good # implementations of most popular formats/containers (MKV, MP4, AVI, etc)
    gstreamer1.0-plugins-bad # implementations of some obscure stuff, but also the MPEG-2 containers
    gstreamer1.0-plugins-ugly # implementations of "patent encumbered" crap, including the ASF/WMV demuxer!


    Yes, you need all those even if the package descriptions sound redundant, or your VNs/games will have no videos under Wine. Some games will just skip the videos, others will hang/crash/abort, and depending on the game, your experience will range between "who cares, it was a boring OP movie" to "you mean School Days was supposed to be a interactive anime!?" If you don't buy your games at Steam, you're done, just use Wine from upstream repos, install those relevant GStreamer packages for your distro, and you're set. Don't forget the tissues~

    Now, for those of us where Steam is our prefered marketplace (for better or worse, monopolies are bad but who can argue agaisnst good deals all year around and wide variety of titles?), it means you're forced to use Proton, and that's where things strongly deviate from the intended upstream/downstream way. You will notice that every Proton version (even the custom ones) are self-contained, they ship their own libraries, and notably, they will NOT use your system GStreamer install, but instead they ship their own. And this is where things get icky real fast when dealing with games and playback of media files:

    - All Proton versions ship with GStreamer 1.0 base libs.
    - Valve's stock Proton only ship with a small subset of plugins (basically the -good set, and not even complete, maybe due to patents BS since Valve is a USAian corporation), so if your game use WMVs, you're toast.
    - GE Proton ships with a full set of plugins (-good/-bad/-ugly, plus libav), but for some reason WMV/ASF support is either disabled on Wine itself, or something else is broken, because WMVs will NOT play even with all the pieces being there.

    The result? Broken games forcing workarounds from 10-20 years ago for problems that were already solved upstream long ago! Meet protontricks, a bastard extension to another tool I've always disliked, Winetricks. You will need them BOTH if you want to have a chance to enjoy your purchased games the way they were meant to be played™ (no, not with nGreedia GPUs!).

    Here is example case: Nekopara Vol. 1, a game that due to $RAISINS I ended paying THRICE for: the uncut original release at DLSite, the all-ages release on Steam, and (eventually) the juicy bits (but still censored due to Japanese laws) R18 DLC for Steam:

    How to play the non-Steam version:
    - Install Wine, plus all relevant GStreamer plugins (this game needs plugins-ugly and libav for its WMV videos)
    - Extract the game (it's a self-extracting RAR file)
    - Run the game, enjoy ChocoVani shenanigans for a while, and eventually the OP movie will play.
    (If the game just skips the move with a brief blackscreen, then your GStreamer install is incomplete!)

    How to play the Steam version:
    - Enable Steam Play support for all titles from Steam->Configuration->Compatiblity, restart Steam.
    - Install game, no need to force a specific Proton version.
    - Run the game at least once to let Proton/Wine initialize the game prefix dir, but don't actually play it yet.
    - Make sure to have Protontricks and winetricks properly installed.
    - You will need this script: https://github.com/b-fission/vn_winestuff/ - git clone that somewhere.
    - Run Protontricks, select your game (the game ID for Nekopara Vol.1 is 333600), dismiss a bunch of "can't determine your wineprefix/WOW64 arch" warnings, and when Winetricks actually launches, ensure "Select the default wineprefix" is selected, confirm that, then select "Run a commandline shell (for debugging)". This will fire up your favorite terminal emulator at the prefix dir for your Steam game, configured to run using the Wine version from whatever Proton version is set for that game!
    - Execute the following commands on that terminal:
    # This forces the script to assume that our prefix is indeed for 64-bit Wine since it's on the new WOW64 format.
    # Neglect to do this and the WM11 runtime installer will abort with a Windows version error since it's
    # meant for Windows XP only!
    export WINEARCH="win64"

    # Run the script to install quartz and the WM11 runtimes - it uses bash-isms so don't use anything else but Bash!
    # This will install wmfdist11-64.exe, which covers WOW64 architectures, and temporarily set your prefix Windows
    # version to 64-bit XP to please the installer
    bash /path/to/your/vn_winestuff/codec.sh quartz2 wmp11

    # Restore the Windows version for this prefix, otherwise it will be left at "winxp64" and the game may not run
    winecfg -v win10

    - Close the console, then run your game from the Steam client, enjoy ChocoVani shenanigans for a while, and eventually the OP movie will play.

    Notes:
    - If you check the game entry at ProtonDB, you will notice that people suggest installing WMP11 with protontricks to enable videos. DON'T - Not only it will not work with recent Proton versions (the game will CRASH instead), it will also bring a bunch of irrelevant noise into your prefix (like unneded Windows dependnecies and a full install of WMP11 that is not even needed, we just want the WM format runtimes!), and it will also miss another required dependency (quartz)... hence the need for that alternate install script for those two dependencies.
    - Tested with Proton stable (9.0-4), and with proton-ge-custom (9.24), which were the latest releases available at the moment of writing this.
    - The same instructions will also work with volumes 2, 3 and 4 - just select the proper game on the Protontricks list, then follow the rest of the install steps.
    - If you don't want to waste your time and have decided you can live without the OP/ED movies (you monster! How you can say no to KOTOKO/nao!?), then be aware that on volumes 1, 2 and 4 the engine (Kirikiri) will simply skip the videos when they fail to play. But Volume 3 was done on a completely different engine (CatSystem2), which will HANG instead! In that case, helpfully the engine itself came with an engine configuration dialog which allows to disable videos as a compatiblity option: on the main menubar (minimize and restore the window if you can't see the menus, another Proton glitch), Config->Engine Config, then on tab "Compatibility" check "Don't play movies", confirm and restart the game, otherwise you won't be able to start Chapter 1 as the OP movie is supposed to kick in early.
    - Vol. 0 (unsure about Extra, I've yet to play it) do not have movies, it works as-is out of the box.
    - Vol. 5 After? Bring it on, Shigure! Whenever it ships, I'm Ready™.


    FWIW, most modern VNs with videos these days use WMV, from the Nekopara series to 0verflaw™ Days series, older titles may rely on MPEG video instead. The Recettear OP movie is also a WMV file - in fact, many modern indie/doujin Japanese titles will use WMVs for videos. Life is easier on native Wine, but if you're forced to buy from Steam, you now have a current weapon you can use to deal with this popular issue. Sadly, fixing video playback is not a priority for Valve (or any of the Proton downstream forks), so we have to endure with highly obsolete workarounds :/
    wyatt8740 Hmm, maybe I'll move my Pentium M laptop to OpenBSD sometime, if that's the case. That's such an incredible shame.
    I'd donate a CPU if I had one. My P4 HT is still a 32-bit one.
    I forget what I did for GPU drivers on my Latitude D610 (dell), but I have it working now in Sid. Been a few months since I booted it into anything but XP.

    My systems are currently all using alsa directly, and custom builds of firefox to get the Alsa audio backend. They also are all using FVWM.
    Got a Pentium III in a Gateway E-3200 next to me, but it's just running english Win98 SE and Japanese win2K right now. On a "death star" (75GXP) HDD, no less. I guess now I've waited too long to put Debian on it. :(

    It's possible that debian ports will pick up 32-bit x86, though – it's still possible to run Debian Sid on my PowerBook G4 through it, although the setup was very painful because I had to take an unusual installation route to make the bootloader install (ended up using Yaboot instead of GRUB).
    I'd keep an eye on https://cdimage.debian.org/cdimage/ports/current/ just in case.
    tomman THE END IS HERE... for x86 installs on bare metal on Debian!

    True to its words, you can no longer install Trixie (still on Testing) to 686 boxes, the last ones supported by 32-bit Debian targets. Mind you, they're not killing x86-32 support outright, just removing it from the installer, which also means no new kernels, no new 32-bit installs, etc - you will still be able to run 32-bit programs (hi Steam games!), create and manage 32-bit chroots, and the like. But this is no Windows - 32-bit has its days counted in Linuxworld.

    This is nicely reflected on recent changes from the Debian backports world for those of us still on Bookworm on old 32-bit metal:

    - Last 686 backported kernel is 6.10 (6.10.11+bpo-686-pae in this case). All other platforms are now at 6.11, but there will be no more kernels for 686(-pae). Cherish the moment, or learn to build your own kernels.

    - If you get weird build failures when compiling 3rd-party software and the build errors blame missing files like this:
    /usr/include/linux/errno.h:1:23: fatal error: asm/errno.h: No such file or directory
    #include <asm/errno.h>

    ...that's because you've pulled linux-libc-dev from Backports, which is now a single monolithic package for all platforms. Not only is a waste for those of us that will never build apps for PPC or IBM mainframes, it also comes with a nasty surprise: it no longer has i386 headers! Not sure if this is a bug, or part of the same deprecation (linux-libc-dev is actually built from the kernel packages!), but if you build software for 32-bit x86 this will hit you. Remedy: downgrade (and pin!) linux-libc-dev to the version from Bookworm (6.1.119-1 as of this writing) - those are the old style platform-specific binary packages AND they fully support i386.

    Remember: Bookworm is the final Debian release for 686, but it will be supported until 2027 at least, then there comes LTS, and after that, you can pay for a few more years of ELTS. But we're witnessing the end of a era, the sunset of 32-bit x86 on hardware. it's too late for Pentium Pro/II/III, and for any P4 prior to Socket 775 (unless you can find those magic SL7Q8/QB 478s that cost $WTF because collectors are rich scumbags), the game is also over (but who loves NutBurst anyway?)

    Ironically the number of Debian Powrered™ i386 boxes on this home had a sharp drop in 2024, from 4 to 1:

    - Compaq PIII routerbox (Saki/Patchy): retired in favor of newer metal, paving the way for future gigabit speed boosts from my ISP (It now runs WinMe just like it did the day it left the factory, original license and all!)
    - nx9010: Never really got along with kernels past 3.16 having severe ACPI diarrhea with any newer kernel, rendering it unusable. so I never updated it past Stretch (and even with Stretch, performance is poor). System is now officially retired from active duty.
    - T40: Sometimes it hangs at boot, or outright shutdowns. I suspect a flaky mobo, as the T4x series is infamous for that (haven't managed to reproduce the hang on XP, but it DOES hang and shutdown on 9x rarely). Too bad, as it was running Bookworm relatively fine (barring the sad situation of GPU drivers)
    - Thinkcentre M50: The Final Survivor, The Chosen One, 21 years and counting! Seriously, can anyone donate a SL7Q8/SL7QB? :D
    tomman Undo UI sabotage (mostly from GNOMErs) on your Linux desktop, courtesy of a Phoronix regular:
    https://blog.ssokolow.com/archives/2023/06/17/fixing-applications-which-resist-feeling-platform-native/
    tomman And here we are, one week later Debian DID upgraded to Wireplumber 0.5 (via backports).

    Fortunately this time I was prepared:
    Old format (lives at ~/.config/wireplumber/main.lua.d/):
    rule = {
    matches = {
    {
    { "node.name", "equals", "alsa_output.pci-0000_00_03.0.hdmi-stereo" },
    },
    },
    apply_properties = {
    ["priority.driver"] = 1050,
    ["priority.session"] = 1050,
    },
    }

    table.insert(alsa_monitor.rules,rule)



    New format (lives at ~/.config/wireplumber/wireplumber.conf.d/):
    monitor.alsa.rules = [
    {
    matches = [
    {
    node.name = "alsa_output.pci-0000_00_03.0.hdmi-stereo"
    }
    ]
    actions = {
    update-props = {
    priority.driver = 1050
    priority.session = 1050
    }
    }
    }
    ]


    Syntax changes, keyword changes, properties are defined a bit differently, change for the sake of change, blah.
    Fortunately it worked at the first try, so... crisis averted. For now.

    Dare changing the format again, and I'm wiping this Pipewire shit out of my systems, FOREVER.
    CaptainJistuce If I could change one thing about modern hardware interfaces, it'd be the elimination of HDMI audio. Two cables is NOT too much to ask, and the one-plug solution causes so many more problems than it solves.

    And given how much I bitch about so many modern interfaces... that says a lot.
    tomman HDMI is a horrible standard, part 14345262627326524e10935:

    OK, so I now got clean audio from this display. But the whole thing goes south as soon as my display sleeps (because of fucking course that's how HDMI works - the HDMI Consortium is a bunch of killjoys that never considered "listening to music with a display sleeping but with speakers attached" a valid use casse), falling back onto the onboard Realtek audio just to never come back even after the display wakes up.

    Easy Effects is unable to fix it on its own, since it only applies audio effects and nothing else. The real solution lies within Wireplumber instead. Someone on IRC pointed me to this:
    https://blog.zenlinux.com/2022/08/how-to-configure-audio-device-priorities-in-pipewire-wireplumber/
    All I had was to point my "node.name" to "alsa_output.pci-0000_00_03.0.hdmi-stereo" in my particular setup, reboot the whole thing and... be greeted with screeching audio. Oops, looks like a side effect of this is getting HDMI audio back to actually loud volumes, so let's turn off that autogain filter on Easy Effects :P

    Display sleeps, goes back to the crab chip HDA codec that nobody will listen ever, display wakes up, clean HDMI audio comes back. Oh, and I'll have to rewrite all this the day Debian upgrades to Wireplumber 0.5, because the twats switched from Lua to JSON for their config files and provided absolutely NO way to upgrade your config files, and of course their documentation is typical FOSS fare - terrible. But for now, this problem is effectively solved.

    Did I mentioned HDMI is a shit standard? Because HDMI is a shit standard, and of course DisplayPort had to piggyback on portions of it :/
    tomman I got fed up with the onboard Realsux HDA onboard audio on this Optiplex 9020 USFF, so I decided to try something else: my Aiwa display has an analog audio out, which means it can receive audio over HDMI/DP, feed it to a built-in DAC, and output it on that jack. But there was a little problem: it was too quiet!

    Easy Effects to the rescue! Add some loudness, done.

    ... or not, because I now started to notice out extremely choppy audio over that HDMI output. After researching a bit, the Pipewire docs told me to check some runtime stats via pw-top, where I determined that 1) I was getting a high number of xruns, and 2) they were ALL driver-caused, not application specific. The official workaround for that is to increase the "headroom", which is achieved via modifying some config files on locations and languages that will vary according to your Pipewire setup, distro, session manager (you're all using Wireplumber these days, right?), product versions, and of course phase of the moon and underwear color. (As usual documentation sucks rancid donkey dongs big time, top notch FOSS Kwality®).

    After tweaking a bit headroom (but also buffers and even whatever the hell is "quantum" in Pipewire parlance, all I had found was different stuttering patterns, and a new way to turn my Haswell bento box into a 486DX rustbucket: move your mouse while playing sound and see how xruns shot to the moon, audio stuttering owns the day and it will not recover until you restart the whole chain. WTF. No. Just. NO! And all of this ONLY happened via the HDMI port - the crab chip powered onboard audio was fine - no xruns, no stuttering, no NADA (just subpar quality, but that's Dell tuning for ya). Even tried different kernel versions, from 6.1 (Bookworm's stock kernel) to 6.10 (the latest one via backports) with no difference. It was at this point when I was getting desperate and considering to demote Pipewire from "software done right" to "permabanned from my premises", so instead I decided to refocus my online searches.

    "Pipewire HDMI audio stuttering"

    The second result was enlightening:
    https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3110
    ...which led me to this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025453
    I was not alone after all this time! Misery seeks companion, and oh boy, the solution turned out to be incredibly worthy of its own Darwin Award: append "intel_iommu=on,igfx_off" to your kernel commandline. "But wait dude, what the fuck has to do the IOMMU with HDMI audio stuttering!?" Everything, it seems, because after applying that and rebooting, HDMI audio suddenly was working like a world champion! No stuttering, no choppyness, xruns remain at a big fat solid ZERO, and I could move my mouse without murdering audio performance! What in the holy name of Jesus Fried Christus is happening here!?!?!?


    ...but wait, it gets even better: https://bugzilla.kernel.org/show_bug.cgi?id=86311
    It was ALWAYS Boeing Intel's fault!
    Yep, IOMMU on Haswell CPUs break HDMI audio when enabled, unless you exclude the IGP from it. What. No. I can't even. I officially hate Intel with all of my guts. Also hate HDMI, but that's a tale for another day.

    tl;dr: intel_iommu=on,igfx_off unfucks HDMI audio on Haswell CPUs under Linux.
    tomman Bought a nerd-favorite WLAN card to cure my Realsuck wireless woes on this Dell: an Intel AX210 for $15.

    No, the Inspiron 15 3525 does NOT have a WLAN whitelist, just like 99.99% of every other Dell laptop ever made. Internet claims over Dell pulling a Lenovo over that WLAN slot are bogus at best. Install is simple: remove 8 screws, get your favorite plastic spudger or expired credit card, release a metric boatload of clips, and watch out with those TINY antenna connectors!

    Card works fine for WiFi (latency is still a bit higher than expected), but Bluetooth is day and night: fluid audio, Dolphin picks my Wiimote at the first try, it almost feels like an Atheros or Broadcom! You may want to use the firmware-iwlwifi package from Sid to ensure you're using the latest blobs for these cards that have a patchy reputation of solid drivers but shit firmware.

    Bonus: silence the stupid "failed to load iwl-debug-yoyo.bin" error message on kernel logs:
    # Put this somewhere under /etc/modprobe.d/
    options iwlwifi enable_ini=N

    DON'T! It may work for you, but in my case (and some others I found online), instead it crashes the firmware. Yay Intel.
    UPDATE: Update to kernel 6.9, now shipping on backports - that one no longer complains about that missing Intel Confidential® firmware.
    tomman Routerbox rebuild: partial success!

    The plan was to keep the Compaq (with Saki Mk. 2 brains) as a backup, and promote the PCShits (with the new "Patchy" brains) to showtime. But... PCShits happened: my second M756LMR turned out to be unusually unperformant, even by Hsing Tech standards:

    - Awful PATA speeds (not even UDMA33, even with capable drives and cables - the 630 chipset maxes out at UDMA66, and my broken M756LMR can easily saturate the bus)
    - Weird IRQ behavior - from unnatural IRQ assignments (sure PCShits, I totally want my sound card anywhere BUT at IRQ 5!), to heavy interrupt loads in kernelmode severely nerfing network performance (especially with the built-in SiS 900 port)
    - Speaking about that SiS 900 LAN port... my DSL modem turned out to heavily dislike it, causing frequent connection dropouts. What the hell.
    - Absolutely hopeless at FSB133, so no way to get the top performance from the fastest CPUs for the socket, no matter what RAM you throw at it.
    - Unwanted BIOS settings for the unused and unwired SiS 7018 audio core on the chipset, which can cause severe conflicts with the onboard C-Media audio (again, exclusive from this particular specimen - my other broken mobo has no way to enable this unused feature)
    - Incompatibility with many PCI cards, from old GeForces to many Realsuck 8139/8169 NICs.

    The one saving grace was that these mobos are not picky with solid state drives, but the performance hit and stability issues with some connections were too much to stand. Enter plan B: give up SSDs (for now), and do a brain swap. After some well deserved maintenance, the Compaq is back to routing packets, but with a shiny new Debian 12 setup, capable of maxing out 100Mbit channels even on lowly Realsucks, and even getting somewhere in the way to gigabit. Well, at least good ol' Saki finally earned its well deserved retirement, even if on spirit only.

    Also: now that I cut RAM usage in more than half. I no longer have the need for the unreliable "swap on video RAM", so I got rid of the MX4000 and switched back to the onboard i810E IGP. It's... hopeless on GRUB too, the best it can do is 640x480x16 colors thanks to its lobotomized VESA BIOS. Also no way to tune shared RAM size for video - Compaq hardcodes it at 4MB and that's final.
    tomman After some minimal tuning, ETS2 runs fluid with zero slowdown on this lowly Lucienne IGP.

    No glitches, other than some reduced rendering distance for far-away objects. Trucks look as shiny as the day they left the dealer, and gameplay IS butter-smooth.

    Now I want to close my eyes and pretend I've got a oversized, non-touch Steam Deck :D
    wertigon
    Posted by tomman

    - CPU: Ryzen 7 5700U. I wish AMD had came up with a honest naming system for their Ryzens, just like Intel (where the first 1-2 digits give away the generation of the CPU), because unlike what the "5" on "5700" would suggest a Zen 5, this is actually a rather old Zen 2 SoC! This one is actually a low-end part (it's a "U" with a measly 15W TDP), quite popular on cheap laptops and mini PCs, but that packs quite a lot of punch anyway. Linux Just Works™ with it. mitigations=off or GTFO is the rule in this house, even if the performance gains are hardly measurable these days with all those microcode and BIOS mitigations in place.


    Huh, I thought all 5xxx Ryzens were Zen 3. Shame on AMD then, but whatever. Atleast you have an 8 core. :)

    Posted by tomman

    - Ethernet: *crickets* Thaaaaanks Apple. Had to spend $20 on a USB-C Ethernet dongle, a TP-Link UE300C which is gigabit and Just Works™ (ASIX chipset). USB3 adds 1-2ms of latency to your ping, so don't bother playing competitive online shooters with it.


    Am I the only one that fondly(?) remembers playing Quake on dialup with a 500 ms roundtrip latency? :D
    tomman Debian 12 on the Dell Inspiron 15 3525

    - CPU: Ryzen 7 5700U. I wish AMD had came up with a honest naming system for their Ryzens, just like Intel (where the first 1-2 digits give away the generation of the CPU), because unlike what the "5" on "5700" would suggest a Zen 5, this is actually a rather old Zen 2 SoC! This one is actually a low-end part (it's a "U" with a measly 15W TDP), quite popular on cheap laptops and mini PCs, but that packs quite a lot of punch anyway. Linux Just Works™ with it. mitigations=off or GTFO is the rule in this house, even if the performance gains are hardly measurable these days with all those microcode and BIOS mitigations in place.

    - GPU: "Lucienne". Not bad at all for a IGP - it can even move Euro Truck Simulator 2 at 1080p at playable speeds on pure Mesa! Hardly smooth as butter, but it can deliver SOMETHING at least. Just Works™ out of the box on Debian 12, haven't done many gaming tests yet, but the ETS2 results alone impressed me in a positive way. Sadly the only discrete GPU option on those Dells is goddamned noVideo, eugh! HW video decoding works nicely on mpv and Xine via VAAPI, while VLC exhibits some weird interlacing artifacts via VDPAU. Yay VLC, can't you just become more and more irrelevant on Linux these days?

    - display: non-touch 120Hz 1080p panel (mine comes from LG Display). Nothing special, colors are a bit trashy (especially greens), but then you get what you pay for. Wished this was a OLED, but alas. At least it's matte and non-touch!

    - Storage: Micron 2500 DRAM-less NVMe M.2 SSD. Firmware updates require Windows, sorry. Otherwise, this thing is FAST. I'm surprised at the lack of information that smartmontools can read out from NVMe SSDs, I guess whoever designed SMART for NVMe didn't really cared about SMART being useful. Oh, GSmartControl does not like NVMe SSDs AT ALL!

    - Audio: Realsuck HDA trash. Forgettable. This laptop has one of those cellphone-style combo 3.5mm jacks for headphones and microphone - plugging headphones while playing something may take a couple of seconds before audio switches from the speakers to the headphones. Consider using Easy Effects to improve the jack output, because the built-in speakers are MEH. Remember that Debian still defaults to Pulseaudio instead of Pipewire, so this should be among the first things you fix after setup!

    - Ethernet: *crickets* Thaaaaanks Apple. Had to spend $20 on a USB-C Ethernet dongle, a TP-Link UE300C which is gigabit and Just Works™ (ASIX chipset). USB3 adds 1-2ms of latency to your ping, so don't bother playing competitive online shooters with it.

    - Wireless: Realsuck RTL8821CE 802.11ac + Bluetooth. AWFUL. DOGSHIT. UNUSABLE. RIPOFF. Total and complete waste of silicon and money! All because the Taiwanese crabmen HATE Linux, and their drivers are TERRIIIIBLE. Laggy WLAN which is only fine for casual web browsing (even SSHing over WLAN feels like using DSL from CANTV over wet string!), and Bluetooth is slow for file transfers and UNUSABLE for audio! Do yourself a favor, forget about your warranty, crack open this laptop and rip out that piece of M.2 radio crabmen crime, and put some Atheros love there. Or anything else BUT Realtek (or Intel - their WLAN firmware/drivers can be atrocious at times too). Dell's other option is Mediatek's MT7921/22 802.11ax card, which I just spotted for sale online for $25, and that will be my next move once warranty expires here. Realsuck, your place on my SHITLIST is WELL DESERVED, YOU FUCKERS!

    - Battery: Haven't pushed the pedal to the metal yet, but at least battery doesn't go flat in a couple hours of Steam and web browsers.

    - Camera: Some HD garbage I'll never use since I don't use front-facing cameras on laptops or cellphones - I don't do videoconferences at all! Works, for whatever it's worth (it's /dev/video0 - VLC also lists a /dev/video1 device that is non-operative)

    - USB: 3 x 3.1 USB ports (boo!), one of them being USB-C. They're close to the rear edge of the machine, which means they won't disturb. This is no ASMedia trashy xHCI controller, so they work fine on Linux.

    - SD reader: Genesys SD interface chipset (USB Mass Storage class). Just Works™ - nothing special there (you won't see the device on the kernel until you actually insert a SD card).

    - Power management: Suspend works fine, nothing dies on wakeup so far. Haven't bothered testing hibernation since 1) I don't use it, and 2) I don't even have a swapfile yet!

    - OEM-specific bits: This is a Dell laptop, so i8k/dell-wmm-smi still lets you control the fan. Use i8kfan (from i8kutils) for setting some sensible fan/temperature thresholds. The fan on this thing is hardly silent (it sounds exactly like a jet engine at full blast), but most of the time the laptop will remain fresh enough for it to not kick in. Volume/brightness control keys work. The BIOS on these laptops is bugged regarding the handling of the F-keys: they default to "multimedia", not "function" keys. You can change that on BIOS, and it MAY even work after saving and restarting, but by the next restart the setting will revert to "Multimedia". To put it bluntly: what the fuck Dell!?
    tomman How to make a new Debian-powered routerbox using the lamest possible hardware, 2024 Edition:

    - Hardware-specific config:
    For some reason this M756LMRT didn't required idle=poll to not hang at boot. Set Power Management to ACPI-only on BIOS so the power button works as intended, instead of just suspending the machine (this will also prevent a couple kernel warnings. I went with a /boot partition, just in case. GRUB behaves weird at times on this SiS 630 by starting to a blank or garbled screen - it will boot anyway! (But just in case, don't forget to set a GRUB_GFXMODE on /etc/default/grub - 800x600 seems to be safe, 1024x768 often fails). Gain some precious seconds at boot by slimming down your initramfs (/etc/initramfs-tools/initramfs.conf) - set MODULES=dep to only include the required modules for your box (at the cost of being unable to boot this disk on antyhing but another equally configured system), and pick a less aggressive compression format (Debian nowadays defaults to zstd, which is too heavy for Coppermines - crank it down to gzip which still compresses OK and yet it unpacks MUCH faster).
    Splurged a bit on this thing and bought a PATA DOM, a 30GB "Yansen YS40V2-32" (sold by Amazon as a Kingspec - turns out they farmed their boutique PATA SSDs out to this Yansen subsidiary). Sadly they're DOGSHIT: they're based off a SMI 2236 controller that it's for CF cards, the firmware often comes misconfigured (want a HPA? Best reflash it then with the SMI mass production tools with love from Soviet Russia), many boxes won't recongize them properly including this PCShits AMIBIOS that hangs when detecting it unless you set as a CHS 0/0/0 LBA-only drive! (my Compaq recognizes it just fine, but has a utter and extreme allergy for anything that doesn't have platters, heads, and a legit PATA port). They're overpriced garbage, but they can be made to work anyway, and the latency gains are worth the effort.

    - Kernel preparations:
    Add these magic strings to your sysctl.conf:
    # Enable IPv4 forwarding - you need this for masquerading/NAT to work!
    net.ipv4.ip_forward = 1
    # Some performance tunings for the TCP stack
    net.core.wmem_max = 4194304
    net.core.wmem_default = 131072
    net.core.rmem_max = 4194304
    net.core.rmem_default = 131072
    net.ipv4.tcp_rmem = 4096 131072 4194304
    net.ipv4.tcp_wmem = 4096 131072 4194304
    net.ipv4.tcp_mem = 4096 131072 4194304
    net.core.netdev_max_backlog = 10000


    - Network device preparation:
    Remember to use /etc/systemd/network/10-xxx.link files to setup your persistent device names if you want names that make sense (no, "eno1" or "ens1f1" do not make sense from the point of view of a router!). My fiber ISP uses PPPoE for no good reason at all, which means setting it up in advance on Debian is a pain - pppoeconfig won't just ask questions, it DEMANDS to be connected to the real deal for it to work. And it will shit all around your /etc/network/interfaces with PPP-specific crap, so go and tidy up things afterwards.

    - Network rulesets:
    I used my current nftables ruleset - the magic is literally a oneliner. Don't be me, remember enabling net.ipv4.ip_forward or your routerbox won't... route things!

    - DHCP:
    Install isc-dhcp-server, edit /etc/dhcp/dhcpd.conf to your tastes. I redid mine with a new IP layout for my fleet, and this time I threw everything inside a "subnet X.x.x.x" section.

    - DNS:
    One of the main points of this new setup was to dump BIND, since it's a bloaty pig with my adblocking lists, taking forever to start, and being a pain in the ass to manage in general. My first option was PowerDNS, since it looks to be very flexible and its management tools looked nice... but I quickly hit a brick wall of 32-bit deprecation, as PowerDNS no longer offers i386 packages, and Debian Bookworm followed suit. Ended picking Unbound, which seems to be a popular choice for caching DNS servers, although it's not really meant to be anything else (much less as a real DNS server with zones and junk - you're meant to use its companion for that, NSD), but as usual networking software is meant to be abused anyway. Started with this config as a base, added my LAN zone following this other guide, hard redirects with this, and the gory adblocking bits will be taken care of with yet another script that emits a nicely formatted config file too.
    UPDATE: HOLY SHIT, Unbound is really lean'n'mean! RAM usage was so good that I even decided to backport this config to Saki... going down from 200MB RAM (and heavy swapping!) to ~50MB is absolutely worth the switch! Sayonara Mr. BIND, and rot in hell!

    If Unbound refuses to start with a obscure "error: Error for server-cert-file: /etc/unbound/unbound_server.pem", run unbound-control-setup as root to create those cert files that you will not need anyway.

    - Other random bits:
    Don't forget to install samba, winbind, and libnss-winbind so it can resolve your Windows host names.
    I don't intend to go with a print server this time, so I'm sparing the CUPS setup. I might experiment with a scan server in the future, so I can share my one scanner with the LAN.
    And yes, TEST-NET-3 (203.0.113.0/24) can be used on real networks, despite what the RFC says. I'm going with that one since I wanted private IPs that don't start with a frickin' one!
    tomman Setup Season!

    After burning some hard-earned Benjamins (and getting Knee-Deep In The Red with a certain friendly bank MasterCard), I'm doing not one, but TWO fresh new Debian setups at the ever growing fleet at home:

    - New routerbox! Saki Mk. 2 has served well, but I can't stand Compaq/Intel shenanigans with those moronic RAM limits and its absurd incompatibility with anything that isn't a legit Parallel AT Attachment Rust Spinner, so I picked another PCShits M756LMRT, this one with non-blown capacitors and non-broken video/LAN ports. Sadly the M756 is unstable at FSB133 no matter what magical voodoo you invoke, but at least I can stuff this baby with up to 1GB RAM, and it can accept solid state drives, be it bridged SATA devices or the rare, almost unobtanium Chinese-made PATA SSDs/DOMs. Codename "Patchy" will be routing your porn packets Coming Soon™. Status: still installing stuff, figuring out how to escape BIND hell.

    - FINALLY, a new laptop made in this decade! With doom elections in less than 2 months, a ever threatened budget, and few options to defect Camp Intel/noVideo, my options to get into the Promised Ryzen Land were down to one: a Dell Inspiron 15 3525, powered by a Ryzen 7 5700U. Not exactly a "raw power screamer", but still, far FAR better than what I have now, an aging Sandy Bridge i5 (think on this as a coin with two sides: heads - I'll sell this somewhere down the road and buy something great, when communism falls. Tails - at least I won't be stuck with a Sandy Bridge for the next decade!). Codename "Setsuna" is now the flagship of the fleet... somehow. Status: still installing the universe and a half.

    Will be covering my install notes on upcoming posts, to help random lost souls in the Internet (and my future self) as usual.
    tomman This is what happens when I decide to blow off the dust from my Steam library on my new old shiny box:
    https://steamcommunity.com/app/251990/discussions/0/4336482945457838940/

    Game crashes on PC A, runs fine on PC B, forcing audio driver to ALSA fixes things on PC A, and I've yet to actually sit and play the goddamned game. Yay.
    tomman A pretty good guide (sadly hosted on a Dischorse Discourse board) on how to tune Pipewire + EasyEffects to improve audio quality, even on craptacular Realsuck HDA solutions:
    https://forum.manjaro.org/t/how-to-make-linux-sound-great/146143

    It goes beyond a simple equalizer, and trust me, it DOES improve things a lot... but it requires a lot of steps and some tinkering. Absolutely worth it, albeit not a replacement for a proper soundcard*.

    *TIL Creative still makes soundcards - X-Fi got followed up by Sound Core3D, which is actually an HDA-based solution (!!!), albeit on a proper PCIe card. Oh, and Linux support is finicky, as expected.
    tomman
    Posted by creaothceann
    Posted by tomman
    Uuugh, USB...

    There's not much chance of picking up interference if the 'soundcard' is directly in the ear cup.

    I'm not fan of USB audio more because of latency and CPU overhead concerns, but yeah, point taken (although in my case it's just low audio quality overall, not EMI/RF interference)

    ...either that or spend like €20 $80 on spec-violating adapters and risers to plug one of my SB Live!s to the internal mPCIe slot of this thing :D (assuming drivers would even work behind such a Tower of Power contraption, which is not a given since this is Creative we're talking about!)
    creaothceann
    Posted by tomman
    Uuugh, USB...

    There's not much chance of picking up interference if the 'soundcard' is directly in the ear cup.
    tomman Uuugh, USB...

    What I want is for the glorious return of the soundcard. Somehow, Creative is still in business, selling PCIe Sound Blasters at stupid prices for gamers and "creators" (because the competition died the day C-Media quit making proper sound chipsets that weren't lameass HDA garbo). There is still value on a proper soundcard - not just because of room for a far better analog section, but also because a legit audio DSP frees precious CPU cycles for other useful tasks, instead of relying on halfassed host software solutions for everything (that may not even work at all on your favorite OS!)

    Alas, the market has spoken: $1000+ RTX4090s? Hell yeah! $50 soundcard with decent analogs? TOO EXPENSIVE!!!

    --

    Back to Kuroneko Mk. II, it only took me a few hours to redo my setup, skip some pitfalls, and do some steps I missed on the first, doomed setup. And I finally managed to buy a straight DisplayPort cable, which for some reason are impossible to find in most of Venezuela, requiring a cross-country shipping of one week for ONE $5 CABLE. That worked without issues, as expected from good ol' lame Intel HD Graphics.

    Steam still performs like ass, as usual. But Debian boots in a flash on this thing! - I don't even get time to watch my Plymouth splashscreen before the thing is already at the logon prompt! Maybe we're actually living in the future after all?
      Main » Discussion » (Mis)adventures on Debian ((old)stable|testing|aghmyballs) » New reply
      Yes, it's an ad.