0 users browsing Discussion. | 3 guests | 12 bots
| wertigon |
Posted on 23-04-04, 19:50 (revision 1)
|
|
Post: #196 of 205
Since: 11-24-18 Last post: 157 days Last view: 28 days |
Posted by CaptainJistuce Ah, right. Let me check the options: 1. Steam Deck [1] + Dock [2] - $399 + $89 2. No-name 3rd gen AMD laptop [3] - $369 3. Modern PC parts [4] - $315 Doesn't seem too far-fetched to purchase; for 6 people that's just $50-$75 each. Then again I could just be a spoiled euro tech-junkie having built my ivor^H silicon tower waaaaaaay too high. Also, how to deliver this to a commie will be a problem in the US. :shrug: If it helps I am planning on going AM5 eventually and am currently running a B450 system with a 512 GB SSD; happy to donate that, but it will take at least a year. [1] https://store.steampowered.com/steamdeck [2] https://store.steampowered.com/steamdeckdock [3] https://www.amazon.com/dp/B0BVLV3X6G/ [4] https://pcpartpicker.com/list/KTtCd9 |
| tomman |
Posted on 23-04-19, 03:43
|
|
Dinosaur
 Post: #1226 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
If kernel 6.1 breaks backlight control on your jurassic laptop, send your death threats to this dude. Or not - he WARNED us and we chose to gleefully ignore him. My Inspiron 6400 now needs acpi_backlight=vendor to restore backlight to it's usually semi-broken (but still controllable) status, but your laptop might be Different™. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-04-19, 06:22 (revision 1)
|
|
Dinosaur
Post: #1227 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
And now, for the Stupid Experiment Of The Day: crosscompile Super Mario 64 on a Debian box for Win9x retroboxes! Nintendo will unleash their dogs over anyone that dares distributing a binary built from the decompiled SM64 sources, so you're on your own. And the build instructions out there for Windows targets assume that you're 1) building ON Windows (yuck!), and 2) targeting "Windows 7 or later" (ha ha). Crosscompilation guides also suck because they assume (wrongly!) that you're using Arch (!!!), so they're of no use for this case. While there have been people reporting success on building Win9x-compatible binaries, noone will tell you exactly the full gory details to do it yourself at home. Since I'm - I'll pick the recommended fork for PCs these days, which is sm64ex. I'll also assume you can already build that for your Debian host - otherwise review the Linux build instructions first. Don't forget to place a vanilla SM64 .z64 ROM under baserom.us.z64 (or whatever region you want to use!) - Install the mingw-w64 package. It will require ~1GB of disk space and will net you Win32 and Win64 crosscompilers. You'll also need zstd because we need a few dependencies from MSYS2, and they're now using this hipster - Download these dependencies from MSYS2: mingw-w64-i686-SDL mingw-w64-i686-libiconv mingw-w64-i686-glew You'll end with some weird .zst files, which you will be able to extract with a straight tar -xvf if you've already installed zstd. Extract all three to a known place - you should end with a single /mingw32/ directory. Take note of that location! - Edit /PATH/TO/mingw32/bin/sdl-config to fix some things, otherwise our compile will bomb out: Change line 3 (prefix definition) to: ...and line 45 (--CFLAGS include path) to: - Build! Use this commandline (fix your paths accordingly): make TARGET_ARCH=pentium TARGET_BITS=32 RENDER_API=GL_LEGACY WINDOW_API=SDL1 AUDIO_API=SDL1 CONTROLLER_API=SDL1 WINDOWS_BUILD=1 CROSS=i686-w64-mingw32- CC=i686-w64-mingw32-gcc CXX=i686-w64-mingw32-g++ SDLCONFIG=/PATH/TO/mingw32/bin/sdl-config -j4 You want a Win32 binary using SDL1 and legacy OpenGL 1.x renderer, and this commandline will eventually generate one for you. - If you've followed these instructions correctly, you'll end with an executable under build/sm64.us.f3dex2e.exe. This will run... on Windows XP, but not 9x yet! The reason is that the libSDL static libraries from MSYS2 rely on a couple MSVCRT functions that do not exist on Win9x' msvcrt.dll (and no, you can't replace that lib or cheat by placing a newer one under the same directory as the executable! Fortunately the fix is simple - just bring your favorite hexeditor and do the following edits: * Replace _strtoi64 (hint 02B2) to strtol (hint 02C8) * Replace _strtoui64 (hint 02B5) to strtoul (hint 02C9) Be careful: the leading underscore is part of the original function name. Zero out the extra characters, and don't forget to fix the hint numbers too (they're BYTESWAPPED!). If you didn't screwed this, your binary will now run under Win9x! - Wait for the Nintendo Ninjas to knock at your door. I recommend a shotgun. And yes, those are the horrendous SiS 630 OpenGL drivers wrecking yet another fine game (poor Peach has some severe herpes there! Shadows are BROKEN!). Performance is barely better than the ancient emulators I used on that thing 20 years ago, but hopefully your retrobox doesn't suck as much as mine :P Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| wertigon |
Posted on 23-04-21, 19:56
|
|
Post: #197 of 205
Since: 11-24-18 Last post: 157 days Last view: 28 days |
Man, you have way too much patience for that. Me, I have painstakingly learned the bitbake build system and have mounted a RPi4 to the TV. This means I can update my entire retro system for ARM, tweaked just the way I like it. This also means I can run install-less game "cartridges" (actually SD cards) on my RPi4. Cross compiling is just something I eat to lunch, dinner *and* breakfast now. Start a build and a couple of hours later I have the latest and greatest for most console emulators... As long as I have the source code to make it work of course. It is strangely satisfying to have a dedicated Linux system that loads a dedicated game every time you replace the SD card. Only problem is that it takes a bit of time to load the Linux system first. It does feel a bit wasteful to load a 200 MB image to play a NES ROM, and you *could* probably cut that down if you want to... But when 1GB SD cards costs around 50 cents, why bother? Yeah, I know I can simply reload the emulator instead, but what is the fun in that :) |
| CaptainJistuce |
Posted on 23-04-23, 01:45
|
|
Custom title here
 Post: #1125 of 1164 Since: 10-30-18 Last post: 65 days Last view: 1 day |
