OMFG

Today I've installed a windows application under wine. How impressed I was, when I saw the icon of that application hanging in the tray!

Firewire mess

Yesterday I stumbled upon a task to transfer few recordings from miniDV camera to my laptop. The camera had the iLink output, so did my laptop. I thought that this should be easy. It wasn't.

I prefer to use Debian kernels. Since 2.6.22 they have disabled old ieee1394 stack in favour of new 'juju' one. OK. But the libraries still aren't updated to use it. Fine. Let's build them. Needless to say, that even with libraw1394 updated to include juju supoprt, dvgrab failed to work.

After some experiments I decided to surernder. After a couple minutes, I've built the old ieee1394 stack, fired the dvgrab with original libraw1394 and started grabbing w/o any major glitches.

I won't ask, why the experimental and still uncomplete stack was merged into mainline kernel. I won't ask, why applicatoins still aren't fully updated to use it. But why the hell did Debian kernel maintainers disable old ieee1394 stack?! If they enable such "beautiful" features, why won't they switch off most of the IDE subsystem in favour of PATA which is much more mature?

distros

There are a lot of differencies between Ubuntu and Debian. It's nothing wrong with having some. OTOH some of them are very... frustrating. E.g. there is still no IcedTea for Debian, but there are Ubuntu packages with it. From my point of view, it's really strange.

Generic pointers mess

One of my latest bugs gave me 4 days of vandering in the dark. I was getting really strange warning from the lockdep when I was enabling clocks on tmio chip. The code was 1-to-1 converted from working one, so there shouldn't be any problems. But there were. After double-checking all locking logic, increasing lockdep constants to really big values and even looking into lockdep details, I finally found the source of the problem: as a private data I passed not the structure I exected to receive.
Pretty trivial problem for a language w/o runtime type checking functionality. Maybe it's time to implement it
as a wrapper around various magic values and type checking functions? In the userspace IIUC glib permits smth. like that, it manages a class-based system with objects allocation, etc. Would I like to see smth. like this in kernel? Probably no. Would I like to see some generic way to enable such checks for objects like spin locks, mutexes, etc? Definitely yes.

Screen protectors

I've received a pack with screen protectors for my tosa. Now I do understand, why they are posted in a packs of 3. One was slightly damaged by our post (damn!). Next one was damaged by me, by applying it to the screen. And only the third one is sitting OK, showing the clear screen to me.

going mainline

During current cleanup & rewrite effort I do generate some side patches related to e.g. UDC or power-management. Most of them are merged into the respective subtrees (and hopefully will propagate to mainline). However today I've received the first Ack to tosa-related patch :) The only thing yet left to discussion is if it will go through the input subsystem or through the ARM patchset. I'm happy.

USB host cable

I've finally managed to get USB-host port of my tosa working. Before I've tried using a no-name OTG cable. Today I've bought the Hama OTG cable and it just worked! I still dunno what's the difference. Maybe the problem lies in the wiring or the length of cables.

Foreword

OK, this blog will hold my technical posts, questions, etc. News directly related to tosa linux kernel will be posted at http://tosa.lumag.spb.ru/.