Skip to content

2

Sony Vaio Z21 News:

Some good stuff to talk about since the last weekend update. Lots of activity around Z21 support in the sony-laptop platform module, enough to publish an updated 0.8 release, which Eva has done already through the usual channel. A big update patch was posted on the linux-acpi mailing list, I took parts relevant to the sony-laptop platform module, merged them into our code, fixing some bugs in the way hotkey events were mapped to input events and pushed the fixes back to linux-acpi in order to keep upstream and our version better in sync.

A couple of new features supported now, mostly about wireless kill switch and hotkeys:

  • all hotkeys mapped to input events properly
  • better wireless kill switch support
  • compiles on 2.6.27 to 2.6.29

On special request I added a new load option to the module, if you insmod sony-laptop.ko with 'speed_stamina=3', the module will not touch the Nvidia graphics card power state any more. This is for people who need the Nvidia card so badly that booting through Windows is the lesser problem.

The Speed/Stamina switch now also reports ACPI events and I've found a way to read the switch position from the embedded controller, that means I can generate distinguishable ACPI events for either switch position.

Regarding enabling Speed mode I have been pointed to the "Nouveau" project which aims to provide a free replacement for proprietary Nvidia drivers. Maybe it's possible to reuse some code from this project to initialize the Nvidia card up to a state where a regular Xorg driver would be able to work with it. That sounds like major additional work, not sure I'll be able to do that on weekend time alone. The learning curve appears to be rather steep. However, since it's likely something that involves userspace code as well, it appears to me the correct way for now is just to report the switch position via ACPI and let userspace code handle the actual switching. Policies should not be hardcoded in kernel drivers anyway.

Digital Photography News:

After trying a Canon FD to µ4/3rds adapter from a Polish ebay seller and finding that it has got a couple of problems with infinity focusing and limits the available aperture stops to f/8, I tried to get a better version from a shop in China. It arrived on Friday a little more than a week after I ordered it and it's in a quite different arena regarding quality.

The Polish one is very simple, cut from just one block of aluminum on a CNC lathe. The adapter from China has a separate bayonet flange screwed to a CNC lathed body and also features an aperture control ring. It works correctly for all F stops and also allows infinity focusing. I'm very happy with it. I also got an almost mint 50mm f/1.4 lense for little money, including even a one year warranty against yet undiscovered defects. Both arrived in time before my easter holidays. I'll be going skiing in Italy, of course taking the camera and all lenses with me and hopefully finding enough time to enjoy both a lot.

30

Good news, I think. We've been able to switch off the Nvidia graphics adapter after booting Linux, which means it's possible now to boot directly into Linux and have X11 working with DRI and compositing enabled without the trip through booting into XP first.

It's quite a crude method, though. The hack with acpi_evaluate_object() I mentioned in my previous post worked, I just call the "_DSM" ACPI method of the built in Intel chipset graphics card and instruct it to call the "_OFF" ACPI method of the Nvidia card. I've also found out how to switch the Speed and Stamina LEDs so that you have some visual feedback of what's happening. You cannot see any difference in lcpci, which means that the card is still registered to the bus, apparently it's just powered down. I have no idea currently how to detach it entirely from the bus to reproduce exactly the configuration after having booted XP, maybe through PCI hotplugging? That being said, I have also no idea yet if the card is really powered down entirely.

My wife Eva has uploaded our experimental sony-laptop.c, grab it here. I don't make any guarantees about not damaging your precious toy if you dare trying it.

We're quite pleased with the current status however. It means that Eva can now shut down the laptop without having to make the stupid WinXP detour before using Linux again.

Her detailed log of installing openSUSE 11.1 on the Z21 can be found here.

1

Just as a quick update, we've tried yesterday to get access to the device specific methods of the both graphics cards through the WMI interface wrapper, but it failed. Some methods of the WMI wrapper work, but there's a stupid bug in the DSDT program that prevents executing the really interesting stuff. For the technically interested ones, this is the head of the 'WMMX' method in device WMI1:


Method (WMMX, 3, NotSerialized)
{
CreateDWordField (Arg2, Zero, FUNC)
...

Further down we find this:


If (LEqual (FUNC, 0x4D53445F))
{
CreateField (Arg2, Zero, 0x80, MUID)
CreateDWordField (Arg2, 0x10, REVI)
CreateDWordField (Arg2, 0x14, SFNC)
CreateDWordField (Arg2, 0x18, PARM)
If (LEqual (Arg1, 0x10))
{
Return (^^OVGA._DSM (MUID, REVI, SFNC, PARM))
}

This code block just splits Arg2 of method WMMX into sub arguments and calls the '_DSM' method of the built in graphics adapter. But there we find:


If (LNotEqual (Arg0, Buffer (0x10)
{
/* 0000 */ 0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D,
/* 0008 */ 0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4
}))
{
Store (0x80000002, RBUF)
Return (Local0)
}

So, the code in WMMX copies the first 128 bit of Arg2 into MUID, which in '_DSM' is compared to the byte array above. But wait, isn't FUNC also created by copying a DWORD from the start of Arg2? Hmmm. So, obviously the start of Arg2 cannot contain the function signature ('_DSM') and a MUID starting with 0xa0, 0xa0, 0x95 ... Consequently, every access to this method fails and just returns 0x80000002 to the caller. This part of the ACPI DSDT is just broken.

Now, obviously this is not the path Vista is using, unless they are replacing the original DSDT with something that works (and I cannot believe that). Maybe through a BIOS update? Does anybody know about graphics card related problems with Vista that are solved through a BIOS update? Or can some kind soul provide a DSDT dump while the system runs Vista?

Anyway, I'll continue my quest over the weekend, weather will not be good anyway. I think it should be possible to access the _DSM method of the chipset graphic card directly using its path, via acpi_evaluate_object(). We're going to try that next, stay tuned.

I'm making small progress with the graphics card problem. I've looked into the DSDT source code again and I think the key to switching the graphics adapters is a device called "WMI1", which has the PNP id "pnp0c14". I discovered that already a few days ago but when I tried talking to the device I could just not make the acpi driver register to it. Yesterday I was searching around in the acpi kernel drivers and I found a driver module "wmi.ko" which registers a driver to the very same PNP id. However, this driver doesn't do much on the Z21 but hogging the device. It's registering an event notifier and tries to find an embedded controller area, which is not present on the Z21 and so it does nothing useful. I think there's a DMI match missing, it should not register drivers blocking access to certain devices when it's unable to do anything useful with them.

(Update: After some more research I found that "WMI" reads as "Windows Management Instrumentation". wmi.ko is a wrapper driver allowing access to the WMI functions through ACPI. Now Sony seems to use, or rather abuse, the WMI interface to do other device specific functions as well.)

Walking the namespace of the "WMI1" device reveals that there is just one method, "WMMX", which basically acts as a wrapper to access the functions of both built in graphics adapters, "OVGA", the Intel GM45, and "DGPU", the Nvidia, and also methods of their respective output devices, "LCD", "CRT" and "DVI". I took a deep dive into the DSDT listing again and identified a couple of interesting things to try next. It's all very fascinating ...

1

I'm happy to report that my hack to the sony-laptop kernel module works. We were able yesterday to make the first UMTS data connection with my wifes' Z21, using HSOconnect on openSUSE 11.1. Her detailed description of installing openSUSE 11.1 on the Z21 can be found here, you can also download the source code of the sony-laptop.ko. It's a very rough first version, don't expect packages or inclusion into mainline kernels soon. Still, it gets you where you want.

Loading the module will generate a new file /sys/devices/platform/sony-laptop/snc_wwanpower, you can switch the modem power with "echo 1" and "echo 0".

I'm still working on the graphic card problem, hopefully I'll have a solution soon.

1

My wife urged me today to work on her new Sony Vaio Z21, which is, as anyone able to use Google will know, not particularly well supported by any recent Linux distribution. This is not exactly due to the completely fancy hardware components, rather by the completely undocumented methods of how to switch them on and off.

As an example, the Z21 has a builtin 3G modem, an Option Globetrotter, which is connected to an internal PCIe slot, which means it should just show up on the USB bus. Unfortunately it does not, not under Linux at least. The reason is that Sony chose to switch the modems power supply through an embedded controller chip on the motherboard. This embedded controller is nonstandard and therefore not managed through standard ACPI methods you would find under /proc/acpi, however there is a small kernel module, sony-laptop.ko, which provides an interface to some of the Sony proprietary device functions. The Z21 is unfortunately not supported yet by this module.

Well, it was not difficult to make the module detect the Z21, but the fun just started at this point: None of the functions provided by this module worked. Nada. Zero. OK. Turned out that while the Z21 contains the same "Sony Notebook Controller" as other Vaios, it did not react to any of the known ACPI method calls. So, I started looking deeper into the DSDT. I had never done that in depth before, but looking at the decompiled DSDT ASL, knowing that the DSDT is really not a table but rather byte code, it wasn't difficult to understand that the "SN07" method of "SNC" device was the key to switching the modem on and off. After traversing several levels of If/Else statements I found that calling "SN07" with 0x9f070803 as argument switches on the 3G modem, while 0x00000803 turns it off again.

Unfortunately this is not the end of the story. While the modem is now accessible via USB and even recognized by the hso.ko driver module, and even while we're able to talk AT commands via ttyHS0, we have yet to make the first data connection.

The biggest challenge will however be to understand the weird inner workings of the graphics adapters. The Z21 has two of them, an Intel GM45, and and some Nvidia with a name that I currently cannot remember. Under Vista you can dynamically switch between them, and unfortunately the BIOS lacks any preset, so when you cold boot into Linux, both of them are active which completey confuses the drivers and disables direct rendering. I know the answer is somewhere inside the DSDT devices and methods, but it's hard to understand this from reading the disassembled bytecode, without comments or sensible variable names.