So it's time I kick myself into active job hunting. Anyone looking for an experienced software engineer that's highly proficient in C and is quite comfortable slicing and dicing low-level kernel (Linux, RTOSes) and device driver (Wireless Network, Sound, Printer, etc) code?

I've done high-level systems design, low-level board bringups, database backends, Web UIs, data mining, test engineering, you name it. Python, Perl, C, Shell, and Java. Javascript, C++, and even C# in a pinch. What I don't know, I pick up as needed.

My current resume is available, naturally.

I'm based out of Melbourne, Florida, but for some time I've been wanting an excuse to move on.

It can't hurt to try, eh?

First, the ST-E CW1200 driver. For some reason, I keep being surprised at the amount of major surgery between the releases. Since my last posting to linux-wireless, there's been a lot of work:

• Completely rewrote BSS join logic -- IBSS now works!
• Respect TKIP/CCMP group key rx sequence counter
• Improved 802.11g (ERP) coexistence
• Eliminated callback function pointer structures
• Detect CW1160/CW1260 chips (fw load is different though)
• Greatly simpified BSS loss detection
• Fixed deadlocks and/or OOPSen when hot-unplugging non-idle devices
• Pulled support for Sagrad SDIO modules into a separate module that provides the appropriate platform data
• Simplified Beacon filter configuration
• Many, many, many checkpatch-suggested cleanups

I'll probably prepare another upstream submission this weekend, seeing that the driver is now handling everything I'm throwing at it. Finishing CW1260 support needs to wait until I have hardware to test aginst.

Next, I've also spent time on the rt2800usb driver, adding the ability to write changes back to the eeprom and embedded eFuses. This lets folks update the production data baked into the module at manufacture time, which is occasionally necessary when your module vendor sends you seven hundred modules with a single bit flipped that breaks a legacy product's driver. As an aside, Ralink's official drivers are... painful, to say the least. But kudos to Ralink for maintaining them!

Finally, I started adding support for my employer's STLC4560-based modules to the p54 driver. They come in both SPI and SDIO variants, and have an onboard EEPROM for storing the Production Data. The existing p54spi driver is hardwired to have the PDA loaded from userspace, and there's no support for SDIO devices at all. This is a lower-priority project, but it is nice to be working with the venerable NWN/Intersil/GSV/Conexant/ST 'ARM MAC' again.

Mainly because Dotster does not, nor does it have any plans to, support DNSSEC and IPv6 glue records.

If this goes well, then I'll be moving the rest over as they eventually expire.

The morning started with a flurry CW1200 driver hacking; this time focusing on simplifying its interrupt handling. In the process I eliminated two more compile options and three bus-level virtual functions. As nice as it is to write code, it's even nicer when you delete it without any loss of functionality!

After that, I put my money where my mough was and wrote a systemd unit file for Photo Organizer's background workers. For years I've been using screen and a sudo-driven cmdline to fire them off, because I could never come up with a reliable (and portable) init script to do the trick. No longer. As an aside, systemd is brilliantly put together and worlds beyond anything that's come before. It JustWorks(tm).

Then I pulled out my notes and turned my attention to Gutenprint. The Kodak 1400's unexpected complications derailed my plans a bit, but there were still three related printers whose spool formats I'd decoded -- The Kodak 8500, the Mitsubishi CP3020D/DU/DE, and the Mitsubishi CP3020DA/DAE. They are now all supported by Gutenprint, and awaiting testing. The latter two are the ones I'm most concerned with, as I took a few liberties with the spool format.

Basically, the Mitsubishi-branded printers don't spool the data linearly into the printer; they basically write the color-interleaved data in backward chunks. Consequently, the printer can't start printing until all the data is received. To simplify things, I'm sending the data linearly in one big chunk. Hopefully it will work. We'll find out.

On that note, if there's someone out there with one or more of these printers, care to help out? Either by doing some test prints for me, or better yet, sending me the printers? :)

... and the day is far from over.

I can't help but think this a soliticitation for highly illegal activities, if you know what I mean.

