Category Archives: Arch Linux

Note to self: Grub2 at 800×600

I made the jump to Squeeze on this laptop with a minimum of problems. In fact, the only real issue of note was the shift to Grub2, which always confounds me.

So I can figure this out with less effort in the future, Grub2’s configurations in Debian are at /etc/default/grub. Adjusting this line to read

GRUB_GFXMODE=800x600

and adding this line

GRUB_GFXPAYLOAD_LINUX=keep

gave me proper screen dimensions all the way through the boot process. Instead of snapping back at the end. :evil: Why would that be necessary? I can only wonder.

Actually enforcing those options will require

grub-mkconfig -o /boot/grub/grub.cfg

Until then, Grub just flaps its lips at you. But once that’s done, it works fine.

Surprising credit line of the day: Thanks to the Arch wiki, which had the information up front and easy to find. Cheers.

Classic RPGs, thanks to gog and wine

I’m happier than a pig in mud today, after getting copies of three of my favorite games off gog.com, and finding that they all work flawlessly in Arch Linux and wine.

I’ve mentioned my unnatural affection for Neverwinter Nights, and I have an original boxed copy of the Platinum edition. I even “maintain” (if I can call it that) a quick step-through for a script that installs it.

The Baldur’s Gate series though, is probably the strongest true role-playing game ever written (in my humble and slightly biased opinion), and I’m afraid my experiences with most “modern” RPGs still don’t stand up to that one.

It’s the Icewind Dale pair that I’m really thrilled about now though. gog.com’s installer works perfectly in wine, and both of those games run in fullscreen at their best resolution, without a hitch.

Thus far, of course. For me to playtest the entire game would take … a very long time. I am willing to do it though, if the public demands it. :D

Neverwinter Nights in wine seems to be an unnecessary redundancy, but if you want the shortest route to getting it to work, that might be the solution though.

I have tried the aforementioned script in Arch, and got nothing, and I’ve tried the PKGBUILD from AUR and got nothing. In wine it works like a champ.

With a few small shortcomings. For one thing, as you can see, IceWM leaves its taskbar onscreen while the game is running, which makes it look like the root window is the game.

The easy and obvious way to fix that, without any Googling or terrifying text file editing, is just to set TaskBarAutoHide to 1 in .icewm/preferences, and restart IceWM from the program menu.

Not the most graceful fix, but it solves the problem in a jiffy.

Graphics are good, but I get a wicked slowdown during automated cutscenes or while there are heavy graphic effects underway. I expect that though, since it’s effectively translating the graphics between the two systems.

And it would probably disappear if I would use the established Linux client, rather than running the Windows version through wine. Wine is not an emulator, you know.

I have already found a few pages that give hints on how to make that work; if I can reliably get it going properly, I’ll explain how.

But for now I’m a little obsessed with a few of the games I have enjoyed off and on over the past decade or so. Behind on the times? Yes, I am.

But it’s either that or continue to tinker with Pentium laptops. What’s worse, 10-year-old games or 15-year-old computers? :mrgreen:

Lightweight editors: One audio, one video

I still have a few low-profile graphical applications stacked up, found during some of my distro-surfing late last year. Both are audio-video editors, which are only vaguely useful to me.

It’s true I do, on occasion, have use for an audio editor. It’s rare, but probably once a year it comes in handy.

On the other hand, I have needed a video editor … let’s see, let me think about it … okay, I’ve got it: never in my entire life. ;)

So my opinions on these two are relatively uneducated. Take them for what they are worth; my interest in them is that they appear to run lighter than some other options.

Here’s mhwaveedit:

 

I’ve been through audio editors from as far back as my Windows 98 days, and I really can’t give much more than opinion than the superficial.

This is arranged neatly, it’s fairly easy to figure out, and it seems to have enough options to make it useful. I have most of the common codecs installed on this Arch system, so opening and editing a file was a piece of cake.

I also like the right-side sliders, to control the axis and range of the sound diagram, and the playback speed. It has a few other straightforward tools.

I know there are bigger, heavier suites out there — and not just for Linux. So the audiophiles in the audience may find mhwaveedit less than complete.

On the other hand, if you just need to trim out an audio clip and you don’t want to monopolize a dual core machine for a small task, this will do the trick.

I am a mere interloper with audio editors, but I am a complete neophyte when it comes to video editing. I came across avidemux last month, and it was interesting.

 

Most of the tools and options available here are completely foreign to me. I had a little trouble finding a file it could open, but that might be an issue of codecs or file compatibility. I don’t know for sure.

Once I got it moving though, it was fun to mess with. Call me childish, but it was fun to skip through the video frame-by-frame. :oops: :roll:

And I should mention that there is a CLI version that handles many of its functions as text flags, to include things like normalizing files. That might be handy.

Whether or not avidemux is full-featured enough for your needs is for you to determine. I mention it because it’s considerably lighter than much of the software usually mentioned for video editing.

