As I've posted today to openmoko-kernel, there have been some quite significant power savings during the "backlight off but still not suspended yet" operational mode of the GTA02. The power savings are in the order of 49%, which is really massive, particularly for applications that run in the background while the screen is blanked, like typical mp3/ogg player applications.

It is sad to me that something like this is found long after the GTA02 has actually shipped. It seems like there are still fairly low-hanging fruit around to do some significant power saving.

Since all the measurements can be done on the device itself, using the built-in high precision coulomb counter of the battery, everyone is able to do the measurements without any special equipment. It also means that power management related issues can be tested automatically.

I would love to see somebody working on software that switches certain hardware on (and off) again or cycles through various differnent power states of every hardware unit an then reads the power consumption. The resulting readings can then be manually checked if they're consistent with expectations based on the hardware design. Furthermore, this program could be used for regression testing against new uboot/kernel/OS releases in order to ensure we don't get into power consumption regressions.

It's an interesting feeling to spend some days working full-time on Openmoko again. Swisscom was stating a number of high-priority bugs (for them) which I tried to resolve.

The first two are u-boot related, namely: get GSM passthrough working again, and fix USB DFU Upload on GTA02. Those two should be doing quite fine now.

I've also been investigating possible ways to optimize CPU usage of frameworkd, although it is not yet clear which of the possible solutions should be implemented in the end

Right now I'm working on some power management related issues, mostly glamo/backlight/LCM related, as well as re-investigating the hardware-ECC work by Zecke.

However, after a significant break from _using_ the Openmoko devices and the software available for them for a number of months, I have to say that the overall experience was really disappointing.

• Whatever Openmoko builds as their daily builds available on downloads.openmoko.org is the most unintuitive UI that I've ever seen (is that ASU?). After some attempts, I gave up. unusable for me.
• FSO images can be installed, but are incredibly slow
• Documentation in either openmoko wiki or FSO wiki is horribly outdated
• It's _really_ hard to get devirginator running since lowlevel_foo and others are not available on downloads.openmoko.org, but devirginator insists on downloading them from a website rather than copying them from a local directory
• there's a neverending fragmentation
• core aspects of the system level have not been addressed, like replacing sysvinit with something like upstart, some serious boot speed optimizations and various power management related bits
• Nobody has yet had the time and resources to investigate a thorough, flexible and performant storage and API subsystem for contact + related data

All this makes me really sad and gets me back to the point where I feel like when I left OpenMoko, Inc. last year: Too many insurmountable problems, and very few that can be addressed in a way that they are solved once and forever. Everyone runs their own personal little pet system, magic scripts, revision control system, overlay files, images, etc. Still too many people think OE is a tool to develop+crosscompile application programs.

I'm back to Switzerland for some Swisscom related work. Right now I'm sitting in the Intercity train between Zurich and Bern. And believe it or not: Half of the car is occupied by (loud) Hindi speaking Indian tourists ;)

It really feels like I'm in a Bollywood movie. Indians in Switzerland. And not only in Switzerland, but in the Train. Couldn't be any more cliche ;)

In Berlin there are not many chances to watch a Bollywood movie in an actual cinema. Those few movies that they show, I usually try to watch, at least if I'm in town. So far they've always made a great selection and picked only blockbuster movies that actually were any good.

Since I haven't been staying up-to-date with the latest Bollywood releases (mostly due to time constraints and lack of access to Indian DVD's in Taiwan), I didn't even check about the background of the latest movie they've started to show here: Drona.

After watching the first five to ten minutes of the film, it became already clear to me that I should have done better and check beforehand. Never seen such a trashy movie before. What a disappointment.

Some of you might remember the famous blinkenlights installations of the CCC in Berlin at Alexanderplatz some years back. Basically they used a matrix of windows on a building for a low-resolution display to play pong and display all kinds of animations and text.

After a long break, they're back, even bigger with blinkenlights stereoscope, a massive installation spanning 960 windows of Toronto City Hall. The entire backend technology has been re-implemented based on OpenBeacon , specifically the WMCU and the WDIM units.

I'm currently at the netfilter workshop 2008 in Paris, France.

It's always sort-of a mixed experience for me. Obviously it's great to spend some time with all the great hackers who work on various aspects of netfilter/iptables (and now finally also its successor that is so-far called nftables). On the other hand, it's been about three years since I last actively contributed code to netfilter, which makes me sad. I'm still excited about it and have many ideas that I'd love to implement. But where to find the time for it?

