I'm seeing the same problem as reported here:
http://icculus.org/pipermail/openbox/2009-January/005987.html
I am running qemu with a x86_64 Fedora 12 host and a i386 Debian Lenny guest with 24 bit video (which is default).
If I add "DefaultDepth 16" to the qemu guest's xorg.conf things work fine. Without this, openbox starts, but if you click on the desktop it immediately crashes with:
ObRender-ERROR **: Your bit depth is currently unhandled
Thanks!
Hello,
I can reproduce this bug.
I got here from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545031
I use Debian Lenny with kvm as host.
Host versions:
kvm 72+dfsg-5~lenny5
qemu 0.9.1-10lenny1
I use Debian Squeeze (testing) as kvm guest.
Guest versions:
lxde 0.5.0-4
openbox 3.4.11.1-1
The error message in .xsession-errors (guest) is an endlessly repeated:
> ObRender-ERROR **: Your bit depth is currently unhandled
>
> aborting...
>
It makes no difference if I
- let kvm show the display directly (in an X11 window) or
- connect to the guest display via vnc.
No special setup is needed to reproduce the bug. I can log in, but as soon as I open a window (browser, filemanager, lxde-tip, does not matter) I get a blinking screen, no window decorators, the error messages, and an ever increasing openbox pid.
I hope this helps. It would be neat if this could be fixed in the to-be-released debian squeeze. Tell me if you need more information.
Thanks,
Wolfgang
Hello,
I forgot to say in my previous comment that I logged in to lxde, which uses openbox. I used gdm to log in. But you probably already guessed that due to my version information.
I also tried Ubuntu 10.04 as kvm guest (with the same host).
Guest versions:
lxde 0.5.0-3ubuntu2
openbox 3.4.10-1
Same error behaviour as above.
Thanks,
Wolfgang
Created attachment 2681[details]
Patch to use width instead of height in a loop
24 bit is supported except in swap_byte_order.
While looking at it I noticed something looking like an obvious bug, but I wonder why it never caused any visible problem.
Thanks for the patch! I'll definitely apply that.
Um, so the bit depth issue is still unhandled though I guess. I will take a look at swap_byte_order, thanks for pointing out the problem for me.
Created attachment 2681 [details] Patch to use width instead of height in a loop 24 bit is supported except in swap_byte_order. While looking at it I noticed something looking like an obvious bug, but I wonder why it never caused any visible problem.