Unable to get N900 display in Xephyr when in ARMEL mode

[bluehash]

Hello,

I just finished installing scratchbox last night and everything went smoothly. I could even compile a few sample programs successfully.

Problem is when I'm in ARMEL mode, I'm unable to export the display to Xephyr. In X86, I can see the display.
My steps:
[sbox-FREMANTLE_ARMEL: ~] > export DISPLAY=:2
[sbox-FREMANTLE_ARMEL: ~] > af-sb-init.sh start

I'm getting qemu segfaults and the following error:
getsockopt level=1 optname=17 not yet supported

Any help would be appreciated. Thanks!

[allnameswereout]

Yes, known QEMU bug, your problem is addressed in FAQ. Solution: use FREMANTLE_X86 instead. FREMANTLE_ARMEL is not intended for what you are trying anyway.

[qwerty12]

Known Issues in the SDK


Armel target does not bring up the UI framework


I'm here to make this message longer.

[bluehash]

Thanks guys!

[larsivi]

Yes, known QEMU bug, your problem is addressed in FAQ. Solution: use FREMANTLE_X86 instead. FREMANTLE_ARMEL is not intended for what you are trying anyway.

I find this solution hard to accept. As a developer of graphical applications (OGL ES ++), there needs to be support for testing on ARMEL (low level code used to prepare the graphics, and the OGL ES implementation itself, are things that are likely to behave differently on X86 and ARMEL making it absolutely necessery to test as much as possible before deployment). I understand that there are additional emulation issues when it comes to graphical hardware, but I would at very least expect the GUI to work. The competition (Android, etc) does not appear to have similar restrictions.

Another aspect is that OGL ES normally isn't easily available to test on X86 targets, and the differences relative to standard OGL makes such testing also necessary.

[Joorin]

@larsivi

The Maemo idea that "cross compiling" means "run your armel compiled compiler through qemu to generate armel code" is the root of some of this evil.

Why isn't there an i386 compiled compiler that generates armel code?

[daperl]

I find this solution hard to accept. As a developer of graphical applications (OGL ES ++), there needs to be support for testing on ARMEL (low level code used to prepare the graphics, and the OGL ES implementation itself, are things that are likely to behave differently on X86 and ARMEL making it absolutely necessery to test as much as possible before deployment). I understand that there are additional emulation issues when it comes to graphical hardware, but I would at very least expect the GUI to work. The competition (Android, etc) does not appear to have similar restrictions.

Another aspect is that OGL ES normally isn't easily available to test on X86 targets, and the differences relative to standard OGL makes such testing also necessary.

Hard to accept? Before deployment? I think you need to come in, sit down, and have a beer. This is the Wild West. Around here, we build and test on our devices.

[ancoldsun]

Hard to accept? Before deployment? I think you need to come in, sit down, and have a beer. This is the Wild West. Around here, we build and test on our devices.
"test on our devices" so this mean we have to accet the risk that may thrash our devices ? is that whatu mean .Then u must be a richman cuz u didn't care whether ur device is thrashed or not . but many of us dont have much money although we are really interested in maemo app dev ( especially ogles app ) but we do not want to take that risk