Today, while reading IT mainstream magazine "c't", I stumbled across an article about GSM deployments (and popularity) all over Africa.

One of the interesting things in that article was that one Operator had modified their network in a way to only use four timeslots (out of the eight available timeslots) per frequency in order to extend the range of a single cell to something like 70 kilometers.

For those who are not as familiar with the GSM Um air interface: It uses TDMA (multiple devices each get one timeslot on a given frequency). So let's assume we have eight timeslots on one frequency, all the transmitters (handsets) need to be synchronized with regard to that timeslot. Radio travels at speed of light and not with infinite speed. Therefore, since the handsets can be at a lot of distance to the receiver (base station), they might send in the correct timeslot, but the signal arrives out of the timeslot. GSM uses what's called "timing advance" in order to compensate for that effect. The base station tells the handset how much time earlier than the actual timeslot it needs to transmit to ensure arrival within the timeslot.

Now in that African GSM network in question, it seems like even the maximum timing advance is not sufficient. The frame still arrives late, i.e. in the next timeslot. By allocating only every second timeslot, there cannot be any clash and thus the range of a single cell can be extended. This is actually a very cool idea, I would almost call it a "hack", and it is possible within the GSM spec without requiring any change to existing mobile phones!

I only wonder how much of such cool hacks we would see if GSM base stations were more open and available. If there was a full FOSS stack that many people could use on off-the-shelf hardware, it would lead to a lot more innovative experiments and thus innovation. There would suddenly be more than a handful of GSM experts with access to proprietary technology looking at what kind of good, useful, cool and/or creative things one can do...

I've been invited to be the keynote speaker of the joint NLUUG autumn conference and Embedded Linux Conference Europe.

It is a great honor to me to be the keynote speaker, and I will certainly use this chance to provide some of my insights into Embedded Linux. I feel confident to have a thorough understanding about the market (and it's many problems) due to

• having a strong, 14 year FOSS community developer background
• knowing how hard it is to do FOSS-only embedded hardware development (for OpenPCD, OpenBeacon, Openmoko, ...) in todays secretive hardware industry
• having seen a wider range of embedded Linux products than most other people by reverse engineering hundreds of devices for gpl-violations.org
• and now even knowing the chip maker perspective, after becoming VIA's Open Source Liaison

So I'm trying to point out the various problems I see in the Embedded Linux world, and how they can be addressed.

If I know you and you're planning to attend the conference: Please drop me an e-mail in advance so we can meet up, chat, have drinks, meet for dinner or the like.

For quite some time there has been a project called Wireless3G4Free. I suspect it is little known outside a certain academic community. So what is it all about? Creating a FOSS based test platform for wireless 3G systems. Yes, this is the so-called baseband side. The parts that are usually very carefully locked away in the proprietary stack of cellular handsets and other equipments

Even though the project, funded by the European union and implemented at EURECOM in France, is 'finished', it is not as easy as to just use that software and get UMTS connectivity.

First of all, it implements the 3.84MChip/s TDD variant of the physical layer (layer 1), whereas most commercially deployed UMTS systems for cellular access use the FDD variant. For those not as familiar with 3G technology: There's three different layer 1 options: the 3.84MChip/s TDD, the low-chip-rate Chinese TDD variant, and the FDD variant. The layer 1 is separated in two parts, one that is TDD/FDD independent, and the other part that is shared.

Secondly, the Wireless3G4Free project uses IP on the layer 3, as opposed to the actual layer 3 protocol of UMTS (which borrows a lot from the layer 3 protocol for GSM, which in turn borrows a lot from Q.931 / Euro-ISDN).

So if one was to make that code interoperate with UMTS cellular networks, the lower half of layer 1 need to be rewritten for FDD, and layer 3 needs to be implemented.

What is exciting about 3G compared to GSM: GSM uses proprietary ciphers (A5/1, A5/2) for the actual air interface. Those ciphers have leaked quite some time ago, and they're no longer secret (and thus the GSM security is no longer existing), but still people are not supposed to know how it works.

In the 3G world, the corresponding cipher is public. This means that in theory, it should be possible to implement everything in Free Software based on publicly known information. Yes, it is a lot of work. But it definitely can be done.

Before actually using this on any official network, it would obviously need to be certified. Certification for this kind of protocol is a time-consuming and expensive process. It requires development cycles of going to a certified test lab, obtaining test results, going back to actually fixing the problems, re-running the test lab tests, and so on. Nevertheless, Free Software has already proven that this can be done. The isdn4linux project did a full EDSS1 certification some 10 years ago. ELSA, a maker of passive ISDN cards, sponsored that effort. And if you used an unmodified code version, then you were certified. As soon as the source code was changed, you were running an uncertified version. I don't see any big problem why the same scheme should not work for a 3G baseband software stack.

One important question though, is the question of hardware. None of the existing commercial vendors of 3G chipsets will ever provide you with the hardware documentation that you would need or want to run that kind of code on their hardware. It is their business to sell their proprietary 3G stack along with their chip, so they would only loose money if there was any FOSS implementation in competition.

Sure, you can use something like the USRP or USRP2 or any other software defined radio platform. But while that would be ok for a proof-of-concept, it is too large, expensive and power-consuming to be used or 'ported' to any actual handset-type product.

So any possible real-world plan of making this happen would probably go as far as to implement everything based on the USRP, then have a proof-of-concept prototype and then do a modem design based on existing, openly documented RF components and ADC as well as DSP+Processor combination that is suitable for low-power operation.

Sure, I'm just daydreaming. But sometimes you have to dare to dream in order to make things happen. Anyone wanting to turn this idea into a business, let me know ;)

I've had the honor to join other experienced FOSS hackers on the Jury for the Hackontest. The idea was to let the community collect a number of work-items for teams (of 3 developers) working on a particular project, then pick some of those work items and see how far each team gets within 24 hours.

I think it was a very interesting concept. Something that at least I have not yet seen anywhere else before. The organizers did a great job with the preparation. Setting up the website for project proposals, collecting community votes on the individual tasks, putting together the jury.

The participants of the contest then were placed into a container (yes, the kind of containers used for international shipping) with a fridge, beer, snacks, Internet, power, a projector and some other gear. They had vnc running on all of their systems, to enable a large public screen at the trade show where people would be able to follow whatever happens on-screen right now on a system of a random developer participating in the context. 'reality-tv for hackers' ;)

