Announcement

Collapse
No announcement yet.

Meego IVI Status Thread

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Meego IVI Status Thread

    Hi Gang,

    As I am keeping a finger on the pulse of the Meego IVI efforts, I was asked to keep the community informed... So here's a thread to do so. There's a lot of status to cover, but I will start off by linking in briefings from the recent Meego Conference in Dublin (which I couldn't attend):

    http://conference2010.meego.com/sess...ected-mobility

    http://www.youtube.com/watch?v=XJhLah_u_4U

    http://conference2010.meego.com/session/bof-ivi

    And here's an interesting slide --

    http://twitpic.com/3743bb/full

  • #2
    Genivi

    GENIVI members play (or will play) a large part in the development of the IVI platform... Taken from their website at http://www.genivi.org/ (specifically their FAQs) are some of the more community interesting things:

    What is GENIVI?
    GENIVI is a non-profit industry alliance committed to driving the broad adoption of an In-Vehicle Infotainment (IVI) open-source development platform. GENIVI will accomplish this through three top-level activities: aligning requirements, delivering reference implementations and offering certification programs.

    What is In-Vehicle Infotainment (IVI)?
    IVI covers entertainment and information features and functionality available in automobiles. IVI is a rapidly changing and expanding field within the automotive industry. It covers many types of vehicle infotainment applications including music, news and multimedia, navigation and location services, telephony, internet services and more.

    Who is part of the GENIVI Alliance?
    GENIVI is open to all organizations engaged in the automotive, consumer electronics, communications, application development and entertainment industries that are interested in the success of IVI systems and related products.

    What are GENIVI's goals?
    GENIVI's objective is to foster a vibrant open-source IVI community by:

    * Delivering a reusable, open-source platform consisting of Linux-based core services, middleware, and open application layer interfaces.
    * Engaging developers to deliver compliant applications.
    * Sponsoring technical, marketing and compliance programs.


    What characterizes an IVI open-source development platform?
    The GENIVI open-source platform consists of Linux-based core services, middleware and open application layer interfaces. These are the essential but non-differentiating core elements of the overall IVI solution set. The automobile manufacturers and their suppliers will use this platform as their common underlying framework and add to it their differentiated products and services (the consumer facing applications and interfaces). GENIVI is identifying these common automotive infotainment industry requirements to establish a higher baseline from which to develop products for the common good of the ecosystem.

    Will elements such as HMI/user interfaces and their design/styles be included in the GENIVI platform?
    The GENIVI IVI platform does not address the highly competitive areas such as user interfaces and logic that defines the end-user experience. The alliance is built on the notion that user interfaces and logic distinguish products and, thus, should remain in the domain of the vendors who design and deliver the device and software.

    How is GENIVI's work accomplished?
    The majority of GENIVI's work is conducted through the technical and marketing councils and their respective work groups. The Technical Steering Council develops and monitors the technical working plan of the alliance, including requirement collection and specification development, adherence to IPR policies and processes, testing and release of reference implementations, and adoption and compliance activities. Technical work groups include System Infrastructure, Multimedia CE, Automotive, Mobile Office/Internet and Reference Systems. The Marketing Council develops the alliance marketing plan, manages internal and external communications, and facilitates programs that bring greater awareness to the alliance and its deliverables.

    When will the first release of the GENIVI Reference Platform be available?
    The first version of the GENIVI platform was released in January 2010 and supported the Intel Atom architecture on the Moblin Linux distribution. The next release is planned for late 2010. It will support both Intel Atom and ARM architectures on top of the MeeGo Linux distribution. A further release is planned for summer 2011 with increased functionality.

    What are the main benefits for the automotive industry of a reusable, open-source IVI platform?
    A reusable, open-source IVI platform will:

    * Speed time to market.
    * Accelerate innovation and increase perceived value.
    * Reduce development costs dramatically.
    * Provide a basis on which to cultivate the IVI ecosystem.
    * Provide code transparency and mitigate vendor lock-in.


    What are the advantages of open-source solutions over proprietary solutions?
    An open-source IVI platform provides three key benefits:

    1. A common target for software developers seeking to enter the automotive domain. The current fragmentation means that the automotive OEM must trigger the development and the software developer has to accept that the potential product volume is limited. A consistent platform deployment would address both of these limitations.
    2. Multi-sourcing of a consistent but commercialized software platform. GENIVI intends to become the upstream feed for the commercialized products. GENIVI will encourage multiple commercial distributions to provide the 1st tiers and OEM with compliant alternatives.
    3. Transparency and an unprecedented level of access during development. A combination of consistency and visibility will enable a structured approach to product validation that will drastically improve efficiency across the value chain.


    What is MeeGo, and how does it relate to GENIVI?
    MeeGo is an open-source project focused on developing a Linux-based platform for consumer centric devices such as netbooks, handsets, tablets, connected-TVs and IVI. In partnership with GENIVI, MeeGo will act as an independent distribution mechanism for the first GENIVI open-source reference implementations. The combination of MeeGo and the GENIVI code will provide an automotive infotainment reference implementation that takes the best from both the consumer and automotive worlds. The automotive industry will benefit from the developer ecosystem created by the breadth of devices targeted by MeeGo and the community built up around them.

    Will GENIVI have a product certification program?
    Once GENIVI has delivered specifications and reference implementations, it will define and execute a program that enables member companies to certify products based on the GENIVI platform. This program will document a set of test specifications for use by alliance members.


    More discussion of all this and how it affects our community to come...

    Comment


    • #3
      Features Discussion

      Here's a listing of feature request listed for meego...

      [FEA] sample sirius radio integration
      [FEA] enhance meego-handset-songs to a classed audio sources
      [FEA] remove physical keyboard requirement
      [FEA] btrfs compression during installation
      [FEA] IVI Persistancy Control Manager
      [FEA] IVI Proximity
      [FEA] IVI Nobdy
      [FEA] IVI document viewer
      [FEA] Integrate EMGD 1.0 Update user mode driver components
      [FEA] MCP pluggable mass storage controls
      [FEA] media player: FM/AM radio
      [FEA] weather app
      [FEA] contacts should have routing integration
      [FEA] Terminal Mode Client Controller
      [FEA] RTP Client supporting Terminal Mode payload
      [FEA] Terminal Mode Audio
      [FEA] TmServerDevice:1 Device
      [FEA] Terminal Mode UPnP Control Point
      [FEA] Terminal Mode 1.0 RFB extension messages
      [FEA] RFB Encodings
      [FEA] Remote Framebuffer Protocol
      [FEA] Terminal Mode VNC Client
      [FEA] Smartphone Connectivity using Terminal Mode for MeeGo IVI
      [FEA] Inertia based Application control
      [FEA] BT HFP
      [FEA] BT A2DP

      While these are what's on their bugzilla site -- some don't make sense based on what IVI seems to really be... Discussion to follow.

      Comment


      • #4
        Originally posted by nasa View Post
        Here's a listing of feature request listed for meego...
        [FEA] IVI Proximity
        [FEA] IVI Nobdy
        w00t!

        While these are what's on their bugzilla site -- some don't make sense based on what IVI seems to really be... Discussion to follow.
        Which ones don't make sense?

        I just listened to the first presentation. It's exciting to see the working group form and begin to make plans.
        Former author of LinuxICE, nghost, nobdy.
        Current author of Automotive Message Broker (AMB).
        Works on Tizen IVI. Does not represent anyone or anything but himself.

        Comment


        • #5
          What is Meego IVI anyways?

          Trip -- hope to get your feedback on this...

          The IVI community is kinda split on this, although they don't realize it yet. If one looks at the forum at good amount of discussion revolves around the UI. However, if you look at the discussion from the 1st post and look at what has been released a different look appears.

          Basically, the Meego IVI is suppose to be the foundation for a systems actual IVI. Specifically, the Meego IVI doesn't include the actual UI (take a look at the post again). Which is why I noted that some of the features listed don't make sense in that context.

          Note: IVI Proximity & IVI Nobdy don't fit that category.

          So things like; remove physical keyboard requirement, IVI document viewer, media player: FM/AM radio, etc which are all UI applications don't seem to fit. Taking a look at what has been released as 1.0 & 1.1 -- UI for a car environment are barely addressed (at best is ivihome/desktop). 1.1 is mostly taking handset apps and throwing them into the IVI, which just doesn't work.

          Even though the word is out there, no one is making sure that is the understood postion. Of course, to actually test base functionality a UI of some sort is needed/helpful -- so stealing from a differnt thread maybe appropriate, but without clear guidance the community maybe confused/misguided about what to expect.

          On the flip-side, a Meego IVI with OpenMobile or OpenIce should be workable solutions.

          Comment


          • #6
            As far the XM and Sirius intergration...... A lot of people now have internet in the car, so using the online version of Sirius and XM may be a easier and better route. You can then eliminate all the hardware that was involved.

            In my install I use the XMD1000 for the main audio speakers. I also wanted the rear passengers to be able to listen to XM, but not be limited to what I am listening to. So instead I use a program called SiriusXMStreamer and embed that program into CF. Its 128k audio, so it sounds good. So now I can listen to what I want, and they can listen to what they want. So by doing the online route, you have eliminated the XM/Sirius hardware, and the cable to interface it with the PC.
            Nirwana Project, the Android/Win 7 hybrid system!

            1X Ainol Novo Flame Tab
            4X MK808b
            3x Perixx Touchpads
            3x 7 inch Screens
            1X 7 inch motorized Screen
            1x Win 7 PC

            Comment


            • #7
              Originally posted by nasa View Post
              Trip -- hope to get your feedback on this...

              The IVI community is kinda split on this, although they don't realize it yet. If one looks at the forum at good amount of discussion revolves around the UI. However, if you look at the discussion from the 1st post and look at what has been released a different look appears.

              Basically, the Meego IVI is suppose to be the foundation for a systems actual IVI. Specifically, the Meego IVI doesn't include the actual UI (take a look at the post again). Which is why I noted that some of the features listed don't make sense in that context.

              Note: IVI Proximity & IVI Nobdy don't fit that category.

              So things like; remove physical keyboard requirement, IVI document viewer, media player: FM/AM radio, etc which are all UI applications don't seem to fit. Taking a look at what has been released as 1.0 & 1.1 -- UI for a car environment are barely addressed (at best is ivihome/desktop). 1.1 is mostly taking handset apps and throwing them into the IVI, which just doesn't work.

              Even though the word is out there, no one is making sure that is the understood postion. Of course, to actually test base functionality a UI of some sort is needed/helpful -- so stealing from a differnt thread maybe appropriate, but without clear guidance the community maybe confused/misguided about what to expect.

              On the flip-side, a Meego IVI with OpenMobile or OpenIce should be workable solutions.
              I agree on all points. When I spoke with Tom, one of the working group guys, he mentioned they would be very happy to see a community developed UI for the reference IVI build. I've been working on something and trying to pool some of the other OpenICE guys but OpenICE doesn't have the developer strength it used to. Too add, there isn't enough developers in this forum and even less that are interested in working on something like this for MeeGo. It's basically just me at this point. I'd love to see other forum developers get involved.

              In other news, AMD has announced that it will support MeeGo. This may mean non-SSE3 builds and support for ATI graphics. Who knows when or what AMD will contribute to the project, but this is good news for the project as a whole. Next up: Nvidia. Yeh, I'm calling you out!
              Former author of LinuxICE, nghost, nobdy.
              Current author of Automotive Message Broker (AMB).
              Works on Tizen IVI. Does not represent anyone or anything but himself.

              Comment


              • #8
                One thing that is unclear to me is what level of dependence on QT there really is for the IVI platform. If the UI is undefined, how does QT fit in the picture? When I look the slide from post number 1, it shows a lot of stuff related to QT as part of the core OS -- which doesn't make sense...

                Have you heard anything about this? For me, I would love to run EFL on top of meego...

                Now, I should note the Openmoble could also be used, the only concern I have there is that we would not actually use the meego core functionality as that would come from OpenMobile -- which would be kinda of redundant.

                Thoughts

                Comment


                • #9
                  Following is an exchange between the Meego IVI program manager and myself -- posted for some clarification:

                  >I've had this long standing question/thoughts that I put up on the
                  > forum but haven't gotten much of a response too and was wondering
                  > what your (ie: people on the list) thoughts were:
                  >
                  > I'm a little confused... I am somewhat unsure what the IVI platform is
                  > actually going to be.
                  > I have seen (and run) the first 2 releases -- which have been described
                  > as *demo* of one sort
                  > or another. I also noted the involvment of GENIVI, which had some
                  > interesting things to say
                  > about it on their FAQs:
                  >
                  > What are GENIVI's goals?
                  >
                  > BTW: Is there a project/program manager directing what requirements IVI
                  > is going to solve (ie: who's
                  > driving the bus -- and does he know where we are heading)? I've been
                  > somewhat struggling with this
                  > question for a while.
                  >
                  > So, does anyone have any concrete idea on this? It somewhat frustrates
                  > me given I an actually a System
                  > Engineer in my real life...
                  >
                  > Nasa
                  >


                  The governance of MeeGo IVI is covered in these links:
                  http://meego.com/about/governance
                  http://wiki.meego.com/In-vehicle
                  http://meego.com/about/governance/program-office/ivi

                  As you can see from these pages, I am the MeeGo IVI project team program manager.

                  I don't think this is the right place to speculate on GenIVI goals.
                  There are some components included in the Meego releases that were previously included in Moblin releases that have been labeled as GenIVI components, but as far as we can tell nobody (in GenIVI or elsewhere) is using these components. They are being deprecated and we expect they will be replaced with well maintained components in the future.

                  Up to this point the MeeGo releases have focused on sample/demo applications and some coverage of target IVI boards. Resources have been limited and many gaps remain in all areas from platform support through middleware frameworks extending to applications. The MeeGo IVI working group has only been meeting for a few weeks. A few initial IVI specific features have been indentified, but specific development plans for these are still not firmed up. You can see the log of features requested by this query:
                  http://bugs.meego.com/buglist.cgi?cl...IVI%20Features

                  That said we are seeing increased interest from the open source community and from product vendors. We anticipate the IVI working group filling out the strategy and roadmap as well as increased developer activity in the months ahead.

                  New features may be requested at any time (create new "Feature" entries in bugs.meego.com), but generally they won't be accepted until there is an implementation that is well maintained, packaged for the MeeGo build server, considered of strategic and technical value by the MeeGo IVI community (people can vote for a feature in bugs.meego.com), and shown to integrate well with existing MeeGo components.

                  There are several pages on www.meego.com and wiki.meego.com on "how to add" components to meego.

                  The strategic direction for MeeGo IVI is determined by the MeeGo IVI working group, not by the program manager, but in general I believe MeeGo IVI is "driving the bus" to provide target platform support in MeeGo core (i.e. boots and runs robustly), Automotive enhanced or specific frameworks, and automotive hardened SW stacks with a sample or reference user experience based on industry BKMs.

                  We have a lot to do to reach these goals. The fun is just starting.

                  I'm curious what forum you put your questions to previously.

                  regards
                  Joel Clark
                  MeeGo IVI program manager


                  -----------------------------------------------------

                  Want to express my thanks to Joel for the reply

                  Comment


                  • #10
                    Originally posted by nasa View Post
                    One thing that is unclear to me is what level of dependence on QT there really is for the IVI platform. If the UI is undefined, how does QT fit in the picture? When I look the slide from post number 1, it shows a lot of stuff related to QT as part of the core OS -- which doesn't make sense...

                    Have you heard anything about this? For me, I would love to run EFL on top of meego...

                    Now, I should note the Openmoble could also be used, the only concern I have there is that we would not actually use the meego core functionality as that would come from OpenMobile -- which would be kinda of redundant.

                    Thoughts
                    Qt is not necessarily just a UI toolkit, it's a complete application framework. Both nobdy and proximity are written in Qt but neither of them have any UI. The benefit to using Qt over EFL or any other library is that all of the system services in MeeGo will be exposed through Qt APIs. This means that you can access sensors, multimedia and other platform components through a single high-level API. If you wanted to use another framework like EFL, you end up either duplicating those APIs or wrapping them -both are more work for you and offer little advantage.

                    For example, there are Qt mobility APIs for routing and displaying a map on the screen. If you wanted to use EFL, you would either have to create a wrapper for these or make your own from scratch. Or you could write a Qt application and with a few lines have a navigation app .

                    MeeGo.com only provides references. You can say a reference is a demo of sorts. For example, the whole point of the handset UX (user experience) is to provide a set of example applications that use the underlying Qt-based frameworks and show off the features of the platform. The meego ux from meego.com isn't meant to be used in a product although an OEM may opt to do so at his discretion. Or the OEM may opt to use their own user experience and ditch the UX that comes in the reference. This is the case in harmattan, Nokia's version of MeeGo which they will release as part of a product.
                    Former author of LinuxICE, nghost, nobdy.
                    Current author of Automotive Message Broker (AMB).
                    Works on Tizen IVI. Does not represent anyone or anything but himself.

                    Comment


                    • #11
                      Originally posted by tripzero View Post
                      For example, there are Qt mobility APIs for routing and creating a map. If you wanted to use EFL, you would either have to create a wrapper for these or make your own from scratch. Or you could write a Qt application and with a few lines have a navigation app .
                      Careful there.....Qts Maps and Navigation APIs allow a navigation engine to provide a map to other Qt components. They don't provide any type of mapping or navigation, that requires a third party engine (which they call a service) of which none exist. Its more of a strong data type then anything functional.

                      As far as it being not just a UI framework..true it is an application framework but really just an option for developing a UX layer on. Other UX layers could use qt as well or they could use their own frameworks. Nothing about meego's design or anything i've seen in any plans requires inter-plugin communication or data sharing. afaik
                      openMobile - An open source C# Front End (why choose openMobile?)
                      - Always Recruiting Developers -
                      Like what you see? Donations are always welcome

                      Comment


                      • #12
                        Originally posted by justchat_1 View Post
                        Careful there.....Qts Maps and Navigation APIs allow a navigation engine to provide a map to other Qt components. They don't provide any type of mapping or navigation, that requires a third party engine (which they call a service) of which none exist. Its more of a strong data type then anything functional.

                        As far as it being not just a UI framework..true it is an application framework but really just an option for developing a UX layer on. Other UX layers could use qt as well or they could use their own frameworks. Nothing about meego's design or anything i've seen in any plans requires inter-plugin communication or data sharing. afaik
                        Right now there is an OVI/Navteq service backend for developers to use. There is also an open solution in the works that will likely be included in the reference platforms.
                        Former author of LinuxICE, nghost, nobdy.
                        Current author of Automotive Message Broker (AMB).
                        Works on Tizen IVI. Does not represent anyone or anything but himself.

                        Comment


                        • #13
                          Originally posted by tripzero View Post
                          MeeGo.com only provides references. You can say a reference is a demo of sorts. For example, the whole point of the handset UX (user experience) is to provide a set of example applications that use the underlying Qt-based frameworks and show off the features of the platform. The meego ux from meego.com isn't meant to be used in a product although an OEM may opt to do so at his discretion. Or the OEM may opt to use their own user experience and ditch the UX that comes in the reference. This is the case in harmattan, Nokia's version of MeeGo which they will release as part of a product.
                          I don't think that quite right... From a forum post (again PM):

                          Your ideas align with some of the original ideas for IVIhome/IVItaskbar, which included selecting items from the scrolling taskbar could result in popout of a new taskbar with addition options to the original item select. The IVIhome/taskbar is a sample of possible automotive taskbar. It was not designed by professional designers, rather the rough ideas of a couple of developers. Most of the applications included in MeeGo IVI are borrowed from other devices, and have not been adjusted in any way to fit the IVI style, homescreen or display. They are there only to show the underlaying capabilities of the platform are functional. Thus they are useful for validation of the system features. The only applications that have been developed specifically for MeeGo IVi are the IVIhome/Taskbar and the handsfree dialer.

                          And here's more from our email exchange:

                          The GenIVI goals are specific to GenIVI. The MeeGo IVI working group is very interested in work done by GenIVI and any opportunities to provide mutual alignment and support. However GenIVI and MeeGo IVI are not one entity and GenIVI goals should not be interpreted as the sum total of MeeGo IVI goals. The MeeGo IVI working group will define "what MeeGo IVI would look like"

                          For example if you look at the charter of MeeGo working groups, the focus is on the user experience

                          (bold is mine) My take from this, specifically for IVI, is that it really hasn't started yet. While there are feature request on the bug.meego.com site, they don't represent actually requirements (as of yet) as they haven't been vetted by the project team. But the end game is going to be a *fully* operational product -- one that can/would be run in a car. And given his last statement about "working groups", it seems this is generally true (ie: for all meego platforms)

                          Comment


                          • #14
                            Originally posted by nasa View Post
                            I don't think that quite right...
                            Bottom line is that in order to even remotely look like a compelling platform and show off platform features, you need a compelling user experience. I think this is essentially what is being said in your discussions. You can't have an awesome UX without solid APIs and you can't really convince people to use your APIs if they don't see it working in a compelling UX.
                            Former author of LinuxICE, nghost, nobdy.
                            Current author of Automotive Message Broker (AMB).
                            Works on Tizen IVI. Does not represent anyone or anything but himself.

                            Comment


                            • #15
                              When you see MeeGo in BMW or whoever's product based on meego ivi, you probably won't see the same UX as you see in the reference, open source version. However, BMW's build may still be called and considered meego compliant (note that the definition of compliance for IVI has not landed).
                              The problem is the entire fully independent app design of meego makes this impossible. You would need to specially compile each individual app (and if you remember from our "what ui design is needed for in vehicle" or whatever it was called i feel this is the reason meego has 0 chance of success).
                              openMobile - An open source C# Front End (why choose openMobile?)
                              - Always Recruiting Developers -
                              Like what you see? Donations are always welcome

                              Comment

                              Working...
                              X