Keeping in mind, of course, that both of these will probably require some auxiliary libraries to use, and that might complicate your otherwise lightweight lifestyle. Be careful. … :twisted:

Just for fun: A three-part home media system

It’s a new year, so here’s something fun. I’m going to show you one screenshot, and then another, and then tell you what’s going on. First, this really boring console shot.

Nothing special there. mplayer is running. So is alsaequal; that’s probably unusual enough to note. I keep it on every system I have, just as a way to compensate for the sound qualities of the room.

Next, the Toshiba Satellite J12 bequeathed to me for a song, as I mentioned yesterday. You might recognize it; it’s famous on the Internet. :roll:

What’s worth mentioning is the fact that these are not the same computer — the console image you see there wasn’t taken on the Satellite.

It was taken from a machine that predates it by about 10 years, and is networked into the larger one. mplayer is running on the big one, but it’s being controlled from the small one.

Which means all of the interaction — audio control, position, subtitles, color control … everything — is piped back and forth across the network from the big machine to the little, and vice-versa.

But the video output goes to the Satellite’s screen. :twisted:

And there’s one more thing here that I can’t show you, because there’s nothing really to see. The DVD rip itself — the actual video file — isn’t on the Satellite.

No, it’s being served across the network by still another machine — and this one is almost as old as the control system.

But with an oversize drive and a fast network card, it can serve video data over a wireless connection, which is played on the larger machine, which is controlled by the oldest computer in the house.

(This is the part where I apologize for the post the other day, suggesting that screen and mplayer have a difficult time working together. They did, but the problem appears to have vanished with a fresh installation. My mistake. Sorry about that. :oops: )

More importantly, that means this is another possible use for an out-of-date or ancient computer: as a front-end for a larger one.

And most importantly — to me, anyway — is that the entire circuit, from controller to server to display, runs without the need for Xorg.

You only need framebuffer support on one machine — the display computer, and that one can be as powerful or as not-powerful as you like.

Considering I used to play the same DVD rips on a machine that was running at 550Mhz with only 4Mb of video memory, that’s not saying much. ;)

Here’s a little detail, machine by machine.

Controller: This only needs ssh access to the main machine. I run this with Crux i586 on the second tty of a 120Mhz Pentium, and ssh into the display machine. I also have the Terminus font installed, but that’s neither here nor there.

Networking hardware is an ancient pcnet-driven PCMCIA card, and that’s more than enough since the traffic in and out of this machine is negligible.

Server: A server system can be and do a lot of things, but for my purposes Debian is perfect, and easy to set up too. I put everything in the home directory of a privileged user, and serve that directory as an nfs share.

The network connection is a ralink PCMCIA wireless card, which was rather quirky to arrange, but gets good upload and download speeds, and so is best suited for this situation. Best of all, the power draw is less than a light bulb, it takes up almost no space, and has a battery backup in times of need. ;)

Display: This machine is the winner this time, chosen for its large (to me, anyway) screen, clear display and speedy network access. I using the wired Intel PRO/100 connection because I have a five-meter network cable, and I like the fast access speeds.

This machine needs the most in the way of software, because this is where most of the action happens. To wit:

  • Framebuffer access. If you’re using a modern distro you probably already have this. If you’re using a very old computer, it might be a little tricky to get working.
  • mplayer and codecs, if your conscience allows. I should mention that archlinux.fr keeps a codecs package in its repository.
  • ssh daemon. Remember dropbear is considerably lighter than some other ssh suites. And remember Remy’s ssh dialog, if your connections are stacking up.
  • nfs client access. If you prefer samba or another service, you’re on your own. :|
  • alsa or another audio subsystem, of course. Unless you can read lips, I guess. … ;)

I also include screen and a few ancillary programs, like alsaequal, mc, htop and moc. They’re all useful on the odd chance, or for playing music if video isn’t required.

I mentioned networking equipment for all of these, because that’s where your bottleneck is. I am confident my 133Mhz Pentium can actually serve up those files in plenty of time for the Celeron M.

But if I have a slow wireless card in it, or if there is network pressure from other machines, things start to stutter. So be aware: Skipping playback, in my experience, is probably because of network speed.

(Those new Blue Ray DVDs ripped at 1080p or whatever are going to be tricky. Even my core duo has trouble with those, and that’s if they’re on the local drive. :shock: :| )

That’s all for the hardware I’m using. There are a couple of minor points that should probably be addressed, in way of configuration. First of all, it’s useful to know a few of mplayer’s flags, like …

  • -zoom, to expand or contract the output,
  • -fs, to push the size to full screen, which paints the outlying areas black, as opposed to leaving leftover text on the fringes,
  • -x and -y, to manually force the dimensions of the output,
  • -vf scale=x:y, to scale the output instead, or
  • -aspect x:y, to force an aspect, and
  • -vo, to force a video driver, although with nothing else on the machine, mplayer (in the default Arch version) jumps straight to the framebuffer.

In my case, this is what my ~/.mplayer/config file looks like.

