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