Re: About the future of the freesmartphone.org middleware

2012-07-24 Thread Simon Busch

Am 24.07.2012 11:27, schrieb Thomas Munker:

Hi,
i thought the ui is saving the volume values where it should (using
opreference interface), but fso doesn't pick them up. There's an old
bugreport in shr-track [0], that suggests it's fso's fault. Maybe this
should be clarified. I've found a new bugreport too... [1] And it's been
for some years in the fso-track, too: [2]


Ok, will look into this bug reports.


With the network-registration, i get alwas an error that this feature is
not implemented for my modem. Maybe shr uses to old feeds of fso, i
don't know.


Hm, you're right. I got it wrong cause looking at the wrong place in the 
source code :) Sorry for that. I will implement this really soon.


regards,
Simon


--
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: About the future of the freesmartphone.org middleware

2012-07-22 Thread Simon Busch

Am 21.07.2012 21:44, schrieb Thamos:

Hi all.
I've never seen someone using the conference-feature. I think selecting
the provider is more important. (this one really annoys me, since i am
near an border and simply can't phone until i get out auf alien range,
if the phone switched one time, even reboot doesn't help...). I also
miss the possibility to choose loudness of the ringtone reasonably. Most
other phones are even able to choose a ringtone based of the caller!


Ok, this are two things. The first one regarding switching a different 
provider should be already possible with the 
org.freesmartphone.GSM.Network API. Just take a look at the API 
documentation at [0].


You have to differentiate here. FSO efforts are not about the user 
experience on the UI side. It's just a middleware enables you to 
implement such things like loudness handling of the ringtone in your 
user experience. If you are talking about SHR in detail here just 
request your feature to the SHR developers.


regards,
Simon

[0]: 
http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.GSM.Network.html;hb=HEAD#RegisterWithProvider


--
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: About the future of the freesmartphone.org middleware

2012-07-22 Thread Simon Busch

Am 22.07.2012 02:24, schrieb Kai Lüke:

Hello,
I think these all together will be fine. The only thing I have in my
mind beside these is something I ever wanted to try but never did:
redirecting sound (e.g. a sound file with pause melody or answerphone)
to the call input.


It depends a lot on the phone you're using if this is possible and it's 
nothing I really see in the FSO middleware in the next time as there are 
other feature which are quite more essential. But if you have time and a 
good idea how to integrate this please speak up.


regards,
Simon

--
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: About the future of the freesmartphone.org middleware

2012-07-22 Thread Simon Busch

Am 22.07.2012 03:39, schrieb Pierre Pronchery:

Hi Simon, lists,

On 21/07/2012 20:45, Simon Busch wrote:


as a lot of you may have noticed we did two releases in the past months
of the FSO stack. Both were related to bring stability and consistence
to the stack. Now I want to talk with you about the future of the stack. [...]


Good to hear, thanks for the heads up.


For fsogsmd there are the following things on my list:
[...]
5. Multi device support: While working in HFP HF support in fsogsmd I
discovered that things would be easier if we can control more than one
modem with the same daemon at the same time. Think about phone with
support for more than one SIM card. Work has already started for this in
the morphis/multi-device branch of the cornucopia repository.


I fully agree to this, and I have started work to support this in
DeforaOS Phone. More specifically, my goal is to be able to support (and
integrate) an AT-based modem together with VoIP account(s), Instant
Messaging and so on. To help me with this task I am using libpurple
(from Pidgin) and sofia-sip (for SIP, obviously).


Ok, we're talking here about two different things. My effort for multi 
device support in fsogsmd is a a step before what you describe. It's not 
about using VoIP and a AT based modem together. Think about situations 
where you have more than one modem (and really a modem) to control like 
in a phone with more than one SIM card or on a laptop where you have a 
phone connected via HFP HF and a UMTS stick for your data connection.


Controlling VoIP and a modem together with the same API is definitely 
nothing we should do in fsogsmd itself but in telepathy or a fsophoned.


regards,
Simon

--
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [Shr-Devel] About the future of the freesmartphone.org middleware

2012-07-22 Thread Simon Busch

Am 22.07.2012 12:03, schrieb Neil Jerram:

All of the details you've described sound to me like excellent and
compelling things to work on.

But your wider problem is that you're working in a vacuum, because
there's no reasonably widely used phone distribution that uses FSO and
that is also regularly and safely updated.  That means you have no users
for your incremental improvements.

Obviously there's SHR, but from what I see on the mailing lists it seems
to me that the development edge of SHR is a complete basket case:
constantly broken and regressing in very basic functionality.

I think you either need to change SHR's approach, or to find/create
another compelling distribution (perhaps around Aurora) that uses FSO;
otherwise all your planned improvements won't help anyone.

I'm sorry to be so negative and unconstructive here, but it seems clear
to me that SHR is your elephant in the room, and I don't think you
should ignore that.


You find excellent words to describe the current state our efforts to 
have a completely open sourced mobile telephony stack. There is no real 
development on the upper layers. I tried to get into this for a long 
time (remember mickeyl and I started aurora back in 2011) but came to 
the point that I don't have the time to do the real big thing anymore. 
It's frustrating to have nothing you can really use with the software 
you wrote. But finally I came to the point that I have fun developing 
just FSO and get everything into shape so others can pick up. I 
indicated already some months ago that I don't want to focus on a 
specific device anymore but just FSO and get it available in a good and 
stable state where possible.


So if anyone has fun to pick up my work with FSO on a higher level just 
do. I will continue to develop the middleware in my spare free time and 
hope it's going into the right direction.


Any btw. it must no be everytime suitable for a device like a phone. I 
started implementing HFP HF as I like the idea to have my phone lying 
next to my laptop while working a get a indication when a phone call 
comes in on my laptop where I can then answer the call directly without 
putting my fingers on the phone.


regards,
Simon

--
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [Shr-Devel] About the future of the freesmartphone.org middleware

2012-07-22 Thread Simon Busch

Am 22.07.2012 13:52, schrieb rakshat hooja:

On Sun, Jul 22, 2012 at 3:33 PM, Neil Jerram n...@ossau.homelinux.netwrote:


Simon Busch morp...@gravedo.de writes:


I would be really happy to hear what other people are thinking about
the idea behind FSO since it was started back in 2008. What are your
missing features? What do you like and what not?


All of the details you've described sound to me like excellent and
compelling things to work on.

But your wider problem is that you're working in a vacuum, because
there's no reasonably widely used phone distribution that uses FSO and
that is also regularly and safely updated.  That means you have no users
for your incremental improvements.



Does QTMoko not use FSO now? If yet then Radek has a pretty usable upper
layer out there now where end users can try out the improvements in FSO.


As far as I know Qtmoko can use FSO but does not as default.

regards,
Simon

--
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


About the future of the freesmartphone.org middleware

2012-07-21 Thread Simon Busch

Hey everybody,

as a lot of you may have noticed we did two releases in the past months 
of the FSO stack. Both were related to bring stability and consistence 
to the stack. Now I want to talk with you about the future of the stack. 
In the past we were only concentrating on getting new hardware supported 
and lost our real focus on creating a middleware suitable for 
embedded/specific-purpose devices. This is where I want to go back to 
and get into development again.


In the last weeks I looked over several parts we have in our stack and 
tried to find out where we can improve and get into development of new 
features again. A lot of you have stability in mind as you want to use 
something with FSO on your daily phone. Thats the second peace which 
should be part of the core development focus of the Freesmartphone.org 
middleware.


Getting new features is fast said but I have several things on my list 
where I want to improve FSO in the next weeks and months. Everything is 
focused on the core stack which is formed by our framework libraries and 
the three daemons fsodeviced, fsogsmd and fsousaged. We have other 
daemons like fsotdld as well but that will be not on my focus. If 
someone wants to step up with further development of these just go on 
and get in contact. But please don't get me wrong: I will support all 
other daemons like fsoaudiod and fsotdld in the next releases too but 
just not doing any development related work for them.


For fsogsmd there are the following things on my list:

1. Get the last peaces of not implemented things in like conference or 
emergency calls

2. Several API cleanups
3. Get several bugs fixed
4. Do integration testing with a remote controlled phonesim so we can 
simulate incoming calls etc. This will also included integration testing 
with a remote controlled fsogsmd on another device
5. Multi device support: While working in HFP HF support in fsogsmd I 
discovered that things would be easier if we can control more than one 
modem with the same daemon at the same time. Think about phone with 
support for more than one SIM card. Work has already started for this in 
the morphis/multi-device branch of the cornucopia repository.
6. Cleanup of the modem status handling: right now the modem status and 
SIM/network status are too much tight together. We have cleanly separate 
them.
7. Internally we don't separate a modem from a AT based modem; that 
needs to be fixed
8. A lock-down mechanism to keep anyone out when doing a firmware 
upgrade. When doing a firmware upgrade of a modem we have the problem 
that nobody should access the modem while this is in progress. The idea 
is now to implement a dbus API to lock the modem by requesting a lock 
and only the requesting program can unlock the modem again. While the 
modem is locked nobody else can access the modem via fsogsmd.


fsousaged:
- nothing right now

fsodeviced:
- nothing right now

lib*:
- I am thinking about grouping all libraries together so just have one 
single framework library and don't need to maintain several small 
libraries which increases the complexity of release testing, ABI 
refinements, etc. Just one libfsoframework; this is only a thought in my 
head right and nothing concrete.


That are some of my toughs were I want to go with FSO in the next 
months. So no focus on concrete devices but getting the stack itself 
forward to be ready for every kind of a device.


I would be really happy to hear what other people are thinking about the 
idea behind FSO since it was started back in 2008. What are your missing 
features? What do you like and what not?


regards,
Simon

--
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: New PowerVR SGX reverse engineering project

2012-06-16 Thread Simon Busch

Am 15.06.2012 21:34, schrieb Dr. H. Nikolaus Schaller:

FSF has set up a new PowerVR SGX reverse engineering project
proposed by Luke K.C. Leighton.

Since we have such a GPU in our GTA04 SoC (DM3730), I think there
may be some interest here on this list to support this effort.

The goal is to write free and open replacement drivers and firmware
and maybe do fancy stuff with the GPU shader cores (signal and
image processing).

The mailing list is here:

https://lists.nongnu.org/mailman/listinfo/powervr-devel


The mailinglist is closed already cause of a possible lawsuit. Let me 
quote Bob Ham:


 The GNU lawyers have apparently stated that this PowerVR reverse
 engineering project should not be hosted by the GNU project (on
 savannah.nongnu.org) as there is a risk of the GNU project being the
 subject of a lawsuit.  Yay for lawyers!

 Unfortunately, that means this mailing list is now closing.  I
 apologise for the inconvenience.

regards,
Simon

--
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: FR audio subsystem: gsmhandset ... files

2012-04-11 Thread Simon Busch
On 11.04.2012 15:09, Matthias Apitz wrote:
 El día Wednesday, April 11, 2012 a las 02:47:34PM +0200, Radek Polak escribió:
 
 http://wiki.openmoko.org/wiki/Neo1973_audio_subsystem
 http://hnet.endofinternet.net/elektro/Freerunner/ALSA/sound_setting.html

 I'd like to have a general understanding and in detail how the
 gsmhandset (...) files are used in the FR, for example in the SHR
 distribution.

 Before you answer or make a call you do:

  alsactl -f gsmheadset.state restore

 and after hanging up do:

  alsactl -f stereoout.state restore

 I don't think there's any magic involved there...
 
 In theory I was thinking the same; I even renamed alsactl to
 alsactl.orig and created a shell wrapper /usr/sbin/alsactl which should
 log the args and call alsactl.orig to do the work; nothing appeared in
 my log file while doing a call
 
 1. How this is done exactly (in SHR) and by which piece of software?

It's done by fsodeviced (the router_alsa plugi) or fsoaudiod and is
initiated by libphone-ui.

 2. The SHR GUI while calling (see http://www.unixarea.de/Screenshot-7.png)
has some sliders for Volume and Mic; and to enable the Speaker or
mute the Mic... how do they work? Do they change 'gsmhandset' file?

No. The SHR UI directly adjusts the mixer settings of the ALSA sound
card here. In /etc/phonefsod.conf or /etc/phoneuid.conf is written down
which name this control have.

regards,
Simon

-- 
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: FR audio subsystem: gsmhandset ... files

2012-04-11 Thread Simon Busch
On 11.04.2012 21:19, Matthias Apitz wrote:
 El día Wednesday, April 11, 2012 a las 08:39:52PM +0200, Simon Busch escribió:
 
 1. How this is done exactly (in SHR) and by which piece of software?

 It's done by fsodeviced (the router_alsa plugi) or fsoaudiod and is
 initiated by libphone-ui.
 
 Thanks; I will checkout the sources and have a look into;
 
 2. The SHR GUI while calling (see http://www.unixarea.de/Screenshot-7.png)
has some sliders for Volume and Mic; and to enable the Speaker or
mute the Mic... how do they work? Do they change 'gsmhandset' file?

 No. The SHR UI directly adjusts the mixer settings of the ALSA sound
 card here. In /etc/phonefsod.conf or /etc/phoneuid.conf is written down
 which name this control have.
 
 none of the two files in my SHR has any entry which could have todo with
 audio or alsa (which explains somewhat that the sliders have no impact
 during a call); any idea why?
 
 (should we move this thread to shr-devel?)

Sorry I meant ibphoneui.conf. There you will find for the GTA02:

[alsa_control_speaker]
speaker = Headphone Playback Volume
microphone = Mono Playback Volume
microphone_mute = Mono Mixer Sidetone Playback Switch

This are the three controls which libphone-ui will adjust for
speaker/microphone volume and muting the microphone (you will also find
them with alsamixer).

regards,
Simon

-- 
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: log of sent DTMF tones

2012-04-08 Thread Simon Busch
On 08.04.2012 14:11, Matthias Apitz wrote:
 
 Hello,
 
 I was testing something and used a toll free number of my local
 bank (because it is free and there is a voice and DTMF System menu
 to play around)... I was suprised seeing lines like this in 
 /var/log/fsogsmd.log:
 
 2012-04-08T11:49:59.395616Z [INFO]  libfsotransport 0710:2: SRC:
 +VTS=# - [ OK ]
 
 The value of +VTS=x is the DTMF tone to send; the value x should
 not be logged, at least not in the INFO level; keep in mind that
 such DTMF tones often are used to send credentials, PIN or other
 secret information to the other side of a call. While it is
 technically nearly imposible to intercept them in the call, it is
 prety much easy to read them out of the log files of a (stolen or
 lost) phone.
 
 I will file a bug report in Trac for SHR.

Can you please file a bug report in FSO trac too and link it with the
SHR bug? This is something really related to the core of fsogsmd.

regards,
Simon

-- 
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [Shr-User] [Community Updates] 2011-09-01 issue is out

2011-09-01 Thread Simon Busch
On 01.09.2011 08:05, Timo Jyrinki wrote:
  Aurora is an UI for FSO2 middleware that tries to replace
 Zhone/Zhone2. It is currently primarily offered as SHR distribution
 based images for Palm Pre series of phones
 
 Homepage: http://wiki.freesmartphone.org/index.php/Aurora
 Package: aurora

Thats not correct. Aurora is not only a new UI based on the FSO2
middleware. It is a distribution too and is not based on SHR! Aurora
will be the default development base for FSO in the near future as we
need to target the needs of a user and for that we need to develop our
simple but powerfull user interface.

regards,
Simon

-- 
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


First beta release of Aurora

2011-08-31 Thread Simon Busch
Heyho,

a little bit late but it's still august so who cares? The first release
of the aurora project has finally arrived. It is still in beta state but
ready to be flashed on your Palm Pre / Pre Plus / Pre 2 devices.

The images for each device you find in [1]. Just download them and
follow the guide in [2] to get it working on your device. A short
overview about the the first release you get in [2] too.

Whats is Aurora?

The aim of Aurora is to replace zhone and zhone2 as development UIs for
FSO. From the viewpoint of a middleware architect,
it's essential to have clients available that use the various features
of the FSO services. On the other hand though, this
time we want to create something that is also suitable for day to day
use. Aurora is supposed to be something we call
a featurephone client – featurephones being those things we used for
telephony before smartphones were invented.

Aurora being a featurephone client does not necessarily mean it will
never get the smartphone features Android or iOS
are popular for, it rather describes our approach as being
as-simple-as-possible. So for now you will not be able to
install additional apps or features. Everything (you need) is part of
the Aurora client.


If you have any questions feel free to ask and we're happy about bug
reports!

regards,
Simon

[1]: http://amethyst.openembedded.net/~morphis/aurora/2011-08-beta1/
[2]: http://wiki.freesmartphone.org/index.php/Aurora/Version_0_1

-- 
Simon Busch - http://mm.gravedo.de/blog/

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: qtmoko and FSO

2011-06-04 Thread Simon Busch
On 02.06.2011 23:38, Radek Polak wrote:
 Hi,
 for those who are interested in qtmoko running on top of freesmartphone.org 
 framework here is some update.
 
 Things are going really nice. We can now use Qt binding library for FSO which 
 is automatically generated from fso xml spec files. It means that it's easy 
 to 
 use existing FSO api. It is very easy to add new api (just regenerate with 
 one 
 command) and compiler can find any FSO API changes.
 
 As for integration with QtMoko i have decided to add FSO phonevendor plugin. 
 It means that there will be libfsovendor.so plugin file and you can swith 
 between current libneovendor.so and libfsovendor.so by changing one 
 environment variable. All future releases will have both pluging and you will 
 be able to switch between them.
 
 It seems that both FSO and qtopia phone interfaces are nicely written and 
 they 
 seem to fit quite well together so i expect fast progress now.
 
 Currently QtMoko can use FSO to register to network, print available 
 operators, make and hang call. I plan to do finish the call interface, then 
 probably start with SMS and then i can do some experimental release.
 
 Thanks to FSO and SHR people for great framework and for help!

Thank you Radek for the work you and the others have done!

I imported the qfsodbusxml2cpp utility at git.freesmartphone.org as own
repository [1] and added automake support to it. There is even a own
repository for a library called libfso-qt [2] now which gives you access
to the FSO DBus API in every Qt application without the need to do the
conversion from xml to cpp again. It takes the FSO xml specs directly
from a installed version of fso-specs.

regards,
Simon

[1]: http://git.freesmartphone.org/?p=qfsodbusxml2cpp.git;a=summary
[2]: http://git.freesmartphone.org/?p=libfso-qt.git;a=summary

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Aurora

2011-05-16 Thread Simon Busch
On 16.05.2011 23:22, Neil Jerram wrote:
 I'm afraid I don't understand.  Why not just have SHR as your
 reference set of applications?  If you don't think they are using the
 FSO APIs in the pattern that you would recommend, presumably you could
 work with them to correct that?  Or, if they are missing applications
 or features to showcase some of the latest FSO API features,
 presumably you could help them to add those?

SHR is a great thing, but it's too complex to be the first showcase for
new features. The main problem we have is time and man-power. We are
currentl two people doing most of the FSO work. With two people it's
even hard to get only the basics done.
SHR is based on the traditional design pattern of a window mananger
which runs some application you can work with. The work to integrate new
features like network (wireless, gprs, bluetooth pan) in a usable we
needs a lot of work (you need a new E Gadget, you need a application to
choose the network, you to adjust shr-settings, ...) to do.

I worked for now 2 two to get SHR running on the Palm Pre and it's so
much work that I will never finish it on my own. You invest a lot of
time to debug things, see how things work and never get your work
finished in a reasonable time frame.

 At the top of every application stack is the user. Pleasing him or her
 is the topmost priority.
 
 Speaking as a user, I would be pleased not to see more unnecessary
 fragmentation of front-end efforts; also for the FSO2 middleware to be
 rock-solid, with things fixed like RequestResource('bluetooth')
 starting bluetoothd.

Aurora is not about fragmentation. Zhone was already there before SHR
and Aurora will continue Zhone. We will take aurora as our new reference
application as it is quite simple and let us integrate new features very
fast.

 To be fair, it may be that FSO2 already is rock-solid now.  I haven't
 reviewed the situation recently, but I can't immediately think of any
 known and clear issues, about from the bluetoothd one.  But in that
 case I'd still prefer focus on the SHR front end, over some new UI.

As you may know we are working hand-in-hand with all the SHR developers
and we are loving SHR too. But at some point we need to concentrate us
on FSO and FSO as framework only to be successfull in the future and not
only on the Openmoko devices. There are a lot of devices out which are
suitable to be driven by FSO but needs time to be integrated into the
framework. If we do everytime to full work for SHR and FSO we will never
do anything else with this phones in their lifetime. If you work for a
long time very hard on such a project you want to see something working
and usable to have. But currently with doing the doubled work for SHR
and FSO does not let us come the this point.

 If you strongly favour Qt, you could take QtMoko as your reference set
 of applications.  That would be especially helpful right now, as Radek
 is just looking at converting QtMoko to use FSO.

With QtMoko it's the same as I said above. We need some simple stupid
thing we can change within an hour to support a new feature like network
management. We cannot archive this with QtMoko or SHR.

 I'm almost lost for words here.  Starting from scratch seems so
 obviously the wrong thing to do, when there are mature projects that
 you could contribute to...

We are not starting from scratch with a completely new platform. We are
just reordering the reponsibility of the FreeSmartphone team which is to
develop the middleware and concentrate of integrating new devices and
get new features like network management in.

 I must be misunderstanding what you mean - please do explain more!

Don't thing about aurora as something big, it's a very simple thing for
simple needs. You will see all new features even in SHR, but not done by
the core FSO team.

regards,
morphis

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: FOSDEM 2011

2010-09-01 Thread Simon Busch
On 01.09.2010 14:09, Dr. Michael Lauer wrote:
 Hi folks,

 FOSDEM just released the call for dev-rooms.
 (http://www.fosdem.org/2011/)

 After our lucky mini-appereance which was
 quite well received, I wonder whether anyone
 would be interested in organizing
 a combined SHR/FSO/?  devroom for next year.

 I will not have enough time to take the wheel
 on this, however I volunteer to do something
 (presentation, workshop, whatever) should
 we get the opportunity to have such a room.

 Cheers,

 :M:

I would like to attend a dev room on FOSDEM too, if I have the time in 
early februrary to come to belgium. So if anyone is interested in 
organizing a dev room, please do so!

regards,
morphis


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Is there a way to have webOS on the freerunner?

2010-04-30 Thread Simon Busch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 30.04.2010 19:18, schrieb Lars Hennig:
 Hi,
 
 as webOS seems to me as one of the best fingerfriendly UIs, I wondered if 
 somebody already tried to port it (s.th. similar) to the freerunner. 
 Are there any efforts to do so?
 
 Of course, he best would be to put it on top of the FSO stack :-)
 

No, there is no way to do that. webOS is compiled for armv7 and the
Freerunner can only run the armv4 instruction set. Furthermore you have
to modify webOS in such a way you cannot do without the code.

If you want to have webOS buy one of Palm's devices, otherwise buy even
one of this cause FSO will run on it in the near future :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvbFv4ACgkQqli4aSXiwM93CgCfaE5+by00DZ6rAUWJkJJ1HMau
LZEAn0eX1Tm8erQhZm5kYLNksBn+7u7Z
=y7IR
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community