It's also been something like six years since my last contribution to Wireshark, so it would seem someone's busy harvesting addresses from old commit logs or somesuch.

EDIT: I've reported this email to google via gmail's abuse form. Going to pass this on to the feds too, once I figure out how to do that.

EDIT2: I've reported this to the National Center for Missing & Exploited Children's hotline.

EDIT3: Many others have also received this email.

Unfortunately, my elation turned sour when I discovered that I couldn't just dump the raw spool file to the printer. Firing up a USB sniffer under WinXP, I discovered that the to-the-printer protocol bore little resemblance to the spool file -- even the image data itself used a different format. To top it all off, the printer needed intelligent buffering.

So, armed with the USB sniffer output, I heavily modified the spooler I wrote for the Canon SELPHY printers. Last night, I achieved success, and succesfully printed the WinXP test page I'd previously generated, but also an image printed using gutenprint.

The Kodak 805 printer that replaced this one probably needs a similar treatment (given that it uses the same spool file format) but unless someone sends me a printer (or cash) I won't be able to test that theory out.

I still have to generate another couple of test prints under WinXP to decode two remaining protocol options, but other than that, the Kodak 1400 printer is now usable under Linux!

Oh, this is the first image I printed on this thing via Gutenprint. I wish I could say it was something I took.

Aside from the Sony changes, the single biggest change was a rebalancing of the tx/rx handling, so that it's now considerably fairer. Of course, there was the usual pile of small changes, including a fix for an OOPS triggered by the broken IBSS code. It's still broken, but at least it's not crashing anything now.

We'll see where v3 goes. Hopefully merged into linux-next, or barring that some meaningful feedback on what I need to do next.

In other news, Before the new year I added support to Gutenprint for the Kodak 9810 dyseub printer. None of the code's been committed yet, but there's no real rush. I'm now waiting on a Kodak 1400 printer to show up -- Once I've verified my core gutenprint changes are sound and that printer works, I'll commit everything, marking the untested models as experimental.

Then I'll tackle the Kodak 8500 and the Mitsubishi CP3020D/CP3020DA, not that I'll be able to test those either.. Afterwards, I'll see about the more modern Mitsubishi printers if I'm feeling so inclined.

I really need to start getting rid of this pile of Canon dyseub printers. Maybe four, instead of twelve. At least the incoming Kodak 1400 is a large-format model!

The result is far simpler markup and faster page loads because there's no javascript rewriting the page on the fly. In fact, the only javascript present now is the code that inverts the image selection, and even that's far simpler because it just walks the list of checkboxes and toggles them.

I'm also giving attention to the layout and especially element spacing; trying to generally improve the intangible "feel" of the site through subtle tweaks that make things much more visually pleasing.

The goal here is to clean out as much legacy cruft as possible, so I can more easily make more complex (but necessary) UI changes. There are still too many tables used for layout/formatting; I'll be trying to eliminate those next.

I'm back to working on this thing for my sake, solving my own needs, making it into something I want to keep on using, and I must say it's a nice change. Yay for (useful) productivity!

But I digress. It turns out the 8500 is essentially a rebadged/tweaked Mitsubishi CP3020D, albeit without 8x12 support and a third variation of the Mitsubishi block-chunked image format -- packed BGR data, sent in one ginormous data block but wrapped in the "traditional' 3020D control blocks. That will require no changes to gutenprint to support, so I'll probably implement support for the 8500 before the CP3020D/DA models it's based on.

Meanwhile, The 9810 is very different from the other Kodak models. It uses a command-stream type of format that's on the verbose side but is otherwise well-structured, with the raw RGB data being sent in a plane-interleaved fashion. Supporting it will require no core changes either.

so, this is my plan of attack over the next couple of days:

• Kodak 9810
• Kodak 8500
• Mitsubishi CP3020D
• Mitsubishi CP3020DA
• Other (current!) Mitsubishi models?

Anyway. Time to go to bed.

