Dear lazyweb,
what library, that every decent GNU-loving person has installed (in the range of libm, libz, etc.), could do sha1 encoding for me? I hate to ship sha1.c or sha1sum.c in every single package I make. Reason is that the output of system(“sha1sum $file”); appears to be shell-dependent, and that breaks my firmware-loader for several people. Using a C library/function would fix that.
And whoa!, apparently an airplane just crashed into a building just near where I work and live.
As previously, the newly released 0.1.0-d update (patch, tarball) contains support for two more firmware versions, those with sha1sum c6c94dd77b864f8bd231abf3cb2de4c9d139e1bf and sha1sum 01e291d529e7c18deea2eba252d18114e096276e (provided in the latest OS X 10.4.8). This should make it work again for everyone.
If your firmware is not recognized, please do not just say that it is not recognized. Please send me a copy of your firmware file so I can make it work. Eventually, I hope to be able to redistribute the relevant part of the firmware so I don’t need to jump through those hoops, but right now, this is the only way that I can think of to make it work without getting in big legal trouble.
Dobey, you have some interesting remarks. However, in the end, you are wrong. You are saying that not DRM, but iTunes (or insert some other term here) prevents me from using my music the way I want it to. This is blatantly false.
A gun is meant to shoot people. Not to be used as a teddybear replacement, try it, your son will shoot himself eventually. Similarly, DRM can be argued to not be restrictive, but that is purely theoretical. For all practical purposes, mostly due to political blabla such as laws preventing circumvention and explicit denials to remove DRM from said music, DRM is restrictive. I cannot copy my iTunes-purchased Britney Spears song to my mp3 player because of DRM and its politics. This is not just a flaw in iTunes, but a flaw in the business model. A serious flaw which makes us worry about DRM and its surrounding politics.
And now don’t say that it is not because of DRM, because without those politics, DRM would not be pressed upon us by the industry and would thus not exist.
(See here for the full story so far.) I’ve uploaded a new Apple iSight driver (0.1.0-c, patch) this morning.
The firmware loading could still use some work to be better integrated into the rest of the USB subsystem. Most importantly, firmware loading should be automatic for anyone installing a shiny new Ubuntu on his shiny new Macbook (of course, installing Fedora on your iMac20 should work also, but that’s not the point here). I hope to get some work done in that area at some point in the future, but have some other projects running also. If you’re interested in helping me with this, please contact me.
Edit: link updated (9/27/’06).
Today, in an electronic store, I ran into one of these PIX live mp3/wma players. The advertisement on the side of the box stated:
“Digital Rights Management – This device will play music from legal download sites“
This label is misleading: DRM is not required to play legal music from download sites. See this website for more information.
For all dutch readers (and anyone else), please copy this message in your blog (either in english or dutch) and have all your friends and family members know about it: DRM is defective by design
If they don’t get it, just buy them a decent mp3 player (possibly even one with Ogg/Vorbis support) without WMA/DRM support for their birthday and christmas, just so they don’t have the chance of accidently getting infected with one of those defectively designed right restriction devices. You, your friends and family deserve so much better.
To celebrate the release of the awesome GNOME 2.16, GNOME-NL is organizing a release party tomorrow, Tuesday 9/12, starting somewhere between 16:00 and 17:00 in Stairways to Heaven, Utrecht. Everyone interested is invited to come and have a drink.
Please let us know on the gnome-nl-list @at@ gnome .dot. org if you intend to show up. See you there! Many of the long-time GNOME contributors, many interested contributors and users will show up. If you are interested in GNOME, please come and join us in this happy celebration.
Vacation
In other news, I’m on vacation in the Netherlands for a few days. Good to see some friends and my family again. Next week, heavy labwork in Manhattan starts again.
A few weeks ago, I wrote that sound didn’t work on the new Macbook Pro. A helpful reader sent me in the remarkably simple solution: just show and unmute the “surround” channel in gnome-volume-control (and then file a bug). I also made the gnome-volume-applet use both the surround and the headphone channel, so that it works both with headphones and with speakers. This way, the device works flawlessly (I didn’t test microphone or line-in yet, but that most likely works just fine, also). I’m suspecting the surround channel should be renamed (to speakers) for this specific card type using the hda-intel chipset, and that the other surround-channels and surround-related channels (e.g. to make line-in and mic outputs and have them be used for LFE and for surround sound) should be disabled.
With Ryan Lortie‘s mention on how to setup the remote control to work using appleIR, this means all hardware and features of the device appear to work reasonably well under Linux (including wireless, suspend/resume and such).
Now back to real programming!
As previously stated, I’ve been working on a Linux driver for the iSight built-in in the Macbook Pro. Today, at the DDC in Ottawa (Canada), I got it working in a good enough state to call it useful. I’ll test it in various applications to make sure all ioctls behave correctly, but that should be minor work. This would complete phase I.
The Apple iSight is, on closer look, not UVC-compliant. Format querying (to query which framerates, sizes and pixelformats the device supports) is UVC-style, but data transfer is different. It took me a while to figure out how to get a full image out of those datadumps, but hexedit came to the rescue. The main problem with the driver right now is that it requires you to boot Mac OS X before starting Linux. OS X appears to initialize the device in some way (before that, it is recognized as a vendor-specific device and it doesn’t really do anything), and I don’t know how. Anybody with experience in USB bus sniffing under OS X (or who has this device and is willing to do that for me under OS X or WinXP), please contact me (or leave a message in the comments).
(See this blogpost for history.)
After some trying out, some hangs (“do not write into NULL pointers in the kernel, Ronald, do not write into NULL pointers in the kernel *argh* too late“), some fixing and some more stuff, I can now get a semi-recognizeable picture. Not good enough for a hackergotchi yet, but I’ll probably be able to fix that up soon. After that, I’ll post a patch.
Previously, I write about my Macbook Pro and Linux installation. Most of this works fine now, so time to get the hardware working.
I decided to start with the iSight. Apparently, this is a USB device which shows up in lsusb -v output as the top-most device. What’s better, it implements the new USB Video Class standard, of which a basic Linux implementation exists. Unfortunately, it doesn’t load by default, it errors out early in the initialization process with an error about not being able to retrieve the current palette.
[17186281.868000] usbcore: deregistering driver uvcvideo [17186287.236000] Linux video capture interface: v1.00 [17186287.240000] uvcvideo: Found UVC 1.00 device Built-in iSight (05ac:8501) [17186287.240000] uvcvideo: Failed to query (135) UVC control 1 (unit 0) : -32. [17186287.240000] uvcvideo: Failed to initialize the device (-5). [17186287.240000] usbcore: registered new driver uvcvideo
I of course went on to debug it, and somewhere in this process, I crashed my kernel (oops 🙂 ). However, after a restart, I cannot see the device in lsusb output anymore. A quick touch upon the back of my laptop suggests that the whole machine is highly overheated. So here’s my real two questions:
Also, anyone familiar with the USB Video Class or the USB stack on Linux (and with some spare time), please contact me on IRC (#gnome-hackers), I’d love to debug this thing with someone more familiar with the standard than I am.
Edit: apparently, after a reboot into MacOS X and back into Linux, it is recognized again. It appears some of the (read-only?) fields in the device have to be specifically initialized. This may imply the device is not 100% UVC-compatible. Anyway, it works again, let’s see how it works.