zoom="1"
fs="1"
vf="scale=1024:-3"
vo="fbdev"

The -3 in the vf line throws the y dimension out to a proportionate depth. I think. I can’t find the documentation on it, but I’ve had it around forever and it seems to work. I know, I know: Google is my friend. …

That’s not the last though. This little trick is this coup de grace:

setterm -cursor off -blank 0

Because even with mplayer’s -fs flag, the cursor on a tty screen will blink by itself, in the middle of the screen. Sometimes. But more importantly, -blank sets the default video timeout for the terminal to zero — meaning, never.

Otherwise, after about 20 minutes, your screen will go dark and you’ll have to get up and walk over to the keyboard, and press a key to get the image back. And we can’t have that, now can we? :mrgreen:

That’s all. Let me know if you can get this working with something in the handheld department, because that might be where the fun lies.

I have heard of people connecting to home networks with Sharp Zauruses (Zaurii?) or Toshiba Libretto minicomputers. Something that small … well, it’s practically a remote control. ;)

Just don’t fight over it. :mrgreen:

P.S.: I should mention, if you are more keen on forcing the video into Xorg instead of the framebuffer, to try the xinit command with DISPLAY=0:1 and your mplayer command. And to remember xset s off, which should stop screen blanking. Beyond that though, you’re on your own. … :)

mplayer and screen, in a fight to the death

Edit, 2011-01-01: I should probably apologize at this point, because a clean and default reinstall made this problem disappear. Apparently it was a problem with my system configuration, somewhere. Sorry for the false alarm. :oops:

It took me long enough, but I finally ran aground on that quirk between screen, mplayer and the framebuffer in Arch Linux.

I’ve had people e-mail me or leave questions here asking how to get around screen’s stranglehold on the framebuffer.

For the uninitiated, you can duplicate this … behavior … by building an Arch system, forcing it into a non-default framebuffer dimension, starting screen, then starting mplayer.

Just be prepared to cut the power on your machine, because mine locks completely each time.

Outside of screen though, mplayer seems to be working fine. It will even seek out the framebuffer on its own, without the -vo fbdev flag, and play a movie normally.

But as for fixing that lockup … ?

To be honest, I don’t know. I need to experiment a little more. Right now the only way I know to get both screen and mplayer working well together is to include Xorg.

I know what you’re thinking: You’re thinking, “What … ?” It’s nutty, but if I start screen in a terminal emulator from within X, then start mplayer from there, I can force mplayer to the tty1 on the framebuffer.

Which is so completely bizarre as to be absolutely unuseful. I’ve heard of some wacky solutions to weird problems, but that is not a solution. Heck, that’s not even an option. But what can I say: It works.

And when I think about it, it does lend itself to a few interesting permutations. … :twisted: Stay tuned. … :D

Back to Openbox

I became a little disenfranchised with my pretend Windows XP Classic desktop almost a month ago, and switched gears slightly.

Soon afterward I realized my disappointment with the desktop was rooted in IceWM, and not just in the theme I had built up around it. So I’m back to Openbox now.

And because I was feeling a little nostalgic, I put that together to mimic a desktop I was using about four years ago, also at Christmas. The machine has changed, the distro is different, but the look is similar.

I still have a little bugs to iron out, here and there. I haven’t relied singularly on Openbox for the better part of a year, and there are some shortcuts and configurations to learn.

And it has been even longer since I tinkered with conky. I know: What I have there is rather primitive, compared to what it can do.

But this will suffice for now, and should keep me fairly busy over the next few days. My real-world obligations peak today and then I should be able to coast into a nice, long, well-deserved end-of-year holiday. And I have a few things planned. :twisted:

Stay tuned. ;)

A companion for the CLI

Now this is something very very cool.

That’s CLICompanion, and probably one of the coolest tools for Xorg-plus-CLI I’ve seen in a while. At least since screen-plus-yakuake.

This is great if you have a lot of console commands, you’re tired of working with a shell history, or you’re trying new applications that need long strings of flags. Or you have a library of favorite commands, or you’re comparing configuration files, or … or … or …

You get the idea. If you like the idea of command-line life, but you prefer a full graphical desktop, this is a good starting point.

If you’re new to console commands, this will give you a two-click library to run them from, plus a gaggle of tabbed interfaces to experiment with.

It’s not purist, you’re not taking much of a stand for minimalism and it’s not going to win you any geek points from the office IT staff. Those guys and girls will always know more than you, and they won’t let you forget it. :twisted:

But it’s ridiculous fun, easy as pie to manage and doesn’t require much more effort beyond point-and-click to get started.

Get to work importing your library of favorite commands. This will probably make them a little more fun again. Or at least give you another tool in your ascension to text-only Nirvana. :D

P.S.: That’s the AUR version, which seems to hide the executable in an odd place — /usr/share/applications/clicompanion/clicompanion. Or at least it was odd for me. I believe there is an Ubuntu version; no hints on where that executable is. :)