Active Topics
-
Phone Camera Competition April 2021: "Funny & Foolish" (33)
to General by Fellfrosch - 12 hrs, 30 mins ago -
What's the best Handheld gnu/linux machine for 20XX? (78)
to Competitors by clort - 17 hrs, 16 mins ago -
Unofficial Storage for camera phone competition... (62)
to General by catbus - 1 day, 1 hr ago -
Maemo-Leste pre-alpha announcement (512)
to Maemo 7 / Leste by nonsuch - 2 days, 2 hrs ago -
The Intel RealSense Smartphone prototype (0)
to Competitors by n950 - 2 days, 5 hrs ago -
Maemo Leste Playground (57)
to Maemo 7 / Leste by clort - 3 days, 2 hrs ago -
A Palm OS thread ... and a thank you to the community (23)
to Alternatives by bradvesp - 4 days, 1 hr ago - more...
| The Following User Says Thank You to bluehash For This Useful Post: | ||
 |
|
2009-10-24
, 16:06
|
|
Posts: 3,397 |
Thanked: 1,212 times |
Joined on Jul 2008
@ Netherlands
|
#2
|
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.
__________________
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
| The Following 2 Users Say Thank You to allnameswereout For This Useful Post: | ||
 |
|
2009-10-24
, 16:06
|
|
Posts: 4,274 |
Thanked: 5,358 times |
Joined on Sep 2007
@ Looking at y'all and sighing
|
#3
|
Originally Posted by http://wiki.maemo.org/Documentation/Maemo5_Final_Installation#Known_Issues_in_the_SDK
I'm here to make this message longer.
Known Issues in the SDK
- Armel target does not bring up the UI framework
|
|
2009-10-24
, 16:11
|
|
Posts: 90 |
Thanked: 10 times |
Joined on Aug 2007
|
#4
|
Thanks guys!
__________________
machinegrid.com
machinegrid.com
|
|
2010-04-15
, 11:50
|
|
Posts: 1 |
Thanked: 1 time |
Joined on Apr 2010
|
#5
|
Originally Posted by allnameswereout
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.
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.
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.
| The Following User Says Thank You to larsivi For This Useful Post: | ||
|
|
2010-04-15
, 16:58
|
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#6
|
@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?
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?
| The Following User Says Thank You to Joorin For This Useful Post: | ||
 |
|
2010-04-15
, 17:15
|
|
Posts: 2,427 |
Thanked: 2,986 times |
Joined on Dec 2007
|
#7
|
Originally Posted by larsivi
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.
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.
__________________
N9: Go white or go home
N9: Go white or go home
|
|
2010-04-16
, 18:31
|
|
Posts: 9 |
Thanked: 1 time |
Joined on Mar 2010
|
#8
|
Originally Posted by daperl
"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
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.
| The Following User Says Thank You to ancoldsun For This Useful Post: | ||
 |
| Tags |
| xephyr export display |
«
Previous Thread
|
Next Thread
»
| Thread Tools | |
|
All times are GMT. The time now is 22:28.
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!
machinegrid.com