Dear all,
No one has yet discussed the middleware. Am I on the wrong list?
I have been working on a number of middlewares and dbus is the defacto standard for all. I see a lot of work going on the FreeSmartPhone.Org (FSO) [1] standard's implementation. It is being consumed by Angstrom, debian like and other embedded OSes.
FSO is based on the specifications of freedesktop.org [2] therefore I can't see a better middleware technology. Are there any better alternatives?
[1] http://www.freesmartphone.org/ [2] http://wiki.freesmartphone.org/index.php/Main_Page
Hi!
On Mon, Jun 07, 2010 at 06:43:43PM +0500, Shaz wrote:
Dear all,
No one has yet discussed the middleware. Am I on the wrong list?
no, you are absolutely right here :) ... welcome!
I have been working on a number of middlewares and dbus is the defacto standard for all. I see a lot of work going on the FreeSmartPhone.Org (FSO) [1] standard's implementation. It is being consumed by Angstrom, debian like and other embedded OSes.
FSO is based on the specifications of freedesktop.org [2] therefore I can't see a better middleware technology. Are there any better alternatives?
Better? We don't know yet :). The current focus of linaro is to drive middleware through full UI stack requirements and enabling driver/hardware vendors and upstream developers to collaborate on getting those stacks stabilized and properly integrated in linaro.
For example, on the graphics driver front, one of our focus areas for the time being is getting clutter + gles working this cycle. For that we are making the mesa/clutter gles packaging available which would then enable driver and hardware vendors and unity/clutter developers to make the drivers fit for that use case [1]. Also on graphics, we plan to do some initial experiments with embedded qt and there qt-lighthouse in particular, which should give us another way to drive the armel graphics stack and make these technologies easily available in some archive [2].
The other focus areas we have selected for this cycle is integrating a telepathy based telephony stack by pairing telepathy with ofono and then shipping an experimental dialer app with desktop integration to easily make phone calls [3].
Another topic for now - which is currently not a real focus area though - is make an initial push forward on the gps integration. If there are ideas on where we can better integrate GPS solutions, let us know.
OK, if you see other important topics that would deserve some attention in short/midterm on middleware don't hesitate to talk to me. Either here, or on #linaro on irc.freenode.net (nick: asac).
[1] - https://blueprints.launchpad.net/ubuntu/+spec/arm-m-graphics-stack-on-x [2] - https://blueprints.launchpad.net/ubuntu/+spec/arm-m-qt-on-embedded [3] - https://blueprints.launchpad.net/ubuntu/+spec/arm-m-telephony-stack
- Alexander
On (08/06/10 12:52), Alexander Sack wrote:
Hi!
On Mon, Jun 07, 2010 at 06:43:43PM +0500, Shaz wrote:
Dear all,
No one has yet discussed the middleware. Am I on the wrong list?
no, you are absolutely right here :) ... welcome!
I have been working on a number of middlewares and dbus is the defacto standard for all. I see a lot of work going on the FreeSmartPhone.Org (FSO) [1] standard's implementation. It is being consumed by Angstrom, debian like and other embedded OSes.
FSO is based on the specifications of freedesktop.org [2] therefore I can't see a better middleware technology. Are there any better alternatives?
Better? We don't know yet :). The current focus of linaro is to drive middleware through full UI stack requirements and enabling driver/hardware vendors and upstream developers to collaborate on getting those stacks stabilized and properly integrated in linaro.
For example, on the graphics driver front, one of our focus areas for the time being is getting clutter + gles working this cycle. For that we are making the mesa/clutter gles packaging available which would then enable driver and hardware vendors and unity/clutter developers to make the drivers fit for that use case [1]. Also on graphics, we plan to do some initial experiments with embedded qt and there qt-lighthouse in particular, which should give us another way to drive the armel graphics stack and make these technologies easily available in some archive [2].
The other focus areas we have selected for this cycle is integrating a telepathy based telephony stack by pairing telepathy with ofono and then shipping an experimental dialer app with desktop integration to easily make phone calls [3].
Another topic for now - which is currently not a real focus area though - is make an initial push forward on the gps integration. If there are ideas on where we can better integrate GPS solutions, let us know.
May be gpsd. here is the site http://gpsd.berlios.de/
OK, if you see other important topics that would deserve some attention in short/midterm on middleware don't hesitate to talk to me. Either here, or on #linaro on irc.freenode.net (nick: asac).
[1] - https://blueprints.launchpad.net/ubuntu/+spec/arm-m-graphics-stack-on-x [2] - https://blueprints.launchpad.net/ubuntu/+spec/arm-m-qt-on-embedded [3] - https://blueprints.launchpad.net/ubuntu/+spec/arm-m-telephony-stack
- Alexander
Linaro-dev mailing list Linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 8 June 2010 17:49, Khem Raj raj.khem@gmail.com wrote:
On (08/06/10 12:52), Alexander Sack wrote:
Another topic for now - which is currently not a real focus area though - is make an initial push forward on the gps integration. If there are ideas on where we can better integrate GPS solutions, let us know.
May be gpsd. here is the site http://gpsd.berlios.de/
I suggest GeoClue[1] for location gathering and LibChamplain[2] for displaying this information on a map widget as a start.
Regards, Jamie.
[1] http://www.freedesktop.org/wiki/Software/GeoClue [2] http://projects.gnome.org/libchamplain/
On Tue, Jun 08, 2010 at 09:49:19AM -0700, Khem Raj wrote:
On (08/06/10 12:52), Alexander Sack wrote:
Another topic for now - which is currently not a real focus area though - is make an initial push forward on the gps integration. If there are ideas on where we can better integrate GPS solutions, let us know.
May be gpsd. here is the site http://gpsd.berlios.de/
On IRC the point was made that it would be better to focus on gypsy [1] rather than gpsd which has some "claimed" flaws [2]; for me the arguments for gypsy feel reasonable but I don't have enough hands on experience myself. Anyone has more experience and could comment on this?
[1] - http://gypsy.freedesktop.org/wiki/ [2] - http://gypsy.freedesktop.org/why-not-gpsd.html
- Alexander
Better? We don't know yet :). The current focus of linaro is to drive middleware through full UI stack requirements and enabling driver/hardware vendors and upstream developers to collaborate on getting those stacks stabilized and properly integrated in linaro.
For example, on the graphics driver front, one of our focus areas for the time being is getting clutter + gles working this cycle. For that we are making the mesa/clutter gles packaging available which would then enable driver and hardware vendors and unity/clutter developers to make the drivers fit for that use case [1]. Also on graphics, we plan to do some initial experiments with embedded qt and there qt-lighthouse in particular, which should give us another way to drive the armel graphics stack and make these technologies easily available in some archive [2].
Seems linaro is trying 2 approaches: X based(clutter + GTK?) or Framebuffer based (Qt embedded). I'd suggest to support Qt for X11 too as it can provide unified UI/App framework and hide X or framebuffer details from upper layer.
I understand a lot of effort right now is focusing on GTK but I do see that vendor needs the flexibility to use same app in X or X less environment.
For Qt embedded side, some experiment can be done to strip down the size of it, for example, only including stripped QtCore and QtGui to provide minimal foot print (Maybe it requires Qt to be more modular.)
Another thing is Gallium3D, is there plan to try it out on ARM?
The other focus areas we have selected for this cycle is integrating a telepathy based telephony stack by pairing telepathy with ofono and then shipping an experimental dialer app with desktop integration to easily make phone calls [3].
I think MeeGo is doing the same thing, maybe linaro can share effort with
MeeGo. Will it include Cellular call and SIP call?
Another topic for now - which is currently not a real focus area though - is make an initial push forward on the gps integration. If there are ideas on where we can better integrate GPS solutions, let us know.
OK, if you see other important topics that would deserve some attention in short/midterm on middleware don't hesitate to talk to me. Either here, or on #linaro on irc.freenode.net (nick: asac).
[1] - https://blueprints.launchpad.net/ubuntu/+spec/arm-m-graphics-stack-on-x [2] - https://blueprints.launchpad.net/ubuntu/+spec/arm-m-qt-on-embedded [3] - https://blueprints.launchpad.net/ubuntu/+spec/arm-m-telephony-stack
- Alexander
Linaro-dev mailing list Linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tue, Jun 08, 2010 at 10:14:38AM -0700, JD Zheng wrote:
Better? We don't know yet :). The current focus of linaro is to drive middleware through full UI stack requirements and enabling driver/hardware vendors and upstream developers to collaborate on getting those stacks stabilized and properly integrated in linaro. For example, on the graphics driver front, one of our focus areas for the time being is getting clutter + gles working this cycle. For that we are making the mesa/clutter gles packaging available which would then enable driver and hardware vendors and unity/clutter developers to make the drivers fit for that use case [1]. Also on graphics, we plan to do some initial experiments with embedded qt and there qt-lighthouse in particular, which should give us another way to drive the armel graphics stack and make these technologies easily available in some archive [2].Seems linaro is trying 2 approaches: X based(clutter + GTK?) or Framebuffer based (Qt embedded). I'd suggest to support Qt for X11 too as it can provide unified UI/App framework and hide X or framebuffer details from upper layer.
Yes, Qt (with and without X) will likely to play an important role in our graphics stack efforts. The focus areas are ment to give direction on where to get started. The areas of focus are supposed to evolve over time based on needs and willingness of vendors and upstreams to work on something.
For Qt embedded side, some experiment can be done to strip down the size of it, for example, only including stripped QtCore and QtGui to provide minimal foot print (Maybe it requires Qt to be more modular.)
From what I understand, qt embedded is already supposed to be stripped down; we
can certainly explore if there is more modularization required together with upstream if we are unhappy with the footprint.
Another thing is Gallium3D, is there plan to try it out on ARM?
I think the usefulness of gallium is constrainted to hardware that looks similar to current desktop GPUs wrt programmable pipelines and shaders and so on ...
I was told that chips that support GL ES 2.0 might be modern enough to move to gallium architecture, but not sure. Anyone has input on that?
Also, I would be happy to get more opinions as of why pushing for gallium in arm driver space would be a good/bad idea in general.
The other focus areas we have selected for this cycle is integrating a telepathy based telephony stack by pairing telepathy with ofono and then shipping an experimental dialer app with desktop integration to easily make phone calls [3].I think MeeGo is doing the same thing, maybe linaro can share effort with MeeGo. Will it include Cellular call and SIP call?
Yes, its about getting the telephony stack ready to do easy cell _and_ sip calls.
- Alexander
-
Alexander Sack -
Jamie Bennett -
JD Zheng -
Khem Raj -
Shaz