Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts

Tuesday, 20 May 2008

For the love of eye-candy

Compiz-fusion is lovely, it really is... spinny cube, sproingy windows, neat effects - and even some stuff that's genuinely useful when it comes to organising today's clutter of windows. In short, I like it and find it just useful enough that I'd really hate to have to do without it.

Of course, since this is a Really Cool Thing that I really like, there are some problems. And, of course, these are problems that nobody else in the whole wide world seems to have suffered from, at least as far as google can see (and I've searched and searched and searched...).

I'm actually fairly used to not finding stuff with google - generally when I have a funky problem all I can find is forum posts by other people with the same problem, and maybe something in a language I don't understand that looks like it might be relevant, but isn't.

What makes my compiz woes so much more interesting is that for once I can't even find other people with the same problems. Sure, I can find a few people with problems that look a bit similar at first glance but turn out to be quite different, and I've read plenty of those pages just in case their problems actually turned out not to be that different after all. No joy.

It's not even one thing, either. There are three major problems I had with compiz, of which one is solved, one is mostly worked around, and one continues to baffle and frustrate me. Since I had such a bad time of searching for help on these problems, I figured it was probably worth writing them up a bit. Maybe I'm not so alone after all and somebody will descend from heaven to tell me how to fix them properly. Or maybe what I've discovered will help somebody else in the same position that I was.

Just to add to the fun, I'm unable to reproduce these problems on other boxen locally, even with cloned configuration. And, speaking of configuration, the problems exist for a completely 'clean' user also, so it's not some hairy old piece of config lying around in my setup. But, of course, only on my box.

Anyway... First of all, some background info: I'm using x86 Fedora 8, which has compiz-fusion 0.6. My boxen are all AMD/Nvidia based. The specific box that has the trouble is an Athlon64 X2 5200 with 2GB of RAM and an 8600GTS card (I'm using the x86 architecture to keep things homogeneous here). My desktop environment of choice is KDE (3.5.8), but again that seems to be irrelevant - the 'clean' user has the Fedora default of GNOME.

"Problem 1, if you were an ice-cream, what flavour would you be?"
"Choc-chip, so I could get smeared all over you and leave big splotchy marks."
Problem number 1 is the solved one - a simple change to my xorg.conf file sorted this one out, but I'm getting ahead of myself.

Shortly before I started using compiz in earnest, I discovered VirtualBox and was happily using it to host various OSes for testing/compatibility/whatever. With compiz on the scene, it all started going a bit wrong... whenever the VB window resized there was heavy screen corruption around it. Occasionally the whole X server would crash. Not good, in other words. Smacks of driver/X bug, or similar. It's also worth noting that this problem isn't actually a compiz problem - the exact same thing happens with KDE's compositing manager - it's just that compiz is probably the most common compositing manager out there, and the one I had the problem with.

