Years ago, I donated my TV to someone else at home who needed it, just so we didn’t have to buy a new one and give up on buying the laptop that came to be Bluecore. More recently, everyone at home decided to buy new TVs for their own use to replace the old CRTs we’d been using for the last decade — so I was finally left as the one TV-less denizen of this fortress of insanity.

That’s no longer the case.

I have a TV of my own again, decidedly cheap as we didn’t buy it for ourselves, and it works — not that I couldn’t watch TV when I wanted already, since my desktop computer (Blackcore) does have an analog TV capture card that works nicely on Windows (Linux, namely X.org, on VIA IGPs is an atrocious disaster). Most notably, this is the only TV that came with VGA and audio cords, so I can also connect my laptops (or my desktop) to it, although I can only wonder why there’s no HDMI cord when that appears to be what cool kids use nowadays.

It’s not too useful either way, for the maximum resolution such a setup can handle is 1360x768 (albeit the manual claims 1366x768) — compare against Reicore and Bluecore’s native LCD panel resolution of 1280x800. I don’t care much about its purportedly actual function of serving as an entertainment device since local TV kind of died for me circa 2006, when it stopped broadcasting anything of my interest. I spend more time on computers doing work than watching videos or movies anyway.

As an aside note, it appears KDE SC 4.6.5 or X.org server 1.11 (in Debian wheezy right now) don’t handle display output switching very gracefully in regards to window geometries, and windows tend to become 0x0 (when plugging in the TV) or get tossed offscreen (when unplugging the TV). I won’t claim KDE’s window manager is perfect, but in my experience X.org is not the best piece of software found in current general-purpose Linux distributions and it could as well be literally made of explosives and still do its job in the most basic configurations.

As I previously reported, reicore’s hard disk might be dying. This is not surprising in the least, since I have been hearing loud noises from the drive during high activity since a long while — playing vanilla Minecraft is apparently the most straining task for it for some reason. Considering reicore didn’t present any such issues at the beginning, it’s possible the person who gave her to me when bluecore croaked did something bad to her while I wasn’t looking. He’s unlikely to confirm such a thing, though.

A short drive self-test last night revealed that one of the bad blocks is currently part of the very root filesystem. Since I started to consistently hit a bad block while logging into KDE, I decided to run e2fsck -c on all partitions from a Grml live CD system (also Debian-based).

(Yes, I just realized I inadvertently left the swap partition out of the emergency check procedure. I just ran badblocks on it in read-only mode and it appears to be clean.)

Scanning a 466 GiB hard disk for bad sectors isn’t a quick task, but it took just as long as it did with the 1.18 GiB disk on my first computer back in 1998 — about two hours and some minutes — and here are the good news: there are only two damaged sectors, both of them within the root filesystem, and only one file was lost: /usr/lib/libQtDesigner.so.4.7.3, provided by the libqt4-designer package in Debian wheezy.

Why the dynamic linker felt it necessary to access this file while launching Akregator and KMail during the login process is beyond me, but it’s good that nothing was lost, as I promptly reinstalled the package. Either way, I had a fresh pre-upgrade backup in my external 2 TiB hard disk drive ready just in case.

I’ll certainly have to get used to making backups more often than my previous, sloppy biweekly n-weekly schedule. Thanks goodness for rsnapshot!

The last time I tried to switch from Debian stable to testing I was hit by a disease known as X.org Server 1.10, and more specifically, fd.o bug #31017, which made my KDE experience less than worthwhile, to say the last. The solution I devised was not particularly productive either.

However, X.org Server 1.11.1 hit Testing a while ago, and it’s what I am using right now — I successfully switched to “wheezy” again, today, and this time it would seem a massive rollback won’t be required, since the aforementioned bug is finally fixed.

I don’t think I can claim the upgrade was smooth, though.

I figured that fixing the recordMyDesktop breakage in my Debian installation would be worth the extra effort after all, so I made a complete backup of my system and switched all installed packages I could to their debian-multimedia.org counterparts. That is not to say that this road is covered with rainbows and populated by puppies; dm.o’s version of the mplayer package conflicts with Debian’s mplayer-gui package because of one icon file provided by both, so I had to remove mplayer-gui to complete the “upgrade”.

Based on what I’ve heard about dm.o this is par for the course, though.

This repository does not provide custom versions of rMD or its Gtk+ GUI, so I had to stick to the Ubuntu 11.04 (Natty) version of gtk-recordmydesktop (link) to be able to do some configuration again.

The outcome? Success. recordMyDesktop’s videos finally work with both YouTube and ffmpeg, which I had to use anyway to reduce the output’s size from about 250 MiB to 50 MiB so it wouldn’t take hours or days to upload:

$ ffmpeg -map 0.1 -b 2000000 -i Videos/capture/achievement.ogv Videos/capture/achievement-trans-2000.ogv