The results and the progress were quite different between the individual projects. I don't want to reveal the internal discussions we had in the jury, but one thing that basically everyone agreed to was the improper use of revision control systems. None of the teams was setting a good example on how to use them. Either the granularity of the commits, or the changelog texts, or the time when they committed was wrong. You shouldn't commit unrelated changes, never do cosmetic and functional changes in one commit, etc. This is what makes your work reproducible, readable and understandable to others, like the jury and particularly your own user and developer community. It is one aspect that affects a lot how easy it is for others to contribute to your project or to contribute to it.

At OpenExpo, Swisscom Research had it's own small stand (wouldn't call it a booth) to demonstrate thei research and evaluation work based on Openmoko. This is definitely exciting news, first of all since it is the research department of an established carrier, i.e. Openmoko is considered seriously even by them.

Secondly, they have many interesting ideas, some of which they have implemented. They have created a much more simplified UI, as well as an interesting input method based on gesture recognition. They've also been working on some crypto and security related bits.

I can now also disclose the fact that both Rasterman and myself have been (and stilll are) providing a bit of consulting and R&D services for Swisscom.

During the least couple of days I've had some pretty intense conversations with a number of people on various aspects of GSM, leading me to [re]reading some of the interesting bits of its specification.

There are a number of observations that I don't want to talk about right now, and which will likely be part of my work during the next couple of months.

One thing that ever so often gives me the creeps is STK (Sim Toolkit). To those people involved with GSM, it is no news that with STK an operator can basically remote-control your phone. He can, among other things

• make your phone send SMS
• initiate outgoing calls without your interaction
• initiate outgoing calls and terminate any existing call
• open data connections (GPRS/EDGE)
• launch a browser to any URL
• play tones on your speaker
• access and modify any information (contact, SMS, dial history, even IMSI) stored on the SIM

And the worst thing of it all: You don't even know which of those features your phone implements (most likely all of them). I'm happy to still use a SIM that predates the GSM11.14 (STK) specification.

Now in the advent of projects like OpenBTS, where we can emulate a GSM network side, and in combination with either supplying your own SIM card (or emulating it using a PC), we will finally see a faint possibility of actually testing (and demoing) the never-ending security nightmares caused by this evil monstrosity.

