Received: by 10.58.4.35 with SMTP id h3mr791965veh.20.1344696459732;
        Sat, 11 Aug 2012 07:47:39 -0700 (PDT)
X-BeenThere: pandaboard@googlegroups.com
Received: by 10.220.141.210 with SMTP id n18ls2093536vcu.2.gmail; Sat, 11 Aug
 2012 07:47:37 -0700 (PDT)
Received: by 10.58.4.35 with SMTP id h3mr791951veh.20.1344696457696;
        Sat, 11 Aug 2012 07:47:37 -0700 (PDT)
Received: by 10.58.4.35 with SMTP id h3mr791949veh.20.1344696457686;
        Sat, 11 Aug 2012 07:47:37 -0700 (PDT)
Return-Path: <robdcl...@gmail.com>
Received: from mail-vb0-f48.google.com (mail-vb0-f48.google.com [209.85.212.48])
        by gmr-mx.google.com with ESMTPS id y4si270790vds.2.2012.08.11.07.47.37
        (version=TLSv1/SSLv3 cipher=OTHER);
        Sat, 11 Aug 2012 07:47:37 -0700 (PDT)
Received-SPF: pass (google.com: domain of robdcl...@gmail.com designates 209.85.212.48 as permitted sender) client-ip=209.85.212.48;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of robdcl...@gmail.com designates 209.85.212.48 as permitted sender) smtp.mail=robdcl...@gmail.com; dkim=pass header...@gmail.com
Received: by vbme21 with SMTP id e21so3003564vbm.35
        for <pandaboard@googlegroups.com>; Sat, 11 Aug 2012 07:47:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        bh=VDVTUHeIV+YDGoo+7Ui5o6RVbKyje4A8Vo/1GBnf02E=;
        b=EFqxpB2m1Z5+Z63IQx/b0PfWKyIIsI9r1lwNMW5Bky539Xm8vBc+2ZHcShokdxV7Lf
         C6arVVCuqZHFa9Rig9cXPkfH4JQPuTivSvgrbXMLVya47WFstYqQulzkaJOxIzhnhuwj
         6bv0QejC5fYhzI663zNhNWYzm1NdVJuHa/ctJHP1cDjRwxTvLWf/dUfhlsFDxtuuhS0Q
         TBL/ehEEMFdj4pBgB5DKrSi2cHANVi29ThMtIOocmL4El4d4GIg57yB7F6a3VMJP1TfE
         7UT9xy+OQrcGlnsVEp5x+pfTphR46jFaN8WTPGcadPwyfsY1z06dD8WtwM2D5o09sC9y
         x9bw==
MIME-Version: 1.0
Received: by 10.220.155.203 with SMTP id t11mr5112380vcw.36.1344696457583;
 Sat, 11 Aug 2012 07:47:37 -0700 (PDT)
Received: by 10.220.41.74 with HTTP; Sat, 11 Aug 2012 07:47:37 -0700 (PDT)
In-Reply-To: <f6a7bdf1-a796-4dcd-94a0-eb56b3b73760@googlegroups.com>
References: <eaf2c9f3-21a4-4ce6-aa3f-5f5c22c308c3@googlegroups.com>
	<CAAMy4UTRKx+5c70RTzEkQEyPGD4rjS8d480vFLVVboUh2Eh...@mail.gmail.com>
	<5E8EAD7A0F20034FA79ADBD3036305BE04207...@DFLE34.ent.ti.com>
	<f6a7bdf1-a796-4dcd-94a0-eb56b3b73760@googlegroups.com>
Date: Sat, 11 Aug 2012 09:47:37 -0500
Message-ID: <CAF6AEGvvRyhby+CA4=OCu33WeK2T4Ed226MGh3Q+FR575kH...@mail.gmail.com>
Subject: Re: [pandaboard] OMAP5 Community Board Wishlist
From: Rob Clark <robdcl...@gmail.com>
To: pandaboard@googlegroups.com
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 10, 2012 at 9:09 AM, Emmanuel Deloget <log...@free.fr> wrote:
>>
>>
>> -          Have the board either 100% open or fully supported, don=92t g=
ive
>> answers like =93not available or license restrictions=94
>
>
> The most important here is "fully supported". Even if some IP vendors do =
not
> want to open their code, TI must make sure that every bit of functionnali=
ty
> is supported by the shipped blobs. For instance, it's not possible (or
> excessively difficult) to have OpenGL ES and HD video decoding without X =
on
> the current Panda (this should not be a prerequisite).

It is certainly a challenge to support every possible permutation of
windowing system, application that could use hw video encode/decode,
etc.  We'd like to be able to support non-X11 environments as well,
but well.. some limitation about # of hours in a day and we need to
sleep for at least a couple of them :-P

Correct me if I'm wrong, but I *think* we have the most comprehensive
gpu and video encode/decode support for linux, compared to any of the
other community ARM boards.  I think snowball and some of the others
may include x11+gles but I don't think they have hw video decode.  We
do try to support as much as possible.

And this should improve once we are ready to push wayland/weston
support (which we are getting closer to).. weston is using gles
without x11, using a combination of kms/gbm and some egl extensions to
go between egl-images and buffer objects that you can pass to
drmModePageFlip(), etc.  An application that wished to bypass X11
could do the same.  It is a bit more complex than nullws, but this is
out of necessity as it is a lot more powerful (can deal with hotplug,
multiple displays, using hw overlays to bypass GPU when appropriate,
etc).

Obviously it would be much easier for us if we could just give out the
src code for the gles stuff.. if someone wanted something that we
didn't have time to implement ourselves, well they could always send a
patch.  Sadly this is not an option.  If it was, we would have done it
a long time ago.

BR,
-R