All just in time for a little personal milestone:

The video is silent, though, for a reason:

It turns out that ALSA doesn’t expose a hardware loopback capture control for me for some reason and that is exactly what I need to be able to capture audio from ALSA applications! I haven’t figured out whether it’s possible to intercept the crap sent to the sound card in software so I’ll just settle for silent captures for now. I could use the laptop’s builtin microphone if I wanted, but I tend to be in really noisy environments where anything can happen in the background while I’m recording.

It’s a real shame that ALSA can’t detect (or reicore’s onboard sound controller doesn’t expose) a loopback control. If anyone knows any method to do the aforementioned interception without using PulseAudio (or Jack, which Minecraft/LWJGL does not support), I’d really love to hear about it.

Previously I discovered that KDE SC 4.6 and X.org server 1.10 in Debian Wheezy are not a happy couple for various reasons. One of them is the garbage appearing behind new windows even on non-compositing window managers regardless of the DDX in use.

The issue appears to be tracked, in fact, as bug #31017 in freedesktop.org’s Bugzilla. Unfortunately, it’s classified as being of medium/normal importance, it’s been sitting there for some time while other entries get marked as duplicates and I hear rumors that X.org server 1.11.0 is coming out soon.

I guess I can only hope later versions of the 1.11 branch integrate a fix of some sort. I’m starting to doubt I’ll be able to stick to Debian Stable for much long, especially if I buy a new laptop this year — right now I’m compiling GCC 4.6.1, that’s not a good sign.

Bluecore is back, but this wasn’t necessarily good news for me. The current situation is a bit complicated, but it can be summed up like this: my father (who supposedly gave me rather than lent Reicore) wants a laptop again, and so do I. He doesn’t need graphics or CPU power, but I do. Right now, Reicore barely fits the bill even if it works better than Bluecore in practice thanks to the extra 100 Hz of clock frequency and not suffering from Bluecore’s mysteriously subnormal I/O performance.

The most optimal solution for us is that we buy a new laptop for me and I return Reicore to its original owner. The only problem with this is that I have even more special needs: I have to run Linux.

And I have a goal: I want to own a piece of NVIDIA hardware.

While I could easily buy the components to build a new desktop machine with the same money, this would not be a good investment now that I’m primarily a laptop user. My poor desktop machine, Blackcore is suspected of having an unstable PSU and may have more internal components damaged than it’s healthy for an expensive graphics card — until now Blackcore has been running with its utterly shitty (even on Windows) VIA Unichrome Pro IGP.

For the purpose of saving electric power while on batteries (or not, global warming and all that crap) computer hardware engineers have come up with hybrid configurations in which there’s a low-power IGP serving as front-end for a beefier discrete GPU that activates whenever it’s deemed to be required for heavy tasks. NVIDIA calls this “Optimus.”

NVIDIA Optimus is not officially supported in Linux, and won’t be, at least for a while.

Whether GPUs in Optimus configurations can be made to work on Linux without resorting to unsupported mechanisms appears to depend quite a bit on the computer model — for the larger unfortunate crowd there’s Bumblebee, which may have achieved memetic status due to an unfortunate typo in the installation script (not even the software proper!).

Unsupported solutions with NVIDIA sound very risky to me (temporary /usr bomb aside) after witnessing the possibilities of supported ones with AMD/ATI. Besides, it seems that to get Optimus to work with Bumblebee it’s necessary to use a wrapper for pretty much every application one wants to use. That isn’t bad per se, however I’m not sure I’ll be able to boast about running Linux and Windows/Wine games like that.

NVIDIA’s official statement on the matter makes me think of their leaders as vile and smug sadists who look down on poor mobile Linux users who pay for their shit. I personally don’t feel so keen on purchasing hardware made by people like that, but it’s a well known fact that NVIDIA basically owns the consumer graphics market nowadays, truly rivaled only by AMD.

Yet, I’m not sure I want to buy laptops with AMD ATI GPUs again after all that I went through with Bluecore’s Radeon HD 3200 on Linux.

After playing around with Debian “wheezy” and getting fed up with X.org 1.10.x, I decided to go back to Debian stable — but not without trying downgrading to X.org server 1.9.2 from Debian Experimental 2010-11-31 first!

It turns out that yes, most of the slowness and pre-paint garbage were caused by the X.org server alone. Sadly, the intermittent shadow glitches are seemingly inherent to KDE SC 4.6 and not to the graphics server.

Annoyed and without the required willpower to file bugs and wait for things to be magically fixed in a few months, I burned a Grml live CD from an ISO I downloaded for no particular reason at all about a week ago (!) and embarked on a journey to wipe out my root file system and restore Squeeze from the pre-ugprade backup in my external hard disk.

It was a successful mision, barring the ensuing breakage caused by the inconsistent versions of GRUB found in /boot and the disk’s MBR.

