Doug Goldstein

NVIDIA has released a new set of drivers in the latest series for Linux x86, Linux amd64, and Solaris. Curiously missing from this release is FreeBSD. The version is dubbed 100.14.19 and you can read the shortlog of it here. The biggest thing to note is that X.org 7.3 is supported. The drivers are already committed to the tree and Donnie has already removed the nvidia-drivers blocker in the xorg-server 1.4 ebuild, so everyone should be set. If you’re stuck on the 96xx series or the 71xx series, you’re out of luck for official X.org 7.3 support as NVIDIA has not updated those drivers for the new ABI. However, official word by NVIDIA employees is that if you disable the Composite extension and pass -ignoreABI to the X server, you should be fine.

Basically the new driver adds support for a few new Quadros and improves support for the GeForce 8 GPUs. But the item everyone might notice is actually buried deep in Appendix B on the README. It’s  OnDemandVBlankInterrupts, you put that in your driver section and set it to true and you should see some power savings from your laptops. On my machine with sys-power/powertop, it showed an immediate reduction of 60 interrupts per second.

Overall OpenGL seems to be a bit smoother with compiz and such and general graphics performance seems to be improved, however it must be noted that I am a GeForce 8600 user so people with other cards may not have the same experience I’ve had.

Filed under: Linux, Modular X
3 Comments

So I’ve been working on trying to sort heads from tails from all the Firewire support in Linux. And unfortunately it appears that Firewire support in Linux suffers from the bash it real quick until it works and leave it be. All of the developers that work on the core parts and the userspace libraries, are all maintainers of consuming applications so they really don’t bother themselves with fleshing out the userspace libraries too much. In fact, libraw1394 is the only library that’s documented at all, and even that is an old version. The other libraries are simply read the source, which has no comments. The other bit that adds complication is that the new Firewire stack called juju which went into 2.6.22 and is enabled by Fedora Core 7 by default doesn’t even have support from the userspace libraries which are writing by the same guys that wrote the kernel code. Sure you can do a git checkout of their latest juju branch and get a what they call “mostly” working libraw1394 and libdv1394, but that’s still not considered a release by any means if you have to use git.

My biggest complaint however is with libavc1394. Someone clearly just simply wrapped the firewire spec and the library shouldn’t even be called a library. It’s a set of a handful of functions that require the developer to use the 200+ defines and bitwise add them together to make a valid command and send that out using one of the few functions available. Why this isn’t abstracted away properly for the developer I don’t know. There’s also wonderful stuff in here like returning “quadlet_t *” (which is simply a guaranteed 32 bit int) but no where does it say what the data is or how long it will be. Turns out if you scour the code, you will learn it’s always 8 long. But hey, who needs documentation?  Another wonderful thing is that you have to send commands to specific item types on a specific subunit of a node. Now you can query if the node supports a specific type but there’s no way to programmatically determine the subunit that type is on. This results in most apps having a set of vendor IDs and model IDs and hardcoding it based on this. Also since there are so many bitwise operations required by the developer of an application, all apps I’ve found hardcode some of this to some extent since it was obviously too complex to do correctly to support all types.

A library should be an abstraction to take the difficultly out of the task, not to add additional difficultly.

Filed under: Linux
1 Comment

Currently I’m a Cox Cable subscriber and have their digital cable package. This means that over QAM256 I can get ABC HD (WCJB), CBS HD (WGFL), and Fox HD (WOGX). The other junk I get over QAM are about 100 advertisement channels for PPV or encrypted. This makes my pcHDTV 5500 card not really worth it. The only choice I have is to use the FCC mandated Firewire (ieee1394) output from my digital cable box. Well at first Cox gave me a Scientific Atlantic Explorer 8300, which is a HD DVR box but they disabled the DVR functionality. I couldn’t get anything over the firewire and searching around the common MythTV places, I couldn’t find anyone who did. So I returned the box and in return was hoping to get a Scientific Atlantic 3250, which is known to work and is fairly well supported in MythTV. No such luck, I was given a Scientific Atlantic 4250. I still can’t get any data over firewire from the box, other people I know with SA3250s in my area are able to successfully pull the same channels I am testing. It’s quite frustrating.

At the same time I’ve noticed that Firewire support for STBs really sucks. Each one appears to have it’s own custom channel changer and the code for each is just a copy and paste of a previous one with hacks. All the vendor and model IDs are hardcoded into each app and most of the apps don’t handle everything they need to. i.e. reseting the bus when it’s needed. This has resulted in a lot of wrapper scripts and “this works for me!” stuff going on. It’s really a mess. What I’m wondering is why no one has created a 1394.ids setup similar to  pciutils and usb-utils. That should be the first thing. Then next a generic control app similar to what FreeBSD has done with fwcontrol. On Linux you have to use several apps from several different libraries and even then you don’t get 100% of the functionality. It would also be nice to integrate this into HAL since the HAL spec does define Firewire support. It looks like the new firewire stack will be a step in the right direction but more work is still needed there.

Filed under: Linux, MythTV
2 Comments