I've also reverse-engineered the raw dump formats of the Mitsubishi CP3020D and the CP3020DA 8x10 dyesub printers. They use a somewhat convoluted block-oriented format, with the former using CMY-based plane interleaving and the latter using RGB-based scanline interleaving. To add joy to the mix, the blocks are sent to the printer in reverse order (bottom-up), but within each block the scanlines are top-down.

Once the Kodak 1400/805/6800/6850/605 support is reviewed and committed into Gutenprint, I'll start working on the low-level changes necessary to support these Mitsubishi printers.

Maybe a grateful user will mail one of them to me in thanks? (hint hint)

There are many thousands of these printers deployed in self-serve photo kiosks, and they're trivial to find on ebay. Cost per 4x6 print is under $0.17 and media refills are very easy to obtain.

Meanwhile, the 6800/6850 has been superceded by the 605, and the 1400 has been superceded by the 805. If I'm still motivated I may try to add support for those models too..

I accomplished two major tasks this weekend. First, I finally kicked off new attempt to mainline a Linux driver for the ST-E CW1100/CW1200 WLAN chipsets. The first post to linux-wireless went over fairly well, and the suggestions (many of which were already on the pending list) kicked off a flurry of updates culminating in a second revision posted later that day.

Those submissions have spawned a fair amount of commentary and some patches; I've spent most of the day so far incorporating a massive code drop from Sony, for example. That's undergoing some testing now, and I'm hoping other interested parties will step up and get some wider test coverage in so we can get this driver into the next Linux release cycle (3.9). I created a public git repo of my working tree, which will live on until the driver is accepted upstream:

git://git.shaftnet.org/compat-wireless-cw1200.git

I'm going to hold off on submitting a v3 patch until I get more feedback and testing, which means it probably won't happen until after the new year. Apparently most folks take it easy this time of year.

Thankfully, I've had another project to keep me busy. I've spent a fair amount of time working on the Gutenprint printer driver package too, fixing support for the Kiosk-scale Sony UPP-DR150 photo printer (~8 seconds for a 4x6 print!) and adding support for the larger-format (8x10/8x12) Kodak Professional 1400 printer. I don't own either printer; instead I reverse-engineeried the raw data generated by the printers' Win32 drivers.

Not bad for two and a half days' work, eh?

Meanwhile, there are now twelve Canon SELPHY photo printers on my desk. The entire line is supported except for the CP-790, CP-530, and CP-520 -- and then only because we don't know what their USB PIDs are. The only one with known problems is the positively-ancient CP10, which locks up after the first (successful!) print. All other models JustWork(tm) now. I should start getting rid of most of these.

If I find myself with more time on my hands I may try to add support to Gutenprint for another Dye Sublimation printer. Ideally it would be one still commercially available, not too expensive, and a larger format (eg 8x10) because I can put that to use. We shall see..

If I'm feeling particularly masochistic, I'll continue with my fumbling efforts to implement dock detection for Rockbox on the Sansa Fuze v2. I haven't made much headway on that gargantuan reverse-engineering effort; it's mainly an exercise in learning a new set of skills.

I've also started reworking my website's CSS to improve its curb appeal. Like any other software undertaking, days when you delete more than you add fill me with joy. If I'm feeling particularly ambitions, I'll try doing the same to my photo archive; it could use some sprucing up too, but its underlying plumbing is what could use some real hardcore loving. It's been neglected for far too long, but even that's beginning to pick up, as I've begun to experiment with different workflows.

I'm really enjoying this burst of coding. It's especially nice when you have something to show for it!

I've been thinking about PO's future lately; where I'd like it to go, and to a lesser extent, how to get there. I still don't have a good answer. Pretty much every feature on the wishlist is pretty invasive, and I just don't have the drive to make it happen, because PO has largely done what I've needed.

Most features I've added over the years have been due to my workflow requirements, and I've largely hit a dead end on that front. I've started to experiment with alternative workflow models, but until something gels into a new ideal, PO won't change much.