Whoops.

One chroot and grub-install and update-grub later, Reicore was running Debian GNU/Linux 6.0.1 again, at last. In total, I spent around an hour on the restoration procedure. Cheap.

Let us never speak of this again.

While it’s true that in previous occasions I have switched to Debian testing awaiting the worst to happen to my computer and at the end it’s all been for the better minus the unavoidable annoyance of having to rebuild some of the software I run without the blessings of a package manager, this time the switch from Debian GNU/Linux 6.0 “squeeze” to “wheezy” (current Testing) surpassed my expectations.

I knew that something would go wrong but I expected it to be a temporary issue of the kind “oops, packager screwed up this build, uploading a fix to Sid shortly”. However, for all I know it’s a more complicated issue that just hit me in the face, and it’s called X.org server 1.10.

Stable uses X.org server 1.7.7, which is well tested and stable and worked well with my hideous mix of newer libraries from upstream (Mesa and libdrm from git master, xf86-video-intel 2.15.0) and in fact provided top-notch performance despite its age.

Some time around the end of 2010 while I was still using Bluecore, I switched to X.org 1.9.x from Experimental, of all things, and didn’t cause any problems with my ATI R6xx-based configuration. I was an idiot and switched to Debian testing now based on my previous experience with X.org 1.9.x instead of considering that the second version number is not attached to bug fixes but features. (A Wesnoth developer is supposed to know better, I know. I’m an idiot and I deserve this.)

Now the jump from Debian Stable to Testing was particularly rough because it’s left me swamped with a lot of bugs that are difficult to describe and leave me in the uneasy position where I’m unable to discern exactly what I should report and to whom.

Following the switch, I restarted X without rebooting and logged into KDE SC 4.4, noticing some annoying issues:

• Kwin’s compositing became glitchy, with menu shadows being partially or completely missing at random.
• Huge black rectangles or random garbage lines started appearing in place of popup menus or combo box popups for an instant; while the menus/popups are correctly drawn at the end (bar their shadows) the effect is pretty nauseating.
• Cairo/Gtk2 applications’ performance went down the sink with compositing enabled.
• Frogatto and other GL clients no longer run at near max framerate when compositing is enabled. (Uncannily, this also affects Wesnoth, a pure-software SDL client which I previously had to run under a compositing WM to make it playable at all on Bluecore!)

That was with X.org server 1.10.1. In rage, I grabbed version 1.10.2 from Sid, and KDE SC 4.6. Neither solved it.

I’d like to blame the X.org server itself since using Mesa, libdrm and xf86-video-intel from Debian did not help either. Neither did switching from Linux 2.6.38.8 to 2.6.39.1. All signs point to an issue that’s completely out of my control as a user. To make sure this was the case, I asked Ivanovic in the Wesnoth devs IRC channel about it. For the record, he uses Gentoo and the open-source Radeon stack on an ATI R6xx family GPU, while here I use the Intel stack on a GM45 IGP.

<shadowmaster> Ivanovic: are you using X.org server 1.10.x and KDE SC 4.6 there? do you see some garbage beneath the areas where a window will be  drawn when compositing is enabled and very awful gtk2 drawing performance?
<shadowmaster> (garbage that goes away once the window and its shadow are actually drawn)
<Ivanovic> yeah
<Ivanovic> no idea about gtk2 drawing performance
<Ivanovic> but yeah to the rest

The drawing glitches are only slightly more bearable when using QtCurve in place of Oxygen and Oxygen-gtk. Using Fluxbox helps with the Cairo/Gtk2 performance loss (which impacts GIMP hard) but not with the menu pre-paint garbage glitch, which seems to not be tied to any window manager, Gtk2 engine or client in particular.

So yeah, I got KDE SC 4.6 as I wanted. Is it an improvement over 4.4? Perhaps — whatever Kwin optimizations have been done in the mean time are pretty much irrelevant right now. Plasma is very dependent upon a graphics server that does shit right, and this is not one of those right now. The new (4.5?) notifications are nice, though.

Of course I really regret the idea of switching to Testing at this point, but I somehow can’t bring myself to nuke it and restore Stable from the pre-upgrade backup snapshot that I still have in my external hard disk. Perhaps I am masochist after all, or I have hopes that this will be solved in the next version of whatever component regressed so hard. Just… don’t try this at home!

Sooner than expected, I was notified that Bluecore had been repaired and was awaiting to be retrieved in the support center. Thanks to my never-ending laziness, however, the retrieval did not take place until yesterday.

The verdict was that the screen had to be replaced.

A big problem with this is that I still see the same gray stains beneath the screen’s outer layer that were there back in February the last time I used Bluecore, around the top left corner of the panel, which brings up the question, what did they mean by “screen”?