Posted by wertigonNice! Now if only there was a collection of "bare metal" Pi emulators for the project. --- In UTF-16, where available. --- |
| tomman |
Posted on 23-04-25, 19:43
|
|
Dinosaur
Post: #1229 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
PSA: Thanks to braindamage of both FFmpeg and VLC, the latter will ship with non-working VAAPI hardware acceleration on the next Debian stable release (Bookworm): https://code.videolan.org/videolan/vlc/-/issues/26772 https://code.videolan.org/videolan/vlc/-/merge_requests/1245 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021601 Here is the problem in detail: - VLC depends on FFmpeg, just like every other media player in FOSSland these days - VLC relies on FFmpeg for hardware decoding, including its VA-API interface. - FFmpeg will never learn the advantages of having a stable API/ABI (just like most FOSS) because those are for wimps, and did major changes for its 5.0 release sometime last year, including its handling of hwdec APIs. - Said API changes required major reworks on downstream projects with regards of VA-API support, which mean everybody had to update their players, AGAIN. - While most players eventually picked up the pieces and moved on, VLC devs chose a different path: their upcoming 4.0 release which has been delayed for at least 2 years, and which has no release date yet. - VLC also announced they're not fixing VA-API support on the current stable branch (3.0.x) since the required changes are far from trivial, leaving distro maintainers in a rather rough spot: either keep dragging multiple FFmpeg releases, figure out how to fix VA-API support on VLC, package and distribute a new major VLC version not fit for public consumption yet, or drop VLC completely. - While VLC devs assumed most distros would pick the easy way out (multiple libavcodec versions), the Debian maintainers aren't eating this bait after having been burned in the past, so they had no option but to adopt the VA-API-less patch and pray that noone notices. To be fair here, I can't blame Debian - they're distributors, not developers, they didn't got a word on this and we users get the short end of the stick, as usual. Now with the Bookworm release real close (we're now in Maybe fansubs were right all those years and either VLC was junk, or hardware decoding is for sissies :/ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kawaoneechan |
Posted on 23-04-25, 22:12
|
|
FMOD user
 Post: #587 of 599 Since: 10-29-18 Last post: 197 days Last view: 8 hours |
