Raspian vs. ArchLinux

[randyk]

I have a B9Creator (http://b9creator.com) which I'd like to drive with a Raspberry Pi. For the best interaction, I want to make the Raspberry Pi two-headed. I have that part working with an X11 config that can present each device as a separate screen. One screen will be used to interact with the user and the other will control the projector which cures the resin on the B9Creator.

I have the software ported to the Pi, and it runs on Raspbian, but gives me a segmentation violation when running on ArchLinux.

I'd really like to use ArchLinux because it supports the Plugable.com USB Graphics Adapter out of the box (giving me 2 heads), and I've demonstrated to my satisfaction that it works.

The B9Creator is a Qt-based application (currently Qt4.8). Whether I build it on under ArchLinux or Raspbian, the resulting binary crashes when run under ArchLinux, and appears to run correctly under Raspbian. But Raspbian doesn't support the UGA adapter, so ArchLinux seems like the way to go.

Before I started posting extensive diagnostic data, such as the respective Xorg.log.* files, I thought I'd throw out the question to see if anyone had experience with this. I've searched the net, including these forums, without much luck. Some claim that using Qt5 is much better. I tried a qt5 hellworld program and it crashes immediately under ArchLinux (can't try that on Raspbian currently as I don't have qt5 installed). So maybe if I solved that problem, the other one would be solved as well.

The core dump is pretty useless (stack is trashed, no meaningful stack trace, for both B9Creator and helloworld apps). I'm not missing any packages on ArchLinux that I can tell. The program starts up, does some output, and then crashes after calling the QtApplication object's exec() method.

My guess right now is that it is something to do with Qt4's interaction with X11, but there's a lot of stuff going on (ie. communicating with the B9Creator's arduino via /dev/ttyACM0). However, one reason for suspecting X11 is that if I use SSH X11 forwarding to my mac, the program running on the ArchLinux appears to work fine, which tells me there's something about X11 on ArchLinux that it doesn't like / isn't quite right.

The end result (2 headed Raspberry Pi driving B9Creator) would be pretty sweet.
Hope there are some answers here.
Thanks for reading.

[pepedog]

Does your raspbian install have swap memory?

[randyk]

The Raspbian has a 100MB swap file (/var/swap). I did run into hangs with ArchLinux, but I set up a 1GB swap partition, and I don't seem to have that particular problem any more.

One interesting difference I notice between the Xorg.0.log files (besides nearly all the ArchLinux versions being more recent):
Raspbian:
[ 37.332] (II) AIGLX: Screen 0 is not DRI2 capable
[ 37.332] (II) AIGLX: Screen 0 is not DRI capable
[ 37.341] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/swrast
_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/swrast_dri.so: cannot open shar
ed object file: No such file or directory)[ 37.341] (EE) GLX: could not load software renderer
[ 37.342] (II) GLX: no usable GL providers found for screen 0

ArchLinux:
[ 31.794] (==) RandR enabled[ 31.893] (II) AIGLX: Screen 0 is not DRI2 capable
[ 31.893] (II) AIGLX: Screen 0 is not DRI capable
[ 44.155] (II) AIGLX: Loaded and initialized swrast
[ 44.156] (II) GLX: Initialized DRISWRAST GL provider for screen 0

Makes me wonder if their difference is in how they are doing swrast.

[pepedog]

So your qt5 problem is fixed? Hope swap is not on solid state media.

So now your problem is getting 2 screens running?

[randyk]

Not making much progress yet. One thing I did try was to make /usr/lib/xorg/modules/dri/swrast_dri.so unreadable, to simulate what was happening on Raspbian. When I tried to run B9Creator, it crashed Xorg (the X server). Obviously the B9Creator crashed as well.

The qt5 helloworld program doesn't crash the Xorg server, but it does come back with a segmentation violation. In this case, even when forwarding the X connection to my mac mini.

At this point I have two options I can see. One is to use framebuffer directly, and bypass X11, at least for the part that operates the projector on the 3D printer. This was supposed to be the harder option (a bunch of programming), but it's starting to look like the better one.

The other option is to debug this, perhaps by building a debug version of X11. That is an option I don't particularly relish.