I’ve finally taken the plunge and upgraded to WordPress 2.1 and I’ve got the incredible volume of blog spam I receive and the shiny new Akismet wordpress plugin to thank for that. It only works with WordPress 2.x so if that isn’t motivation to upgrade, I don’t know what is!
And in the last 5 minutes, it’s already caught it’s first spam comment…
Hopefully I haven’t flodded Planet GNOME or any other syndication site that I’m not aware of. Onwards and upwards 
Alright then. As promised earlier, I’ve got a pre-built replacement kernel for the n800 which adds support for MMC 4 and SDHC cards. I’ve been using this kernel for the last week, but I needed to find some time to make sure I’d included a self-consistent set of changes. My main concern was all the MMC/SD changes that went in between 2.6.18 and 2.6.19, but it turns out that Nokia have already backported this set into their kernel.
So, without further ado: go here to download the kernel and/or the patches to the Nokia source.
Building your own kernel is well documented at maemo.org, so if you want to combine these patches with some other kernel tweaks, it’s easy to do so.
As mentioned before, some people have been having random reboot problems when just using the sdhc patch against the original Nokia source. I believe that this is because they are missing bug fixes that are included in my roll-up patch sets. I have not observed any reboots, so I’m pretty confident that that was the source of the problem.
If you try the patches out, do let me know what your experience is – the more testing and feedback we get, the sooner Nokia will be able to roll these into their official kernel.
So, after some effort, I managed to get my n800 ordered last week with my developer discount code (Thanks Nokia!) and it arrived today. It’s thinner than I expected it to be, but I’ve definitely been spoilt by the 770’s hard cover and I’m going to get the n800 cover accessory as soon as I find somewhere that will sell it to a US address. I’ve been playing with it over the weekend and it’s definitely slick – there are some nice usability improvements (like the way the window menu lets you close windows now) and the fully integrated bluetooth keyboard support is much appreciated.
As I discussed previously, the current n800 kernel doesn’t include my mmc4 or sdhc patches but I fully expected them to work once applied. Mark Lee has already confirmed that the SDHC patch works, so I built a kernel with the roll-up of changes that Pierre sent upstream for 2.6.20 (including mmc4) plus the sdhc patch. The patches applied cleanly except that I had to exclude the omap part of the roll-up (already in there) plus make one small fix up. Then, the very first thing I did after unpacking the n800 was flash the new kernel – yep, I didn’t even turn it on first
It came up just fine and I popped my 4GB SDHC card inside at which point it was immediately recognised. Also, in contrast to some reports, the file manager reported the size of the card correctly. I then put my 2GB MMCmobile card from my 770 into the other slot and that worked fine too. I wasn’t able to get useful speed results due to caching (even using dd on the raw card device) but it seems to be faster than if it was only doing 1 bit transfers.
When I get some time later this week, I’m going to make a custom kernel available with the MMC and SD changes in it.
In other news, 2.6.20 is officially out and Pierre has pushed out his batch of changes for 2.6.21 including the SDHC support, so it will hit mainline at that time. I don’t expect Nokia to bump the kernel version, but I hope they take in these patches so that people don’t have to use custom kernels.
In our last episode, I talked about how I was planning to add support for SDHC cards to Linux, and I’m happy to report that Pierre has accepted my changes into his tree and pushed them out to -mm; hopefully they’ll be in mainline for 2.6.21.
Now, if you have any SD/MMC reader supported by the kernel, it will be able to grok SDHC cards. In theory, this also includes the shiny new Nokia N800 – although no one has recompiled a new kernel for it yet to verify this – I hope to get a hold of one in the near future to test for myself.
My next target is High Capacity MMC cards. These don’t have any fancy new branding like the SD ones do – and frankly, I think that to be a mistake as the compatibility story is equally convoluted – the only way to know for sure is if they are described as conforming to the MMC 4.2 spec. The changes to handle these cards are exactly equivalent to those for SDHC, and I have Samsung to thank for documenting that – given that there’s no 4.2 Application Note available from the MMCA. A small piece of reverse-engineering is required to work out where exactly the card capacity is stored under the new scheme, but that was always the easiest part to work out. Now I just have to get my hands on one of these cards!
Pierre is currently undertaking a major restructuring of the MMC subsystem so that we’re better placed to add support for SDIO and CE-ATA and I hope to help out with those efforts as I can.
When it comes to hardware support, we often find ourselves confronted with statements that such-and-such a piece of hardware can’t be used to its full capability under linux or feature ‘X’ isn’t supported yet. For a long time, the SD card reader in many recent laptops fell into that category but thanks to the efforts of Pierre Ossman, who managed to reverse engineer the SDHCI standard from trial-and-error and partial documentation, many of us are now able to use that reader. Although I can’t prove it, I feel that the subsequent publishing of the ‘simplified’ spec (without the DRM bits that we don’t care about) by the SD Association was provoked by his efforts (Why bother hiding it now?) Thanks to those specs, Pierre was able to polish the driver up even more and support a wider range of implementations (of course, there are some that are so out there that even having the SDHCI spec isn’t enough to get them working).
Now, one of the interesting things to fallout of Pierre’s work was that you could use MMC cards in these readers. SD is a fork of MMC and due to the nature of how the hardware works, it is essentially impossible to build a reader that can read SD but not read MMC (the key differences are at the protocol level). So, you ask, why doesn’t the windows driver support MMC cards in the drive? and why can’t my laptop’s BIOS boot from an MMC card in the drive? Well, I can’t speak for their exact motivations but the unquestionable part is that it requires *effort* to not support MMC. The conspiracy theorist may observe that both Microsoft and my laptop’s manufacturer (Toshiba) are both SD backers.
So, if you want to get the most out of your SDHCI reader, you’ve better be running Linux.
And to reinforce that point even further, my changes to support mmc 4.0/4.1 cards were accepted into the Linux kernel and will be present in 2.6.20. w00t! Thanks again to Pierre, wearing his hat as the new MMC subsystem maintainer. So now, not only will that same old SDHCI reader support MMC cards in Linux, it’ll be able to read and write to mmc 4 cards as fast as the hardware allows. And that’s pretty fast. On my laptop it’s a 4-fold increase. If we ever see an 8-bit wide SDHCI 2.0 controller, we’ll be able to make that even faster.
My next goal, and Pierre might beat me to it, is to add support for the new high capacity MMC and SD cards. The original standard uses byte-level addressing, which limits addressable capacity to 4GB – the new revisions (SD 2.0 and MMC 4.2) use block level addressing to access 2TB. Interestingly, the first generation of block addressable cards are 4GB in size – which seems slightly pointless as it introduces incompatibility without gaining anything. Anyway.
The SD literature on these cards (branded SDHC for SD High Capacity) says that they are not compatible with existing readers. While this is true for any reader with a fixed firmware (like most USB readers) and almost certainly true for poor Windows users, it will not stay true for Linux users with SDHCI or other direct-connected controllers – once we get support into the MMC subsystem, you’ll be able to stick these new cards into your existing reader and use them just as well as the old ones.
So, while there are times when using Linux means missing out on some capabilities of your hardware, there are others when it’s the only way to use it to its full potential. Now that’s pretty cool.
Have you ever wished you could test out ridiculously complex xinerama configurations, but didn’t have the hardware? Well, now you can.
Admittedly, that question isn’t going to be answered in the affirmative by many people, but I bet there are quite a few VMware users who wished that their VMs could run fullscreen and reflect their physical monitor configurations – and you can do that too.
I’ve just checked in support for virtual xinerama in the vmware video driver in Xorg and it will go out with the upcoming 7.2 release. Without additional integration into the actual VMware products (watch this space), you won’t get any automatic reflection of host configuration, but you can still manually configure a topology with a sample tool that I’ve included with the driver source. I’m also procrastinating about implementing support for defining a static configuration in xorg.conf.
You can get the new driver and the sample client from xorg git.
Also, most people probably know that keithp’s all-singing, all-dancing, xrandr++ is just round the corner, so don’t worry, I’ll be adding the driver hooks for that in the near future, which will let me deprecate our custom VMWARE_CTRL extension – but in the meantime, Xinerama support is useful and will continue to remain so (especially considering we want to be able to build a useful driver for older releases of Xorg).
One caveat is that there’s a limitation in existing VMware releases which will cause a crash if your frambuffer grows larger than 16MB. That’s a very large screen, but if you’re messing with xinerama, you’ll be more likely to hit it. As such, xinerama support defaults to off when run on this virtual hardware. You can turn it on from xorg.conf, but keep that limitation in mind.
So, one of my friends at work was complaining bitterly after I tricked him into installing 64bit Ubuntu on his shiny new xw9300. He knew flash wasn’t going to work, but wasn’t so enthused when he found he’s lost the ability to use copy-and-paste with VNC. He uses the vnc server extension – but that somehow managed to use long when it should have used CARD32 or something like that – so the vncconfig utility can’t talk to it. The real killer is that gdb is very broken with respect to 32bit programs and often can’t inspect variables on the stack. I believe he’s had other problems too and is imminently going to start again with the 32bit version.
I run 64bit Ubuntu on my work machine and it’s been pretty much problem free (although I am also led to hate gdb from time to time) but at home I would not be so foolish. Consequently, I’ve done things a little bit differently.
When I got my shiny new athlon x2 machine at the beginning of August, I knew I wasn’t going to just install a 64bit distro on it – there’s no official 64bit Slackware and I didn’t want to see flash and realplayer disappear, so I figured I start off with a 64bit kernel and then consider my options. After building a 64bit kernel in a VM (yay!), I was suitably unimpressed to see that the compatibility ioctl layer had enough holes in it that I couldn’t use the system properly (iptables refused to apply multi-port rules and hidd for bluetooth input devices just didn’t work). So I abandoned the idea for a while. Then a couple of weeks ago, I decided that I’d have a go at building a 64bit chroot to run the programs that had to be 64bit – and this has turned out to be a pretty effective way of dealing with the problem.
I took slamd64, the unofficial 64bit slackware, and installed its base into a directory and then used bind mounts to make /dev, /sys, /proc, etc available and then wrote a simple script to run stuff out of the chroot (not as fancy as the one recommended for Ubuntu/Debian), and then pointed the calls to the offending utilities at the chroot, and, somwhat amazingly, everything worked. I was particularly impressed to see my 64bit hidd working alongside the 32bit hcid and sdpd. I’ve also successfully run 64bit Unreal Tournament 2004 out of the chroot – which was rather nice.
I don’t think there’s anything particularly profound about any of this, but I find it interesting that the “page-in” approach to 64bit isn’t one that’s been used very much, if at all.
Thanks to the long weekend, I’ve finally had some time to look at my various little projects, and gphotofs is definitely one that’s needed some attention. I’ve had support for some useful command line parameters in svn for a while and I want to get that out to everyone, so I’ve cut a 0.3 release. It’s current available locally here but I hope it will be on the gphoto sourceforge page in due course.
One key use of these command line arguments is forcing gphotofs to use a directory as a fake loopback camera. This allows for testing gphotofs and the common part of libgphoto2 without worrying about device-specific quirks (such as my Canon being very troublesome after deleting files). I’ve also applied these changes to the experimental write-support branch so testing of that will be much easier for everyone (including me!).
To use the loopback configuration, do the following:
./gphotofs /some/mountpoint –port disk:/any/directory –camera “Mass Storage Camera”
For anyone who tries out gphotofs and runs into problems, please try and reproduce your problem in the loopback configuration. It will help us greately in narrowing down the cause of the problem.
Enjoy!
Well, that didn’t take too long. I’ve tagged and released Maemo Weather 0.7 with support for Maemo 2.0/IT2006. I can’t actually remember what 0.6 did, but the program now provides a radar map, details and a forecast for the selected location – so it’s feature equivalent to gweather in that respect. The next step is to extend it to support multiple locations, as was originally intended.
Two posts in one day, must be on a roll…
Marius Gedminas asked why my GWeather port wasn’t on the new Maemo Garage site and there isn’t a good reason, so I’ve rectified that situation. I’ve uploaded the current source to svn along with the necessary patches for IT2006/Maemo 2.0 support. Marius was able to get the home-page applet working – which I’d have trouble with, and his changes are in there too.
I still need to do a bit more testing and clean up on the home-page applet code before making the full 0.7 release.
I’ve also decided to rename the package from ‘gweather-maemo’ to ‘mweather’ (short for Maemo Weather) so that the naming is more consistent and less verbose. I’ll try and remember to add an ‘Obsoletes’ entry to the deb control file.