maemo.org - Talk - [MADDE] It all started with a black screen...

I want to tell you a tale, one about the fun you can have if you stick to a task to the bitter end.

My storry begins with the purchase of a N900 on Ebay, which led to a significan waiting time, and so I got the Idea, lets develop an App for it with Qt.

After hours of tring to find the right SDK/Toolkit/Planet I fount the NokiaQtSDK, which seemed to be just right for the job, and it even got a N900 Emulator!.

This N900 Emulator ( MADDE ) seemed pretty easy to use, so i decided to give it a try, and it Worked! after about 20 hours of research and tears >.<

Now lets short the storry a bit,
I got the following table of configurations:

Ubuntu Lucid - Ratpoison - Netbook Atom Cpu/Intel graphics
Ubuntu Lucid - Ratpoison - Netbook Atom Cpu/Intel graphics
Ubuntu Lucid - Ratpoison - Desktop Atom Cpu/Nvidia ION
Ubuntu Lucid Server - / - Desktop AMD/ATI

All x86, no other major differences, but on the First it worked and not on the others

I tried The MADDE included in the NokiaQtSDK and the latest MADDE standalone package, so those qemu arm installations and i compiled my own qemu-arm to make sure it wasn't the problem, Also i tried all Targets and Runtimes in every possible constelation, and even ported the working setup 1:1 to another computer.

So finaly I gave up trying to search for different solutions and looked into the Emulation, I could always ssh into it and it was showing me the bootsplash, after that the screen remainded black.

First i thought it was a qemu problem displaying the grpahics, but later i luckily found fb-progress and managed to set the screen to another color, which told me that the graphical output was working fine.

Then I inspected the Xorg logs, and found that it was waiting for hal, to infinity.
Looking at the Process list I found hal not to be running, and started it via /etc/init.d/hal start. a few seconds after that my ssh was disconnected and the vm didn't respond anymore. I tried it again and again it went down.
So I started hal by hand and looked at the output, heres a small excerpt:

Quote:

process 935: arguments to dbus_set_error_from_message() were incorrect, assertion "(error) == NULL || !dbus_error_is_set ((error))" failed in file dbus-message.c line 3265.
This is normally a bug in some application using the D-Bus library.
22:19:31.979 [E] hald_dbus.c:3507: Error calling DeviceAdded for /org/freedesktop/Hal/devices/platform_cmt_wddis on singleton: dG*AX:
process 939: [953]: 22:19:32.124 [D] addon-cpufreq.c:1053: Received DBus message with member Disconnected
Segmentation fault

So hal was shooting down dbus, which resulted in everything going down. Now I got stuck at trying to figure out what was going wrong with dbus, and wich dsme, but that was the wrong way. I later again stumbled over the hal log and saw something that was interresting, the keyword "GPIO".

While initializing the GPIO hardware, by moving the files

Quote:

/usr/share/hal/fdi/policy/10osvendor/10-omap-gpio.fdi
/usr/lib/hal/hald-addon-omap-gpio

I took hal the possibility to initialize it and after a reboot, voila there it is, a graphical envirovement, fully booting!

Regarding the purpose of GPIO it makes sense something can crash at this, but I can't find a rational explanation for the fact this is only happening on my machines...

For now I resigned on figuring out what caused all that, and see it as a way of the universe to mess with me.

For those who read that far, thanks for the attention.