Recently I became witness to a severe case of food mistreatment. I let my colleagues drag me into one of Darmstadt's fast food "shops", I dare not say "restaurant", Subways. Large international fast food franchise, you'll know them, there's likely one in your town as well. Stood in line, ordered some bread with chicken, salad, sauce. Watched the three stooges behind the counter prepare my meal and swore to never, ever return to that place. The way these people treated the food was unbearable to watch. I have never before seen such disrespect towards edibles, and consequently towards me as the customer buying them.
Of course it didn't taste good. Cold despite valiant efforts with a microwave oven, tasteless, boring, the bread dry like carpet dust and just as disgusting to eat.
Now, maybe the one I visited was just the one bad example, but for me that's the end of the story for good. I'm not opposed to fast food in principle, but there are just too few good ones to make it worth the effort searching. Subways? No Way!
26.2.09
14.2.09
Sony Vaio Z21 News: Switching off Nvidia card seems possible under Linux!
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.
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.
13.2.09
WMI is a dead end
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:
Further down we find this:
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:
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.
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.
11.2.09
Sony Vaio Z21 News
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 ...
(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 ...
8.2.09
Dissecting Panasonic RW2 files
I mentioned in an earlier post that I was intending to go to the bottom of certain rumors about Panasonic including lens defect correction data in the EXIF information of RW2 files. A number of commercial photo software programs are known to manipulate the RAW image data to remove geometry distortion, chromatic aberration and vignetting silently, which lead to enthusiastic reviews posted on certain digital photography sites about the quality of the Lumix G1 kit lens. However, I know from developing my RAW files with ufraw and digikam that the kit lense has a significant barrel distortion at short focal lengths.
One way to automatically correct those distortions is collecting correction data in a database like PTLens and Lensfun. The photo software knows what corrections to apply to images taken by a certain camera with a certain lens at a certain focal length. That approach however requires significant effort for maintaining the database plus you will always be playing catch up with the camera manufacturer developing new lenses. Not an issue for independent open source efforts, we've been running after information from vendors ever since, but not a good situation for the camera vendor. Unless he runs after the software companies to update their databases whenever he releases a new lens, images developed from his cameras RAW files will be not optimal. I would not want that, especially not if I wanted to reduce development cost and retail price for new products.
Panasonic most likely went the second way, which is having software makers implement the same correction algorithms they use in their cameras and embedding the necessary correction parameters inside the photos meta data. Doing it that way allows for lesser synchronization effort between Panasonic and software vendors and faster time to market. With some effort it might be possible to use this correction data also in open source software.
That being said, there's now a couple of tasks to be done until the correction data can be used:
Reverse engineering is a black box approach. In our case the camera is the black box, inputs are the controls like aperture, focal length, exposure program etc, output are the generated RW2 files. You cannot observe the inner workings of the black box other than by observing differences in the output when making modifications to the input. It definitely helps if you can make an educated guess about the inner workings of the black box. For geometry correction, I know a bit about how its corrected, so that is my first target.
I know that geometry distortion depends on the focal length, so I made a couple of shots with the kit lens at 14mm and 45mm, two at each. Then I looked at the Exif data and found one tag, "Exif.PanasonicRaw.0x0119", where the data did not change for images taken at 14mm, but changed significantly when going to 45mm.
14mm:
45mm:
35mm:
The next task is now to find out how the data is formatted. Most likely these parameters are rational numbers. What I don't know yet is the representation. Is it 16, 32 or 64 bit per coefficient? Am I looking at fixed or floating point numbers, little or big endian? Does this tag only contain correction parameters for geometry, or also for chromatic aberration? The tag contains 32 bytes, so it's either 16, 8, or 4 coefficients. I'll have to do some research on geometry correction, maybe Panasonic uses something that is public domain.
It looks like a prominent method of correcting lens geometry is based on Zernike polynomials. The PanoTools lens model uses polynomials as well. One property of polynomials is that you can use as many parameters as you like, it just depends on the order of the polynomial. It's merely a question of computing power available. I could start with a 2nd or 4th order polynomial like the PanoTools model and try to match the tag information with coefficients computed by Hugin.
One way to automatically correct those distortions is collecting correction data in a database like PTLens and Lensfun. The photo software knows what corrections to apply to images taken by a certain camera with a certain lens at a certain focal length. That approach however requires significant effort for maintaining the database plus you will always be playing catch up with the camera manufacturer developing new lenses. Not an issue for independent open source efforts, we've been running after information from vendors ever since, but not a good situation for the camera vendor. Unless he runs after the software companies to update their databases whenever he releases a new lens, images developed from his cameras RAW files will be not optimal. I would not want that, especially not if I wanted to reduce development cost and retail price for new products.
Panasonic most likely went the second way, which is having software makers implement the same correction algorithms they use in their cameras and embedding the necessary correction parameters inside the photos meta data. Doing it that way allows for lesser synchronization effort between Panasonic and software vendors and faster time to market. With some effort it might be possible to use this correction data also in open source software.
That being said, there's now a couple of tasks to be done until the correction data can be used:
- find out what information is stored, and where
- reverse engineer the format of the correction parameters
- understand how it's applied to image data
- proof of concept implementation
Reverse engineering is a black box approach. In our case the camera is the black box, inputs are the controls like aperture, focal length, exposure program etc, output are the generated RW2 files. You cannot observe the inner workings of the black box other than by observing differences in the output when making modifications to the input. It definitely helps if you can make an educated guess about the inner workings of the black box. For geometry correction, I know a bit about how its corrected, so that is my first target.
I know that geometry distortion depends on the focal length, so I made a couple of shots with the kit lens at 14mm and 45mm, two at each. Then I looked at the Exif data and found one tag, "Exif.PanasonicRaw.0x0119", where the data did not change for images taken at 14mm, but changed significantly when going to 45mm.
14mm:
84 236 201 47 38 0 0 0 43 1 0 0 141 1 1 0 208 14 238 1 86 2 2 252 196 9 226 3 228 72 36 13445mm:
152 94 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 86 2 0 0 196 9 0 0 35 234 24 15535mm:
161 54 43 194 51 0 0 0 0 0 0 0 0 0 1 0 42 0 1 0 86 2 1 0 196 9 245 1 176 16 17 65The next task is now to find out how the data is formatted. Most likely these parameters are rational numbers. What I don't know yet is the representation. Is it 16, 32 or 64 bit per coefficient? Am I looking at fixed or floating point numbers, little or big endian? Does this tag only contain correction parameters for geometry, or also for chromatic aberration? The tag contains 32 bytes, so it's either 16, 8, or 4 coefficients. I'll have to do some research on geometry correction, maybe Panasonic uses something that is public domain.
It looks like a prominent method of correcting lens geometry is based on Zernike polynomials. The PanoTools lens model uses polynomials as well. One property of polynomials is that you can use as many parameters as you like, it just depends on the order of the polynomial. It's merely a question of computing power available. I could start with a 2nd or 4th order polynomial like the PanoTools model and try to match the tag information with coefficients computed by Hugin.
Success: Sony Vaio VGN-Z21 3G modem with Linux!
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.
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.2.09
Sony Vaio Z21 DSDT fun
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.
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.
Subscribe to:
Posts (Atom)