Since I started on a photo-a-day commitment, my workflow has had to cope with more regular postings, and it's exposed a few cracks in how I used to do things. I'd like to automate some things better, but I'm running into bigger-picture limitations in how I combine PO with my blogging software. For example, none of my "witty" captions have made it back into PO. Fixing this properly means writing a RESTful API to manipulate arbitrary data, which is a huge undertaking.

That said, the biggest driver of change is the massive event-type photography binging like what I got up to last weekend. (Last night I batch imported 44 gigabytes of NEF files; 3,588 images) -- I need a better way of grouping, tagging, and ranking images to manage this sort of thing better. Proper hotkey support would make this a lot easier.

Meanwhile, if the other seeds I've been sowing come to fruition, I'll be working with models on more formal shoots. This will require yet another type of workflow -- less organization, but considerably more post-processing. This means the current versioning system must be beefed up to handle multiple RAW renderings and sidecars. Distributing the final images also exposes weaknesses of PO's permission system.

At the of the day, PO's just a tool that's supporting my needs as a photographer. I'd rather be behind a camera than in front of a computer, especially given that I already spend eight or so hours a day writing software for my day job.

Anyway. As I type this, my PO instance houses some 143,434 images, of which 120,070 are mine. Not counting filesystem overhead, they take up some 1,509,037,063,959 bytes of disk space. Yowza.

In other words, PO's going to be maintained pretty much forever.

This deceptively simple printer test page has been literally five years in the making. It is the first time anyone's been able to successfully JustPrint(tm) with the "newer" Canon Dyesub printers under Linux, at least without jumping through some annoying hoops.

But it's not quite done yet.

I still need USB PIDs for the Canon ES3, CP-200(*), CP500, CP520, CP530, CP710(*), CP770(*), and CP790.

The ES20, ES3, CP-10, CP-100(*), CP-200(*), CP-220, CP-300(*), CP500, CP710(*), CP770(*), CP800, CP810, and CP900 models are theoretically supported but, need testing/confirmation.

Finally, the ES40 and CP790 are unsupported until someone comes along and either donates a printer (or cash) or is willing to be a guinea pig.

So, if you have one of these printers and want to use it under Linux (or modern OSX), drop me a line.

* == Already in the mail, so to speak.

I'm now up to eight Canon dye-sublimimation photo printers, with two more bundles of joy on their way, all in the name of Free Software. It's interesting; a proprietary printer driver was the spark that spawned the Free Software movement, and I'm continuing the tradition with these.

The Gutenprint stack is far more capable than the original Canon dyseub printer drivers.

On a slightly related note, Anyone out there have a coloriometer I can borrow? I'd like to fully calibrate these things.

So, in the spirit of Free Software, I patched gutenprint, and wrote the spooler. Over time, the spooler got smarter, supported more printers, achieved sentience, and brought about world peace.

...Until Apple revved OSX's printer subsystem and Canon neglected to release updated drivers for, well, most everything. Since my tool was written to use linux's native usblp support, OSX users were SOL.

Last night, I finished rewiring it to use libusb, and accept input on stdin. This enables it to be used in a CUPS filter chain, and theoretically supports OSX. But that remains to be tested..

...And I finally moved it to version control:

        git://git.shaftnet.org/selphy_print.git
        http://git.shaftnet.org/git/gitweb.cgi?p=selphy_print.git

It still needs USB IDs for most of the SELPHY line, but otherwise seems to work fine with my ES1, ES2, and ES30 printers, at least on Linux.

Unfortunately, what I have hooked up to my system is a rather pedestrian weather station, not the more interesting missile launcher. And yes, I know it just fires nerf darts or something like that, but I can still dream about an Anti-Air missile installation controlled via USB, can't I?

On the other hand, I doubt .mil publishes their interface specifications, and reverse engineering a missile launcher is likely rather expensive. Not to mention mildly dangerous..

An ideal candidate will be able to code C in their sleep, and have a pretty healthy understanding of the intracacies (and harsh realities) of the IEEE802.11 alphabet soup.