Posted by tommanAs a fansub enjoyer, I feel like I missed something here. |
| tomman |
Posted on 23-04-28, 01:23 (revision 1)
|
|
Dinosaur
Post: #1230 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
https://lists.debian.org/debian-devel-announce/2023/04/msg00007.html Ladies, gentlemen, and FILE_NOT_FOUNDs of the boards, save the date: Bookworm is going Time to define the update strategy for the fleet: - T40: Already done! Picked my least used setup for a trial - went without a hitch, except for a minor catch which I'll detail later. - Thinkcentre: Next on the firing order, maybe I'll do that one before launch date too. - I6400: Will also get upgraded around release date. - Asus: Most likely by early 2024 for now, I'm not messing right now with my daily driver. - Saki Mark II: yeeeeeeeeesh, not yet. "2024" until further notice. Since I have to update many setups at home, I have two options to minimize the download impact on both Debian servers and especially my pathetically slow 3Mbit DSL which will go with me to the grave, it seems: either setup a local mirror (looks unfeasible since I can't find a ballpark feature for a SINGLE arch "all+i386+amd64" disk usage, and I'm not cloning 2TB for a entire Debian mirror!), or an "apt cache" (I've been suggested to use apt-cacher-ng, which is a on-demand cache setup) Ah, the first gotcha on the Bullseye->Bookworm upgrade: GRUB_DISABLE_OS_PROBER now defaults to true for "sekuritah" reasons, which means you'll lose the $OTHER_OS boot entries on your GRUB menu! Edit /etc/default/grub, add "GRUB_DISABLE_OS_PROBER=false" somewhere, save, rerun update-grub, done. Posted by Kawa Over 10 years ago, fansubs used to HATE VLC due to its subpar support for their ridiculously overengineered .ASS styled subtitles (mainly stupid overkill karaoke animations that would bring down a fast Pentium 4 playing SD video down to its knees). There was even one incident of a specifically crafted .ASS subtitle track that would crash VLC (which turned out to be a security flaw!). Instead large parts of the scene insisted in their carefully crafted codec packs for Windows (remember CCCP?), and those on other non-Windows platforms could go pound sand (mpv was in its infancy). They also derided anyone using mobile devices ("plastic toys"), and even when hardware decoding became commonplace on PCs, many actively avoided them (guess why you can't play most modern anime encodes on anything but software decoders AND some very niche devices? Look for the Hi10P drama, one of the many reasons I quit downloading anime) VLC support for styled subs would vastly improve since they switched to libass, and these days nobody cares, but I still remember when fansubs would kick your ass on IRC if you dared mentioning cursed words like VLC... or VirtualDubMod :P Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| CaptainJistuce |
Posted on 23-04-28, 04:27
|
|
Custom title here
Post: #1126 of 1164 Since: 10-30-18 Last post: 65 days Last view: 1 day |
Ah yeah... I remember those days. They also had strong opinions about last year's hardware.("Upgrade from a toaster.") --- In UTF-16, where available. --- |
| tomman |
Posted on 23-05-14, 14:15 (revision 2)
|
|
Dinosaur
Post: #1236 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
Asahi Linux (actually marcan) To Users: Please Stop Using X.Org Gotta love the smell of clickbait and flamebait in the morning~ But we can't expect better from a former console hacker/drama queen from Spain. I'll try to keep this polite, so I'm going to say this: MY computer, MY rules. No software developer decides what I should use and what I shouldn't, no matter the hardware. Please stop "pushing" my desktop "forward", THANKS. NOONE ASKED YOU FOR THAT. From now on, I hereby decree that Wayland is PERMABANNED in THIS house. If Debian ever caves to the Wayland "forward thinkers", that's the day I'm staying with the last Xorg-enabled version until it dies of bitrot, THEN I'm quitting computers for good. Hector Martin, welcome to my select list of Assholeware™ developers, just next to Moonchild, Tobin, and Jamie W. Zawinski. I'll be avoiding any project you're actively involved on from now onwards. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| wertigon |
Posted on 23-05-29, 11:15
|
|
Post: #200 of 205
Since: 11-24-18 Last post: 157 days Last view: 28 days |
Posted by tomman Anyone tying themselves to the Xorg ship mast is doomed to go under sooner, rather than later. Xorg is based on heaps upon piles upon mounds of hacks to get it running on a modern architecture. As soon as Xorg is off the table, you can optimize new drivers to be like one third the size in the active codepath. Xorg support will still remain for a long while as a backwards compatibility option, but I think direct kernel support acceleration could go away as early as 2026 or so. Of course, that means the 2026 LTS kernel will no longer accelerate Xorg on hardware, not that it is completely unbootable. Xorg as it stands is already a rudderless ship on life support, and is rapidly moving towards legacy status, where it will linger until deemed obsolete. Now, one does not simply delete Xorg, far too many hooks for that. But the work to remove all hooks is more or less completed, so now we can start extracting big chunks of Xorg to Wayland. Are there some vital protocols left, yes, but those are edge cases for the most part. Things like HDR and stuff like that. Old tech, Wayland should handle pretty well now. |
| tomman |
Posted on 23-05-29, 20:48
|
|
Dinosaur
Post: #1238 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
Look, I'm not against new tech - I'm NOT that much of a luddite (yet!) I'm against new halfassed tech designed by committee, where you're replacing a pile of hacks for a bunch new shiny code with many shortfalls that aren't a 1:1 replacement for most use cases, and where anyone presenting a sensible complaint gets promptly dismissed because You Don't Fit The Vision™. For me, Wayland IS my systemd moment. If I'm "going under" with Xorg, so be it. But then that day is far away, considering that Win32 is still a thing :P Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-06-10, 17:09 (revision 1)
|
|
Dinosaur
Post: #1239 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
Today is Bookworm's Release Day~! GO. --- Just upgraded Ye Olde IBM TV Box: another traumatic upgrade experience because the Radeon HD2600 is starting to show signs of the RoHS pox (or simply wants to die), as the machine hung early in the install phase, then after a reboot the display went corrupted... and hung again. After removing the case, poking it at the stupid AGP card, and trying a couple times ago, I'm gladly surprised of the battle-tested, highly resilient Debian package managers - here is how you recover from a botched upgrade (flaky hardware, blackouts, etc) without having to pull the nuclear option: - If the machine boots, that's good! Try booting to recovery mode (Advanced Options -> select any kernel that says "Recovery"), then give your root password and move on from there. - Try rerunning apt-get dist-upgrade. It will figure out that the last run was interrupted and will tell you what command to execute, which will be either dpkg --configure -a, or apt --fix-broken install - You may need to repeat that a few times until you're able to do a clean dist-upgrade, then reboot~! Some side effects: I lost all of my locales (except for en_US.ISO-8859-1), so I had to run dpkg-reconfigure locales before the first reboot to clean up that. Also had to do the GRUB_DISABLE_OS_PROBER=false so I don't lose the Windows boot entry (remember: dualbooters now have to do that because $RAISINS) As for the loss of VAAPI hwdec on VLC, there is a workaround: VLC still supports VDPAU, and there is a VDPAU-to-VAAPI bridge available on the repos: libvdpau-va-gl1. Install that, setup VLC to use "VDPAU output" as video output, done. Or use something else not made by braindamaged Frenchies, I guess... 2/5 done~ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-06-13, 03:24
|
|
Dinosaur
Post: #1240 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
Bookworm launched... without the noVideo blob for some "legacy" GPUs, namely my Fermi 610M: https://tracker.debian.org/pkg/nvidia-graphics-drivers-legacy-390xx https://bugs.debian.org/1006719 https://bugs.debian.org/1033776 Remember, the 390-series blob went EOL last December, and that was reason more than enough to not ship it with the latest Debian stable. Even worse, a bunch of CVEs were disclosed recently affecting a large number of nVidia's blob... including already EOL'd versions, so it doesn't make any sense to ship obsolete, broken, and potentially insecure software with a stable distro. This also means for those of us stuck forever on Tesla/Fermi GPUs that we no longer have the right of having good, stable drivers with great performance for our metal. All that it's left is Nouveau and the big punch to the liver that comes to it with regards of its (lack of) performance because they never could get reclocking properly implemented for those GPUs, and I can't really blame them since, unlike Asahi Linux, noone is throwing money at them to support the ever-growing numbers of nVidia GPUs on Linux boxes (after all, "the blob works fine for the 99%"... until it no longer supports your card, but by then you're due for a new computer, right? RIGHT?!). The 390 branch is still available from Sid, and it should work for now (assuming you figure out which packages to install), but it won't work for much longer, so maybe it's time for me to just write off this useless extra GPU for which I paid good money 11 years ago :/ Or, if I'm masochist enough, risk frying this laptop for good with scripts like this: https://github.com/ventureoo/nouveau-reclocking (On the flip side, I would gain proper PRIME offload, something that noVideo refused to give us many years ago) Remember kids:  Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-06-18, 17:37
|
|
Dinosaur
Post: #1242 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
Yay, I've got... bad RAM~! Recently SeaMonkey started crashing at random - sometimes as frequent as 3 times in one hour! Initially we thought it could have been some bad patch or something, until someone at #seamonkey suggested testing my RAM. And of course, memtest86+ found some bad RAM: a dead bit somewhere in the upper ~4GB space seemed to be the possible source of this mayhem (I have 2x4GB DDR3-1333 modules on this Asus, which is apparently the max RAM I can install despite the i5-2450M supporting up to 16GB DDR3 RAM). Since the fault was found in a rainy weekend, in a city where the few remaining computer stores are poorly stocked and overpriced to hell and back, that means enforcing a workaround until I can get RAM replacements sorted out. Fortunately there are ways to tell Linux to stay the hell away from bad RAM: - Good ol' BadRAM patches: memtest86 can even generate the badram= patterns for you, but unfortunately those patches were optional and never merged upstream (AFAIK). I'm pretty much sure Debian doesn't even ship them, so those are unusable as-is. - GRUB: The GRand Unified Bootloader can use badram= patterns as-is too (via the GRUB_BADRAM param on /etc/default/grub), passing those to the e820-generated memory map to the Linux kernel, except that... nope, it can't. At least not in 64-bit machines! Even worse, if you define GRUB_BADRAM with 64-bit offsets, you'll end with an unbootable PC that can't even reach the GRUB menu anymore, requiring to boot via rescue media to undo the setting and hopefully restore bootability. So nope, that ain't do either. - memmap: The expected solution these days, where you can define your own memory map and pass that to the kernel commandline. Documentation is of course confusing, but the only thing we need to know here is that for excluding bad RAM areas, all you need to know is 1) the size of the area to exclude, and 2) the offset, then you pass them in a somewhat more user friendly way like "memmap=64K$7400MB" to exclude 64KB of RAM at ~7400MB. Or use hex numbers and offsets, LIKE AN ANIMAL: "memmmap=0x1000$0x0000DEADBEEFB00B". Basically the syntax is "<size>$<address>", and you need to remember to escape that $ on /etc/default/grub with THREE backslashes! (GRUB_CMDLINE_LINUX="memmap=0x1000\\\$0x01234567") So it's just matter of telling memtest86+ to output badram= patterns, take the offsets and use them on memmap, right? HAHAHAHAHAHAnope, this shit as expected is not only poorly documented, it's also somewhat misleading because thanks to the magic of MMUs, system-specific memory layouts, and other black wizardry, the kernel and 3rd-party memory testers may not agree on the actual offsets of the bad RAM spots. This of course bite me because I was still experiencing the random SeaMonkey crashes even after excluding the bad memory (and then some!), and it even managed to bite Steam too! So... what gives? Enter the kernel's built-in memory tester, triggered via the memtest=<num-of-passes> option. memtest86+ was telling me I had a dead bit at 0x00000000a00f2888, but after using Linux memtest=8 (you may need to try with a larger number of passes since this thing is not at exhaustive as memtest86+ is!), the kernel was finding the same bad bit at 0x000000001e00f2888! That's a 0x14000000 difference, dunno why, but seems to be consistent on each boot so I'll go with that one, therefore my memmap magic param turns out to be "memmap=1M$0x00000001e00f2000", that is, I'm excluding the entire megabyte surrounding that bad offset just to be sure. I got very VERY lucky that this hard-to-diagnose fault was ONLY hitting my web browser, and not something more delicate... like a filesystem driver, or the kernel itself, or the shared video memory! Of course the real solution here is to just go out and buy moar RAM, but that's not exactly easy in the land of the Sovereign Bolivar Mark II, still it's something I intend to sort out this week, hopefully! In the meanwhile, let's pray that the faulty RAM stays confined and doesn't spread :/ --- In other news, remember the KDE3.5 revival? My previous experience with Trinity Desktop Environment were ruined because of Arts and Pulse not cooperating (instead, Pulse was hanging while turning that poor ol' Thinkpad single-core CPU into Furnace Mode). After upgrading to Bookworm, TDE followed on and released a new, Bookworm-compatible version, and oh joy, I can now turn on TDE's sound services without clashing badly with Pulse! Poetteringware hateboner averted. Now it's time to plan the deployment of TDE into the rest of my fleet, since MATE is getting devoured slowly by the GTK3+ worms :/ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-06-25, 03:07 (revision 1)
|
|
Dinosaur
Post: #1243 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
How to let your vintage Windows 9x/XP/2K boxes talk to your Samba server: Edit your smb.conf's [global] section to look like this: The username map file has a trivial structure that looks like this: This is ONLY needed in 9x/Me since those OS are dumber than rocks and assume that whatever user "account" you're using is the same you want to use to logon into a NT/SMB server (instead of asking for it like NTs do), which most likely is not your case. Restart smbd after you're done with your edits here. (I'm not sure if the username map file is case sensitive, but be aware that Win9x is sending usernames in ALL CAPS) Don't forget to re-set your SMB passwords after all this (# smbpasswd -a yourLinuxUsername), since NTLM and LANMAN use different algorithms and by default Samba won't save hashed passwords for the latter, preventing your 9x hosts from ever logging in. And before the SEKURITAH LOLSEARCHERS come at me with their "reenabling those ancient security algorithms is a bad idea" rants: 1) FOR AMUSEMENT ONLY! 2) Don't do this on a machine directly plugged into the raw Internet, a production server, etc. 3) Go hack into a bank, the Kremlin, or something else! --- In other news, I replaced the bad RAM in my laptop, so I got rid of the memmap= entry for now. Be aware that memmap= CANNOT be used on UEFI systems with Secure Boot enabled because of "security concerns" (yes, I still believe Secure Boot is a solution looking for a problem), so either get rid of Secure Boot, or replace that RAM ASAP! --- Just updated my Inspiron 6400 to Bookworm. 4GB of packages that took ~2h30m to install, not bad! Here are the gotchas I found along the way: - GRUB_DISABLE_OS_PROBER=false. This shit is getting tiring, Debian! Not everybody lives in a LVM set! - The default font on this one was set to "Sans Regular", which now maps to Cantarell instead of DejaVu Sans. Turns out that while Cantarell looks ugly at 11pt (the default for new installs), it actually looks pretty nice at 9pt, so I'm keeping that~ - You won't be able to scan anymore from GIMP via xsane because some random bug reporter took a deprecation warning too serious, without even consulting to actual users of this thing! Your options: 1) Install "sane" (NOT xsane), then you get xscanimage... which is a barebones version of xsane devoid of nearly all of the functionality. Oh, and that one also triggers the OHMYGOD deprecation warning too! 2) Revert this stupid patch (because GIMP 3.0 is not shipping anytime soon). For fun, let's do it the Debian Way™... mostly: (the "apt-mark hold" is required since your rebuilt package will have a slightly lower version number than the official one, unless you wanna tamper with debian/changelog too) I'll be dropping some angry remarks on those bug reports... Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-07-03, 00:26
|
|
Dinosaur
Post: #1245 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
Forget about using libvdpau-va-gl1 on VLC on Bookworm: it's so broken it fails to do any kind of hardware decoding! You might as well fall back down to software decoding and hope that your hardware is not too underpowered for the media you're trying to playback. If you have a Radeon (even one like my lowly HD2600), you still have another fallback: native Mesa VDPAU drivers. Except that VLC crashes when trying to play certain media, namely, Blu-Ray menus. Yay, the curse of ATi drivers never ends! Tried also using good ol' Xine (yes, that thing still exists), but... nope, it has aged badly. VERY badly. I completely failed to get hardware decoding working with it: VDPAU would crash (due to the previously mentioned driver issue) or do nothing (va_gl), and VAAPI surprisingly was broken too (the driver would be loaded correctly, but it resorted to software decoding anyway). So yeah, forget about playing discs with menus on Debian 12 :/ (also fuck mpv devs for insisting that disc menus are noise!) --- And now, for something completely different: testdriving Trinity Desktop Environment R14.1.0 on Debian Bookworm! MATE is my DE of choice, but thanks to GTK's braindamage slowly corroding it, I no longer consider MATE a long-term choice for my computer use, so I need a plan - The Debian repos are here: https://wiki.trinitydesktop.org/Debian_Trinity_Repository_Installation_Instructions - Do *not* install the tde-trinity metapackage! It will end replacing a stock Debian branding package (desktop-base) with their own one (destkop-base-trinity), creating potential for weird things to happen. Either install tdebase-trinity, or install their direct metapackage dependencies (tde-core-trinity, tdeedu-trinity, tdegames-trinity, tdetoys-trinity, tdeaccessibility-trinity, tdeaddons-trinity, tdeadmin-trinity, tdeartwork-trinity, tdegraphics-trinity, tdemultimedia-trinity, tdenetwork-trinity, tdepim-trinity, tdeutils-trinity, tdewebdev-trinity). Feel free to ignore those that you do not need/want. - I ended tripping a landmine during install on my Inspiron, because one of the dependencies of TDE is libart-2.0-2, which is a library that exists in both Debian and TDE, but the latter ships with a higher version number. Since nothing else uses this thing (it seems), it should be safe to replace... except that in my case it ended installing the i386 version, which was causing the entire setup to abort badly, and no magical spell of apt(-get) will fix it, leaving with a BROKEN Debian install! OUCH. The fix took me some time to figure it out: dpkg -P libart-2.0-2:i386. Then let apt-get --fix-broken do the rest. WEIRD ERROR MAN. - This is good ol' KDE 3.5 (Peak KDE, if you will), but that doesn't mean it is stuck in the past! TDE features a optional desktop software compositor, which is actually a custom version of Compton. Put that GPU you paid good money for to good use~ - Slap these two lines in your ~/.Xresources to stop (Or use your favorite xterm theme, if that's how you roll) - Theme integration! A favorite of mine. Sadly you can't use GTK themes with the bizarro Qt3 zombie that TDE uses, but here is how you achieve reasonable integration with your GTK apps (since we're forced to coexist with that pest for as long as our web browsers rely on it): first install gtk-qt-engine-trinity and gtk3-tqt-engine-trinity so you can set your GTK apps to use THEMES NOT NAMED FUCKING ADWAITA (GTK3) or ancient Motif-inspired junk (GTK2) - installing those two will enable the GTK appearance settings page on the TDE Control Center. As for achieving the unified GTK-Qt look (in my case, Cleanlooks), you can install tde-style-qtcurve-trinity and gtk2-engines-qtcurve (please use --no-install-recommends with this one, or it will try to install a bunch of Plasma 5 vomit!) to get the insanely customizable QtCurve theme, which even ships with a quite convincing "Kleanlooks" preset. Stuff I still need to work on: * Minor font screwups (particularly with filenames with Chinese characters) * Find a temperature/network speed monitor taskbar applet (the ksysguard-powered one SUCKS, and I do remember using something much nicer in my KDE3 era!) * Figure out how to replace the system beep with an actual audio file (like MATE does) * smb:/ network browser won't list machines in my network So far, I'm lovin' it™, but there is still work to do. Also, no Wayland stench in the horizon here! Just me, and a (mostly) non-braindamaged desktop! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-07-04, 01:29
|
|
Dinosaur
Post: #1246 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
More stuff I need to find fixes/workarounds on TDE: * GTK3 apps ignoring specified font sizes (I really do *not* want to go back to my KDE4-era .xprofile/gtkrc fuckery!) * Rendering glitches with GTK2 themes (for example scrollbars being rendered... a bit too flat) * TDE's Konqueror insistence on feeding useless file URIs when you try to open a file (this often causes pain when dragging and dropping files into VLC, or trying to play something with mpv from a SMB share since they punted support for smb:// URIs to ffmpeg - this somehow automagically works on MATE because of GVFS doing some Magic™ behind the scenes, but not these old crusty kioslaves!) * Find a better way to integrate system notifications from non-TDE apps Also need to perform a KDEctomy on my current, now dormant Plasma installs. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-09-17, 21:18
|
|
Dinosaur
Post: #1257 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
After imaging (and verifying!) the Asus, I've decided it's time to give up VLC, the Fermi dGPU, and move on with the Bookworm update. Of course, I fell into a completely unexpected set of pitfalls this time, but as usual, victory was achieved: - Upgrade failed halfway because of some long forgotten (self-built) mGBA .DEB. apt-get --fix-broken dist-upgrade was enough to give a push for the process to continue. - libdvdcss is installed these days via libdvd-pkg because the DVD CCA goons are still willing to sue people over distribution of DVD players that haven't paid the bribe for a weak crypto key. This one also kept failing, so I had to manually dpkg-reconfigure libdvd-pkg to settle things. - For the first time EVER since I become a Debian user 11 years ago, I've had problems with the supposedly supported way of upgrading from oldstable+backports to stable - for whatever reason the Qt6 and the kernel 6.1 had newer version numbers on bullseye-backports rather than bookworm, so the installer left those in place. This also means that while doing the post-install vacuuming of old junk, I ALMOST ended deleting the kernel I was running because apt didn't bothered installing linux-image-amd64, and Synaptic flagged the kernel package as "old/local". Fortunately apt has a safety net that stops you from nerfing your system that way, but COME THE FUCK ON... Fixing Qt6 was fun too - had to remove qmake and friends so i could "downgrade" the packages to the proper, Debian-kosher versions from stable. - The noVideo 390.xx blob remains there for now - it won't be autoremoved during upgrade, but by the time Trixie hits stable (in less than 2 years from now on), it will be Nouveau or nothing. ICK! Let's hope Maduro is dead and rotting by then so I can afford new hardware, preferably something with less green and more red, or even blue! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 23-09-18, 21:19
|
|
Dinosaur
Post: #1258 of 1317 Since: 10-30-18 Last post: 1 day Last view: 5 hours |
Bought a not-so-cheap USB LAN adapter for the DSL on the routerbox, since dual-port PCI NICs are unobtanium in this country. While I figure out how to configure dual-WAN failover on this thing, getting this horrendously common USB gadget to work properly came with a snag: my adapter uses an ASIX AX88179 USB-Ethernet chipset, which claims to be "driverless" on modern Windows versions (it is not RNDIS, tho), and on Linux it uses some common CDC drivers plus some AX88179-specific bits. Turns out there is a strict loading order of all those pieces of the puzzle, or you will end with this: https://github.com/FreddyXin/ax88179_178a/issues/6 The workaround is simple, but you gotta be careful - not many users bother checking the kernel logs when deploying some shiny new piece of hardware, and then wonder why stuff works poorly! (FWIW, it seems to be finally fixed on kernel 6.1 - plugging the same adapter to any of my Bookworm hosts load the drivers in the correct order) Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