Whoever did the repairs or testing managed to boot and properly shutdown Linux several times, so my logs indicate that the first successful boot (resuming from hibernation) took place around 15:30 UTC-04:00 (+DST) on April 28th. I’m glad that they figured out how to turn it off from the KDE display manager instead of resorting to wild button pushing.

Since the repairs were effected under an “extended warranty” plan from the store at which Bluecore was purchased, the only mission of the tech support people was to make Bluecore boot again, so everything else (fan, keyboard, etc.) is still in the same crappy conditions, except for the touchpad buttons — oddly enough, the right button is no longer hyper-sensitive to touch and works correctly.

I’d love to know exactly how a screen replacement fixed the laptop or whether it is really possible and valid to replace all display components bar the outer transparent material layers with the aforementioned stains.

Bluecore is now officially dead, and only a miracle could bring it back to a usable state. During the next week I’ll be taking it to technical support, so the current condition will hopefully be temporary.

Some days ago, I came up with a joke in ##shadowm regarding a hypothetical “Reicore” laptop, which would have some awesome NVIDIA GPU and a quad-core processor. This is most likely not going to happen, yet I have reused the computer name on my new, temporary laptop, which used to belong to my father and was, in fact, bought exclusively for his use during 2010.

My main reasons for choosing “Reicore” as its hostname over another “<color>core” combination are the following:

1. Like its namesake’s namesake*, Reicore is intended for backup purposes until Bluecore or a new laptop come to replace it.
2. It’s a nice reminder so I don’t complain about inefficiencies in working computers again. That seems to bring bad luck.

Last night, after shutting down bluecore and leaving it alone for hours, the BIOS boot stage failed and I had to turn it off and try again. Today that’s not the case, and bluecore won’t boot.

I do not understand why is this, or what could be the cause, since in both opportunities the laptop went through a successful hibernation cycle from Linux. There doesn’t seem to be any relation to the AC adapter or battery status, since I tried turning it on with different power source combinations. The GPU and display screen don’t come up, and the keyboard doesn’t work — the only visible indication of (in)activity is the two blinking Caps Lock and Num Lock LEDs, which I saw before when Linux wouldn’t resume from suspend-to-RAM properly back in the 2.6.26 days, two years ago.

This means that my files, configuration and software are currently inaccessible and unusable, save for a ~2 weeks old complete system backup on my 2 TiB external hard disk, which I could use with the machine I’m using right now, blackcore. There are various problems with this desktop computer, however, that make it barely usable with Linux. In particular, GL applications crash X.org thanks to VIA’s nearly nonexistent IGP support, and there’s nearly no means of 2D acceleration.

The current plan is to take bluecore to the technical support people. Hopefully they’ll prove their worth in money this time.

Despite Espreon’s rather unfortunate accident with the (back then still experimental) ATI R300 Gallium3D driver from Mesa, I have been wanting to give the R600 driver a try since a while, especially after consulting on the #radeon IRC channel about its feature status.

R600g appears to be rather complete and on par with the classic Mesa R600c in terms of capabilities, and while I did not try many applications with it yesterday to avoid tempting fate, I witnessed its performance on a Linux 2.6.37 kernel, using the latest libdrm, Mesa and xf86-video-ati DDX code from the Freedesktop.org git repositories.

In terms of speed, R600g has some major drawbacks with some of the applications running on my Debian Squeeze/Sid+Experimental laptop, most notably KDE SC 4.4.5’s window manager. Apparently there’s a small incompatibility between KWin in 4.4.x/early 4.5.x and Mesa Gallium3D that renders the OpenGL compositing code really slow for most purposes, albeit still usable. Someone in IRC mentioned to me that he experienced the same issues in KDE 4.5.1 but not 4.5.5.

In fact, replacing KWin with Compiz did the trick for me. I don’t run any serious benchmarks here, so this is all pretty subjective, but I could swear Compiz runs slightly faster with R600g than with R600c.

Then there’s one of my favorite time-killers, SuperTuxKart. Performance with R600g seemed to be on par with R600c — that is, without disabling some of the game’s visual effect features, the poor graphics stack here could barely manage around 30 FPS. On the other hand, R600c suffers from some texture corruption bugs with STK that don’t appear with its Gallium3D counterpart.

Frogatto is a whole different story. It’s already suffering great performance penalties in some border cases with transparent background tiles using the classic DRI/DRI2 driver on KMS mode; with Gallium3D, it’s just absolutely unplayable in exterior levels displaying parallax backgrounds.

Summarizing, I doubt I’ll be able to enjoy R600g until Debian Squeeze is released and a newer KDE SC version (probably 4.6.x by that point) makes it to the package repositories. I still plan to figure out exactly what’s wrong with Frogatto on R600c and R600g, somehow.

There might be some hope with the ATI R600 page-flipping code that’s scheduled to land in production kernels with Linux 2.6.38, but I won’t bet on it for now.