As it happens, as part of troubleshooting problem 2, I'd made some changes to my xorg.conf file as recommended in one of those 'not quite the same problem' forum topics. The specific change that lead to the problem seems to have been enabling backing store, thus:
Option "BackingStore" "True"
(Incidentally, that didn't make any difference to the problem). Removing that line from the xorg.conf file sorted out the corruption, and now VirtualBox is running just fine again. Yay.


"Problem 2, what would you be doing while you waited for me to get ready to go out?"
"I'd be looking at pictures of old flames."
Problem 2 is my "mostly worked around" one, for those keeping score at home.

I use the 'Animations' plugin in order to have the beam effect for minimised/restored windows, and the burn effect for closed ones. Oh, and some zooming for newly opened windows. All in all, it makes for a visually cool desktop that somehow feels a little more 'tactile' than one where windows just appear/disappear 'whole'. It gives the windows some sort of 'life', elevating them above being mere rectangular regions of a rectangular screen. And, naturally, I'm not willing to do without it. If my windows don't burn when I close them, they might as well not do anything.
So, what's the problem? Well, if I leave my box idle for any significant length of time, for instance overnight (or overday, I suppose - I tend to being nocturnal) then the next animation to be displayed gets jammed for several seconds. The length of the 'jam' seems to be proportional to the period of inactivity, and until it sorts itself out the entire X session is wedged. The effect is noticeable after even an hour or two of inactivity, but really comes into its own after a night/day or so.

What happens is that the effect begins to play, then freezes. So, if I close a window then the fire effect will render its first frame and then everything comes to a complete standstill. The same happens with the other effects provided by the Animations plugin, but not for ones provided by other plugins. My wobby windows are fine, my cube rotates, etc., etc. But that first 'animation' effect gets stuck, with 100% CPU load.

The box is still running fine while this is happening - I can ssh in to it just fine, for instance. I can't switch to a VC though - X handles that, and X is frozen until the effect finally deigns to finish playing several seconds later.

So, what's my workaround? Well, since the Animations plugin is the only one affected, and since I'm hardly likely to miss it when the machine is sitting there with the monitor off, I knocked up a little script that watches for the monitor being turned off by DPMS and disables the Animations plugin. When the monitor is turned back on, the script (re-)enables the plugin. Overall effect: problem solved as long as DPMS corresponds to idle time, which it pretty much does.

The script (and a little more info) can be found here.


"Problem 3, sometimes I feel like my clique is out of control. What alternative could you provide?"
"None. And I'd be sure to get you out of those shift dresses, too."
Ah yes, problem 3. My current Nemesis. The Unsolved One. The great Dunno. Etc.

I make heavy use of VNC: my 'media player' box runs Amarok in a VNC session, my IRC client is also running on that box and accessed via VNC. VNC is great - it's screen for X servers, and what's not awesome about that? Nothing, that's what. Sadly, VNC becomes a good deal less useful if you can't actually use it properly, say if certain mouse-clicks or key presses didn't work. And that's what's happening to me.

Specifically, I can't use the Control, Shift or Alt keys in combination with the mouse buttons. They just get ignored completely and the click happens as though I wasn't pressing any keys at all. Naturally, this makes it rather hard to do various things that require shift/ctrl/alt-clicking/dragging something - and there's actually quite a lot of things like that, as becomes abundantly clear when your ability to do them goes away.

My VNC client of choice is the standard RealVNC vncviewer as installed from the Fedora repos. Before compiz all was well, but now no modifiers. Naturally, I've tried some other VNC clients with mixed results. TightVNC has the same problem, but a really old tightVNC client I have lying around for some reason doesn't. Vinagre doesn't have the problem, either, but it's not really useful for how I use VNC.

So currently I'm stuck using an old tightVNC whenever I think I'm going to want to shift/ctrl/alt-click /drag anything, which sucks.

Try as I might, I can't get the other F8 box here to behave like this - it just works there.

Gah.

Tuesday, 13 November 2007

I hate "upgrades"

The new box is built and working... so that means that it's time to install Linux and settle in. Naturally, the distro I'm currently using is being end-of-life'd very soon, so it's time to upgrade. Should be good, right? Shiny new hardware to run a shiny new Fedora?

Well, it isn't.

There's always some gotchas when moving from one distro to another, even when moving from one version to another. It's not that I expect things to just magically "pick up where I left off", or anything. I'm quite happy to do a little tweaking to bring things back to how I like them... but this "upgrade" has frustrated and annoyed me quite enough already - and I've barely started the process.

Sound support has always been a problem for me in the past, so naturally that was one of the things I was most concerned about with the new machine. One "quick" Fedora 8 install later (after one slow, painful failure to install - you'd think I'd have learnt by now not to add repos until after the initial installation, no matter how much the installer tempts you to) I was ready to go.

I'll skip the sorry tale of "The i586 Driver Packaged As An i686 One" because it's not terribly exciting. And besides, if livna didn't screw up at least one nvidia driver package for each fedora release people would start to think they'd got the wrong repo, or something.

I created a user (I'll move my own stuff in later, so just a test user for now) and logged in.... to be greeted by GNOME. Hmm. I don't like GNOME, and I keep forgetting that Fedora just adores it for some reason, so of course it's the default session type. Oh well, never mind - it's not exactly rocket science to select a KDE session instead, which I did. Safely back in my KDE desktop I opened up the Control Centre's soundsystem module and, with baited breath, clicked the "Test Sound" button... and heard nothing. My poor little heart sank.

And then suddenly the test sound started up. "Oh!" I thought, ever the optimist - heart in boots or not, maybe the sound system just took a while to start. So I tried it again. Same result. A little more testing confirmed that sounds did indeed play just fine - but about 2 seconds after they should have done. So I tweaked arts options a bit, but to no avail. It just wouldn't start playing sounds until it was good and ready to. Grrrr. Mr Google didn't have anything useful to say (at least not in english - I have no idea what all the non-english results said, but the fact that almost all the results fit into this category should provide some insight into just how little google had to offer. So, thoroughly miffed, I went to bed. It was, after all, 6am by this point.

Next day... Since I wasn't convinced that arts wasn't indeed the culprit, I tried sound in GNOME... and it worked perfectly. So arts was the problem. Bah. Some very careful googling turned up a page that mentioned in passing that you can make arts use the new PulseAudio wosname for sound by setting it to use the ESD, which I tried... and it worked. Sounds are still lagged a little (thanks to arts' buffering) but that's as good as it gets in KDE, so "W00t!"

By now I was getting annoyed at the fonts looking less than perfect, so went to turn on subpixel antialiasing with full hinting... only to find that I simply couldn't. The subpixel antialiasing tickbox was greyed out. Oh joy. So, having learnt from my sound tribulations, I gave it a go in GNOME... and whadayaknow, it worked just fine there. Shame I really don't like GNOME, huh? But I prefer KDE, seemingly in spite of Fedora's efforts to make it painful for me.

I'm well aware that subpixel AA and hinting are things that might be covered by patents, or some other such crap, but that never stopped me being able to use them in FC6... or in GNOME in F8. But in KDE, "The computer says 'no'." I checked the livna repo and there's a freetype package there, so I installed that... and now I can select subpixel AA in KDE, making me 'teh winnar!', or something.

Since I was clearly on a roll, I copied my homedir from the current box to the new one. OK, I expect some problems when keeping an old set of config files, etc. but generally it's not that big an issue and things get sorted out in short order.

And yet... and yet... My fonts still didn't look right. It wasn't the DPI - I'd already taken care of that. It wasn't the hinting/subpixel settings or any such, either. No, it was that they don't bloody exist according to anything I ask to find them. They're displayed on the screen, messily, but they're simply not in the list of fonts I can choose from. A little prodding later, I discovered that apparently "DejaVu LGC Sans Condensed" simply shows up as "DejaVu LGC Sans", exactly the same as "DejaVu LGC Sans" does. So, no "... Condensed" font, just the plain one. Which means that for all my config is specifying the font I actually want, and the system is using it, *I* can't select it. Worse still, the hinting on the font as displayed is messy. Looks like I lost my 'winnar' status.

Mr Google didn't manage to help me out here, either, BTW.

So here I am, using fonts I don't really like because that's better than the mess I get using the one I do like (and I use "DejaVu LGC Sans Condensed" *everywhere* - or, at least, I used to... sniff). My sound is working, as best I can tell, so that's a bonus... But still, it's taken me two long days & nights to get this far.

Hooray for "upgrades".

Now I've vented, I suppose I should get back to finding all the other problems and, hopefully, fixing them.

Bah.