I've just arrived in Winterthur (Switzerland) for OpenExpo where I will present on the various reasons and implications of the fact that 99.9% of the makers of commercial embedded Linux products have not understood the slightest bit about Embedded Linux or rather, embedded FOSS in general.

Those people who've ever tried to exercise their freedom to create and run modified versions of an embedded product with pre-installed Linux will definitely know what I'm talking about.

Today I've posted some patches that add SD/MMC card support to GNU parted, including libparted. It's actually just support for auto-detecting the /dev/mmcblk* devices, since the actual partitioning and block layer access of SD storage cards is exactly the same like on any other disk.

This has been fun, as I always like to read source code of programs that I've only been using so far ;). Luckily, the architecture is nice and abstract so the feature was easy to implement.

After the copyright assignment to the FSF has been done, the code will get merged. Once libparted has support for this, debian-installer should more or less automatically offer those devices as installation targets.

Now I just have to find out what the other distributions use for this purpose, with some luck they also rely on libparted and I don't have to implement this feature 5 times.

It seems like boot-from-SD is about to become as standard in the x86 world as boot-from-USB currently is. This is generally good news. Also, the need for OS integration is minimal, as it just uses the usual BIOS ABI on doing disk reads.

However, the initrd's shipped by all distributions don't contain the SDHCI driver, and all the installers that I've seen don't support installation on /dev/mmcblk*

I've now filed bugs for all the major distributions about this issue, and you can find more information at this wiki page on installing Linux on a bootable SD card. Let's hope that the distro's consider this feature important enough to add support to it to their next releases to make sure at the time the users buy this kind of hardware they can install the then-existing versions of those distributions.

The last two days I was busy preparing a patchset with various updates against the linux-2.6/sound/pci/hda/patch_via.c driver for HDA Codecs.

The resulting patchset has now been posted at alsa-devel and I'm waiting for the fallout from that.

The other bit that I'm currently playing is boot-from-SDcard support, apparently a feature that major BIOS vendors have in their new releases and which will become more common with upcoming mainboards and laptop devices, just like boot-from-USB in the past.

There have been numerous questions regarding the recent open source release of VIA's 2D Xorg driver.

Why did VIA publish yet another driver, rather than improving any of the existing Xorg/openchrome/unichrome drivers?
Because this driver is all but new! It was the base for all the binary-only driver releases that VIA has made (and is still making) for select Linux distributions. So rather than having written a new driver, this is just the disclosure of an existing driver.

One of the commonly asked questions is _why_ not the complete source, including codec acceleration, TV out and 3D was published. I cannot disclose the particular reasons for VIA, sorry. But I can comment on the general reasons on why companies cannot disclose certain source code. As you may have noticed, the situation with regard to the ATI driver e.g. shows certain similarities.... Usually there are some parts of the code, particularly for the 3D driver, which cannot be disclosed due to either

• parts of the source code are under a proprietary license from a 3rd party
• parts of the source code refer to technologies (e.g. macrovision) which are subject to very strong NDA's by the licensor, which in turn prohibit the open documentation or distribution in source code form

Will VIA learn to build a community around that new driver? Will there be mailing lists and a public revision control system?
As of now, this is unlikely. Not because VIA doesn't believe in the community, but rather because the disclose of VIA's source now enables everyone involved to look at all the available drivers. Some consensus has to be found on which driver is best to be used as a base for a future Xorg mainline driver, and then the community and VIA can work together on merging bits from other drivers into that base. Creating VIA's own mailing lists (and community) would lead to more fragmentation, rather than unification.

Heh. You could say I'm now among other things a professional hardware reverse engineer. This mostly started as a kid, where I always had to take everything apart. In more recent years, I've mostly been doing hardware reverse engineering as part of the gpl-violations.org effort, or projects like openezx.osmocom.org.

Now, I've actually been asked by a company to buy a device on their expense to disassemble and photograph it, to find out about the components it uses, etc. And no, before you start to wonder, I don't work for Openmoko anymore. So they are not that company ;)

The device in question is the E-TEN glofiish X800, a full-vga 3.5G Windows Mobile PDA-Phone with AGPS, Wifi and bluetooth. You can find the pictures of the disassembly process and PCB photographs here.

As you can see, the device employs the following major components / chipsets:

• Samsung S3C2442B SoC with integrated SDRAM and NAND (same like Openmoko GTA02)
• CSR4 based Bluetooth (same like Openmoko and many other devices)
• microSD slot, must be connected to S3C2442 SD/MMC controller
• WiFi Module using a Marvell 8686 chipset (you actually can't see that, I had to peel open the shielding of the module and the angle didn't allow any good photographs)
• TD028TTEC1 LCD module, exactly the same as the OpenMoko GTA01/GTA02
• AKM 4641 audio codec, reportedly used in HP iPAQ and HTC Universal
• Two cameras of unknown type, must be using the S3C2442 camera interface
• Ericsson based quad-band GSM and tri-band 3.5G chipset centered around the DB3150, which is used in many Sony-Ericcson 3G/3.5G phones. Sony-Ericsson has excellent public documentation on their AT-commandset for their phones. Since they are likely to use the same firmware base, the AT commandset should thus be known.
• A Xilinx CPLD

So now what does all this mean? Setting aside the CPLD and the unknown camera modules, this device (and its keyboard-enabled brother the M800) should be a very attractive target for porting Linux to it. Known SoC, wifi with driver already in mainline, GSM/3.5G modem with documented AT commands, etc.

Big question is the power management. It looks like they're using a lot of discrete regulators rather than an integrated PMU. Also, the CPLD is likely to cause a lot of trouble since neither the external connection nor the internal logic is known...

VIA has just released a open source Xorg driver for their integrated graphics chips on their linux.via.com.tw portal. Here's the actual download link for the source code tarball.

I am very happy to see this! It's one more step that VIA has been working on to improve and show their support for Free Software and Linux.

Please notice that this driver (as opposed to VIA's proprietary binary-only Xorg driver) has no support for 3D, hardware video codec or TV encoder support. Nevertheless, it is a big step ahead.

Of course everyone involved understands that this simple "code drop" is not enough and that it is just the first step for actual 'Free Software integration'. There is a lot to be done to harmonize the current FOSS driver landscape for VIA's graphics products, from the old via driver in the Xorg git tree, over the unichrome and openchrome and now this new driver. Stay tuned!

I've just arrived in Taipei two days ago. I'm looking forward to an exciting four weeks of close work with VIA, talking with various different groups in management as well as actual software engineers.

I can only repeat my earlier statements: It still feels great to be able to play such a substantial role in improving the Free Software interaction of a large chip maker and key player in the PC industry.

Of course being in Taipei also enables me to meet again with former colleagues at OpenMoko. I just returned from a very nice dinner conversation with jserv.

The German business newspaper Financial Times Deutschland has published an article about my GPL enforcement work. To the best of my knowledge, it is the first such article in a general newspaper. All previous coverage was in publications or magazines tailored to the IT industry.

However, the content is of very low quality, and the actual facts are wrong in a number of cases. First of all, why go to a personal level and describe myself as having a 'Harry Potter hairstyle', and then calling me "a mixture between bill gates and a heavy-metal fan". I hereby deny any similarity with Bill Gates. I had my hair style like this even in the nineties (before growing it long around 1997-2000 and then cutting it again in 2001). And I listen to a lot of weird music, though heavy metal is generally not on my playlist. Anyway, what is the point of all of that? How does this help people to evaluate the risk of GPL violations?

Further down, the article has claims like "the driver software of the router also contained some lines of code that were originally written by Welte". First of all, it is the firmware, not the driver. Secondly, it is more than a couple of lines (since a couple of lines would probably not constitute a copyrightable work).

The article also explicitly states that I am not fighting for money, but "out of principle". Despite that, it also claims "The first couple of companies are shivering expecting the destruction of their book value". That's illogical.

Furthermore, there are claims that I have focused on companies that only used small amount of open source. To the contrary: The majority of the products that I've enforced so far contain 75% or more open source software. Only small portions were added by the respective vendors.

To the contrary, there was a recent article in the Berliner Morgenpost paper one of the CCC Leaders which was really well-researched and of high quality. Even that one gets some minor facts wrong, but still portrays a realistic picture.

Today I found out about this years schedule for 1654 THE CAVE.
Today it will happen.
And I'm even going to be in the right part of Germany.

The best coincidence of this year.

I know there are many curious readers about what is happening at VIA with regard to Free Software. There are many things that I cannot talk about, but I can still state how excited I am by my new role, and how many (some big, some mall) steps I have managed to make during the short time that I'm working with VIA now.

The last week was mainly talking to various FOSS developers that have written or are maintaining existing Linux drivers for VIA hardware, like Ethernet, I2C, SATA/RAID, AGP, DRM/DRI and others. I have been able to provide hardware reference manuals that some of them have been trying to get their hands on for a long time (even willing to sing and NDA). VIA has also starting to offer reference hardware to selected Linux developers.

I'll be back to Taipei in roughly three weeks (August 21st) and am looking forward to the many interactions with Product Managers and Developers. Meanwhile, I'll continue to have conf calls at weird times and sending tons of emails back and forth, trying to establish the right contacts, getting the right people to talk to each other, etc.

So far I have resisted the temptation to touch a lot of the code. But I think I will not be able to resist very long ;) Right now I just don't want to step onto anyones toes (and/or duplicate work), no matter whether in the community or inside VIA.