We also are in need of a kickass QA person.

Oh, we're located in Melbourne, Florida, but we're open to long-distance relationships. If you're interested, drop me a line.

It turned out the ES-series weren't. In fact, every generation was subtly incompatible. (Indeed, the latest generation of CP-series is also incompatible with everything else!). But thanks to a motivatd soul, I was supplied with printer dumps for nearly every dyesub printer Canon created. It piqued my interest, and I started generating dumps for the rest of the ES-series, filling in the support matrix for all paper types. The code was committed to guetenprint about a week ago, but remained untested.

I decided to trolling eBay for the second and third-generation printers (ES2/20 and ES3/30, respectively), and much to my surprise, my lowball bids on two of them won. My "new" ES2 turned up a couple of days ago, and the ES30 should be here tomorrow. I spent late last night and part of tonight rewriting the smart print spooler the ES1 needed, and about 30 minutes ago I finally succeeded with successful prints with the ES1 and ES2.

The ES2 is slightly larger than the ES1, has a better UI and a more efficient paper path. It also adds Memory Stick support. Otherwise, it's identical under the hood, with the same print speed and output quality as the ES1. We'll see what the ES3/30 brings to the table when I eventually end up with one.

But in keeping with tradition, here's the first picture I (successfully) printed with the ES2:

This was shot outside my office a couple of years ago.

I'd like to find a colorimeter so I can get a calibrated printer profile, but as usual, there's an endless line of more important stuff I'd like to get first -- like some grids for my studio flashes. Damnit, photography's an expensive thing to dabble in..

[pizza@stuffed] ~]$ yum  
Bus error
[pizza@stuffed] ~]$ dmesg
-bash: /bin/dmesg: input/output error

It seems that something had gone very, very wrong. I trumped home to find the console full of disk error messages. But that shouldn't have brought the system down; The OS was installed on a pair of drives set up in a RAID1 mirror. There's no excuse for a read failure -- If one drive failed, the other should have picked up the slack and kept the system working.

Well, *should*. I made the mistake of setting up the RAID1 mirror using the "dmraid" tools, which piggyback on the motherboard's "fakeraid" metadata. Unfortunately, it seems that this mode of operation doesn't handle failures worth a damn. And that there's no easy way to migrate from the "dmraid" stuff to the very mature and robust native Linux "dmraid" tools.

The dmraid tools have one major disadvantage though -- they are much more dificult to boot from, and from the motherbord's perspective, if the primary drive fails, the array becomes unbootable. So by using dmraid intead of mdraid, I ended up trading one (minor) failure case for a much more serious one.

How does one work around this quandry? By going for a real hardware RAID controller. The ones with onboard pocessors that do all the heavy lifting. The ones that hide the messy details from the OS. The ones that are designed to JustWork(tm) and NotFail(tm).

The ironic thing is that this server already has a hardware RAID controller in it, a 3Ware 9550SXU-8LP, but it's maxed out with two 4-drive RAID5 arrays totalling about 7TB. This server's predecessors both had 3Ware RAID controllers -- and in my decade-long experience with 3Ware controllers, I've not had a single controller-related failure, ever. They JustWork(tm), handling too-numerous-to-count drive failures cleanly and transparently.

So, I just ordered another 3Ware 9550SXU-4LP controller to plug my OS array into. It's used so I got it for cheapcheapcheap, and like the one I already have it's two generations older than their current top-line models, but it'll be more than good enough for a simple RAID1 array. Migrating the dmraid array over to the new controller will be an interesting proposition even without the flaky drive complicating things, but since downtime is unavoidable thanks to dmraid's failings, I might as well make sure things are done right.

If I hadn't picked up another hardware controller, I'd have migrated to mdraid, and booted off of an USB stick. That solution has worked great at work, and those USB sticks are trivial to back up and replicate in case of failures.

In other news, the tally from this weekend is 5581 RAW photos taking up some 62Gigs of space. Been to busy to post anything, but as my backlog empties out, you'll be seeing more here again.