Yesterday was the last day of OLS 2008. In fact, the last day of OLS in general, since from next year on, it will no longer be in Ottawa, but Montreal.

2008 marked the 10-year anniversary for OLS. Impressive. I have missed at least the first one (1999). I'm not sure if I started with the 2000 or the 2001 incarnation. Most likely 2000, since that was about the time I got heavily involved with netfilter.

I had the honor to be mentioned in the 10-year-anniversary talk in a reference to my fashion style (wearing skirts/kilts at earlier OLS's). If I only had known, I might have brought and worn it again ;)

As for the conference itself: I don't want to follow all the various people who have been voicing their discontempt with recent incarnations of OLS. Sure, due to the advent of the kernel summit, the UKUUG linux developer conference, linux.conf.au, the Linux plumbers conference and other events there now is more 'competition' to attract the Linux celebrities. However, most people should not be attending a conference like it was some kind of fan club. There are still quite many people at OLS who actually _do_ a lot of die-hard Linux development work. And those poeple have interesting things to say, and it's interesting to share ideas with them. OLS is pretty much a conference where mainline developers can talk to other mainline developers. It's not an event directed at users, and not an event directed at non-participatory 'consumers' of Linux like many commercial embedded vendors.

So after all, I have to say that the conference was a success and I'd be happy to attend it's future incarnations. Hopefully with my own paper and presentation.

There is one thing, though, that upset me a lot: At the closing ceremony, there was something like a lottery for a handful of Linux-based devices. Among those devices was the Motorola ROKR2 V8. For those of you who don't know: This is a device where the vendor chose to remove your freedom to 'run modified versions of the program'. It will not boot any non-signed bootloader, kernel or executables. And the user is locked out of his own device by means of SELinux. I think it is a grave insult to the Linxu developer community that something like that was chosen by both organizers and sponsors.

Today, VIA made public what I've already been doing behind the scenes for some time: I've been contracted and appointed to be VIA's Open Source Liaison. As first part of the process, they've released the Padlock programming guide and the CX700/VX700 integrated north+southbridge manuals on linux.via.com.tw.

This basically means that I'll be helping VIA with improving their strategy for Open Source support, such as Open Source driver support, merging those drivers into the respective mainline projects as well as working on publicly available reference documentation for their hardware.

This is an incredible chance to contribute my part to help a major manufacturer of CPU, Chipset, Ethernet, WiFi, Card Reader and PC Graphics components understand what it takes to interact properly with the Free Software community. This is a big learning experience for VIA, and a teaching experience on my part, of course. I feel very happy to be able to work in such a key position, and to be able to put all my knowledge about Linux driver development, the development process, the FOSS community values/ethics/practises as well as licensing related knowledge at work.

VIA is truly interested to learn, and they're already doing a lot internally which you might not have been aware about. I am well aware of many of the historic problems between VIA and the community, related to binary only drivers, not cooperating with mainline development, suboptimal press announcements with little action, etc.

I'm very confident that together we can move beyond this and take a fresh start for much better FOSS support of VIA products. Of course the change will not come overnight. It's a process, and it involves many groups in a large company, each group with their own management, R&D and so on. So please bear with us, and don't expect all drivers to be finished in mainline quality tomorrow.

If you are a Free Software developer and you have some comment/feedback/demand to via, please feel free to contact me (preferably at HaraldWelte@viatech.com. I will try my best to follow-up with all those comments. If you are missing some piece of documentation for hardware or have some other issue, please let me know. I do care, and I will take up the issue with VIA's management.