won't someone please think of the users!?
just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time There has been some feedback, for example on #pandaboard, that the monthly release cycle is confusing and detrimental for folks looking for something working and stable, and not necessarily bleeding edge, the question is, "should I upgrade?", "what is fixed and what is now broken?". Linaro is doing some great upstream work, and enabling features on these boards, and it is good to showcase that, but I'm not really sure the best way to do this is rush that into the next monthly release and break things for all the new users of their shiny new xyz-board. I tend to think that part of the problem is that the cadence of monthly releases is too fast for any sort of stability. Perhaps we should think more along the lines of releases roughly every quarter (potentially with "beta"s in between). I don't think we should strictly adhere to a time based release cycle, but we should call it a final/stable release when it actually is so. There is a reason that the linux kernel uses an approx 3 month release cycle, but doesn't stick to that dogmatically when things aren't really at release quality yet. But, we do still need a place for latest-and-greatest bleeding edge for folks who want to check out what we are working on. One approach, for example for ubuntu releases, we could have a "release" and "trunk" PPA for bleeding-edge.. that way folks looking for bleeding-edge can get it, and folks looking for "it just works" are not screwed. I'm not quite sure what android equivalent would be, but I guess we could figure something out. This gives folks in board specific channels like #pandaboard who are trying to help new users something to reliably point them at without having to worry if they are giving bad advice to recommend a linaro filesystem. And updates do not have to be tied to a time-based schedule. If something is broken for feature x for board y in the release PPA, then as soon as it is fixed (and if it doesn't break board z), then push an update to the release PPA. But maybe big new features shouldn't immediately go to the release PPA without some soak time first in the trunk PPA. It is great to be enabling new features, but for someone new to the arm platform I don't want to just frustrate and scare them off. Also, I wonder if we should split #linaro, either into #linaro-devel and leave #linaro as a place that users can come to for help, or setup a separate #linaro-users? This way we aren't just dumping out new releases with nowhere for users to turn to for help.. (Well, they can always come to #linaro but I guess this would help with the signal-to-noise..) BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: won't someone please think of the users!?
On Fri, Apr 6, 2012 at 4:05 AM, Wookey wrote: > +++ Clark, Rob [2012-04-05 21:10 -0500]: >> just some random thoughts on our release model, etc.. I've been >> meaning to write up for a while but haven't had time >> >> There has been some feedback, for example on #pandaboard, that the >> monthly release cycle is confusing and detrimental for folks looking >> for something working and stable, and not necessarily bleeding edge, > > You make some good points. > > The fundamental question really is 'are we a distro or not'? If linaro > is not a distro then no-one should be expecting stable releases - we > are a technology showcase, and developer quick-start mechanism, and > the existing process seems reasonably appropriate for that, but if we > are expecting people to actually base real work off our outputs, then > he's right and we ought to change some things. yeah, I think this is actually a very good way to describe the problem.. Currently, people *think* we are a distro, and I guess you could say this is the source of the confusion. Someone new to arm world gets their shiny new xyz-board and isn't sure whether to use an ubuntu 11.10 release, or linaro 12.01 release, etc. Maybe the solution, to put it in management buzzword-speak, is the need for some "crisp messaging about what our builds are". > The original model was that we just sent things upstream and people > who wanted a stable platform used whatever distro they wanted. But by > putting out images and encouraging people to use them we seem to be > increasingly viewed as a distro and so users will expect distro levels > of integration testing and stability. > > I think we should continue to resists 'distroness', concentrate on > upstreaming and discourage the use of our releases for anything other > than development, but it seems to me that things are headed in exactly > the opposite direction at the moment. I certainly don't want to distract from the upstream aspect of what we do. (And to be honest, I am more on the upstreaming side of things.. the distro side of things is certainly outside my area of expertise so it's quite possible that everything I say on the subject is complete and utter BS.. I just saw that it was causing confusion so thought I needed to start the discussion) > There is a fundamental problem of timing - it takes several months > longer, sometimes years, for people to get what we are doing via a > distro, and that's too long for many of them, which is where the > pressure comes from. We are all aware of that tension. This is part of the problem.. even a 6 month cycle for ubuntu is forever in arm-years. This was partly why I was thinking of a 3(ish) month cycle. Maybe not necessarily only doing a build every 3 months, but having the focus of every 3rd month build be something that is more stable, and something we wouldn't be afraid to give new users. So if joe-new-user wants something a bit more enabled than 11.10, we could tell them, here, go use ubuntu 12.q1. But maybe I speak complete crack ;-) But if we should only do technology showcases, I'm not even sure the approach of popping out one build every month really works for everything there. At least not for some of the larger topics. Maybe we should be thinking more along the lines of builds for different work topics.. Well, the one I'm familiar with is UMM/dmabuf, but that is touching many areas and takes much more than a month to get all the pieces (display, gles, multimedia, etc) in place, as well as cooperation from member companies for the evil binary blob bits. If we'd pulled that into a monthly release a month or two ago, you would have completely lost gfx and multimedia accel. Well, from TI side, I know they are busily trying to pull all the bits into a 3.3 kernel and TI PPA to enable this for ubuntu/linaro 12.04 (well, still a few bits missing to have all the multimedia, eglImage xbmc/ubuntu-tv stuff, so it won't immediately have feature parity with the old stuff).. I suppose Rome wasn't built in a day (or month). But on the other hand, doing N*M build for N different topics and M different member boards perhaps doesn't really scale well. So I'm not really sure what the best solution is. BR, -R > So are we a distro now or not? > > Wookey > -- > Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM > http://wookware.org/ > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: won't someone please think of the users!?
On Fri, Apr 6, 2012 at 2:59 PM, Nicolas Pitre wrote: > On Fri, 6 Apr 2012, Ricardo Salveti wrote: > >> On Fri, Apr 6, 2012 at 6:05 AM, Wookey wrote: >> > The fundamental question really is 'are we a distro or not'? If linaro >> > is not a distro then no-one should be expecting stable releases - we >> > are a technology showcase, and developer quick-start mechanism, and >> > the existing process seems reasonably appropriate for that, but if we >> > are expecting people to actually base real work off our outputs, then >> > he's right and we ought to change some things. >> >> It might be the same thing, but for me the question is really "do we >> care about users and we want people to use our LEBs?". If we assume >> the LEBs are just a bunch of evaluation images to be used internally >> to help improving the development and testing, then you could simply >> say that we're not any kind of distro. >> >> Now if we decide to have people using and consuming our LEBs (what I >> believe we do), then we need to think a bit further, and assume some >> extra responsibilities. We don't want to be a full distro, as we want >> to be flexible enough to break things once a while, but we really need >> to be aware that once we get users running our images, they will >> *expect* some sort of stability, putting us back as we were a distro >> :-) > > Stability is not sufficient. Users will also expect support, updates, > and security fixes, etc. And the more stable our stuff looks, the more > users and user demands we'll get. Fulfilling those user *expectations* > is hard and costly. Some companies are basing their entire business on > that, and they do a really great job already. > > We certainly don't shine at being a distro, and IMHO we shouldn't even > try. If some people want the latest cool stuff we provide that's fine, > but they should expect a shaky world. Existing distro people out there > will pick up our work too and stabilize it. In fact, they are > encouraged to do so. > > Stabilization takes time, which is why there is a delay before our stuff > is available through existing distros. There is simply no way around > that. Stable and latest bleeding edge are simply not compatible. If > Linaro is to produce stabilized releases, we'll introduce extra delays > too, and we'll consume a significant amount of development resources > doing that. > > Therefore I don't think we should duplicate what distro people are > already doing. That shouldn't be where our focus is. Expectations to > users should probably be clarified as well. That is fair.. there is no point duplicating what distro folks are already doing. It might be nice to do a better job of folding back bits and pieces of what we do into (for example) ubuntu PPA's.. for example, I think a number of people are trying linaro builds just because they want xbmc, not because they care about various other bleeding edge bits. Although, other than OMAP, are there ubuntu PPA's to get graphics, etc, accel for other member company platforms? Ie. when someone like the FXI cotton candy folks come along looking for a filesystem they can use on their product (where presumably they care more about enablement than bleeding edge), could we tell them to use ubuntu or AOSP or whatever? I'm just wondering if there is a good "one size fits all" answer.. if there isn't a member company supported PPA for ubuntu where you can get the gfx and/or multimedia blobs, then the only-bleeding-edge-devel filesystems approach might be leaving a bit of a gap for someone trying to make a product (which is, in the end, what we care about). BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 3.3 kernel from TI landing teams and powervr problems.
There is an omap_drv.so which should be the xorg driver to load.. it will attempt to load (if present) omap_pvr_drv.so as a submodule for EXA accel. I'm not entirely sure why it is named pvr_drv.so in your filesystem, but from list of symbols it seems to match what I would expect to be omap_pvr_drv.so BR, -R On Mon, Apr 16, 2012 at 8:45 AM, Martin Ertsås wrote: > Hi. > > I am not 100% sure this is the correct place to ask, but since I know at > least Ricardo Salveti are working on these drivers for omap4, and I > haven't heard anything from the ppa's mailing list, I try to ask here. > If this was completely wrong I'm sorry, but would still appreciate a > hint as to where to ask and who to contact. > > We are compiling what is now HEAD in the tilt-3.3 branch from the TI > landing team. To compile the module needed for the powervr drivers, we > had to get the pvr-omap4-dkms-1.7.15 and pvr-omap4-1.7.15 from > http://ppa.launchpad.net/tiomap-dev/omap-trunk/ubuntu/pool/main/p/ > > We downloaded the tar.gz from those, extracted them and compiled them. > Problem starts when we boot the board and try to run startx. The xorg > config which comes with the later package is loaded, but when trying to > start X I get the error: > > (EE) Failed to load /usr/lib/xorg/modules/drivers/pvr_drv.so: > /usr/lib/xorg/modules/drivers/pvr_drv.so: undefined symbol: OMAPFinishAccess > > None of the libraries in pvr-omap4 contains this symbol, so I'm > wondering if I'm doing something wrong, or if there is something wrong > with the binary? > > When comparing to the library from rsalveti, from > people/rsalveti/pvr-omap4.git, I see that the dynsym table contains 232 > entries, but there are only 64 entries in the same table in the other > library. Is this correct, or should there be more entries in the 1.7.15 > library? > > Both the Xorg log and the readelf output from both libraries are > attached, if you have questions/need more info, please do not hesitate > to ask. > > Thank you in advance for the help, and thank you for the great work you > put in for making embedded Linux better. > > Best regards > Martin Ertsaas > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 3.3 kernel from TI landing teams and powervr problems.
On Mon, Apr 16, 2012 at 10:07 AM, Martin Ertsås wrote: > > True, I renamed that file, since I got the message that it couldn't find > module omap. First I renamed it to omap_drv.so, which gave me the same > error, then I tried pvr_drm.so which is the attatched logfile. Both of them > are the omap_pvr_drv.so file. yeah, you probably shouldn't really rename the xorg modules.. the xorg module loader will look for symbols within the driver matching the name. I expect omap_drv.so is in a different package (maybe missing dependency?).. it is opensrc, anyways, you can rebuild it from the git tree at freedesktop.org http://cgit.freedesktop.org/xorg/driver/xf86-video-omap/ git://anongit.freedesktop.org/xorg/driver/xf86-video-omap BR, -R > Should there be a omap_drv.so file in the same directory as the > omap_pvr_drv.so file? In that case there isn't, the omap_pvr_drv.so file is > the only one in that directory when extracting that tarball. Actually there > is no file at all named omap_drv.so: > > $ find . -name "omap_drv.so" > > return nothing, while just omap gives > > $ find . -name "omap*" > ./usr/lib/debug/usr/lib/xorg/modules/drivers/omap_pvr_drv.so > ./usr/lib/xorg/modules/drivers/omap_pvr_drv.so > > which is the same as "*drv*" gives. > > - Martin > > > > On 04/16/12 16:42, Clark, Rob wrote: >> >> There is an omap_drv.so which should be the xorg driver to load.. it >> will attempt to load (if present) omap_pvr_drv.so as a submodule for >> EXA accel. I'm not entirely sure why it is named pvr_drv.so in your >> filesystem, but from list of symbols it seems to match what I would >> expect to be omap_pvr_drv.so >> >> BR, >> -R >> >> >> On Mon, Apr 16, 2012 at 8:45 AM, Martin Ertsås >> wrote: >>> >>> Hi. >>> >>> I am not 100% sure this is the correct place to ask, but since I know at >>> least Ricardo Salveti are working on these drivers for omap4, and I >>> haven't heard anything from the ppa's mailing list, I try to ask here. >>> If this was completely wrong I'm sorry, but would still appreciate a >>> hint as to where to ask and who to contact. >>> >>> We are compiling what is now HEAD in the tilt-3.3 branch from the TI >>> landing team. To compile the module needed for the powervr drivers, we >>> had to get the pvr-omap4-dkms-1.7.15 and pvr-omap4-1.7.15 from >>> http://ppa.launchpad.net/tiomap-dev/omap-trunk/ubuntu/pool/main/p/ >>> >>> We downloaded the tar.gz from those, extracted them and compiled them. >>> Problem starts when we boot the board and try to run startx. The xorg >>> config which comes with the later package is loaded, but when trying to >>> start X I get the error: >>> >>> (EE) Failed to load /usr/lib/xorg/modules/drivers/pvr_drv.so: >>> /usr/lib/xorg/modules/drivers/pvr_drv.so: undefined symbol: >>> OMAPFinishAccess >>> >>> None of the libraries in pvr-omap4 contains this symbol, so I'm >>> wondering if I'm doing something wrong, or if there is something wrong >>> with the binary? >>> >>> When comparing to the library from rsalveti, from >>> people/rsalveti/pvr-omap4.git, I see that the dynsym table contains 232 >>> entries, but there are only 64 entries in the same table in the other >>> library. Is this correct, or should there be more entries in the 1.7.15 >>> library? >>> >>> Both the Xorg log and the readelf output from both libraries are >>> attached, if you have questions/need more info, please do not hesitate >>> to ask. >>> >>> Thank you in advance for the help, and thank you for the great work you >>> put in for making embedded Linux better. >>> >>> Best regards >>> Martin Ertsaas >>> >>> ___ >>> linaro-dev mailing list >>> linaro-dev@lists.linaro.org >>> http://lists.linaro.org/mailman/listinfo/linaro-dev >>> > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 3.3 kernel from TI landing teams and powervr problems.
On Tue, Apr 17, 2012 at 2:52 AM, Martin Ertsås wrote: > Thanks to this, I got x running, problem is that I don't seem to have > direct rendering. First it complained that glx could not be loaded. When > adding the glx extensions from the xserver, I get some problems with > AIGLX. It sais that /usr/lib/dri/omap_dri.so could not be found. Is this > something I should have with these three packages, and I have not > compiled everything I should, or is it a fourth package which I haven't > installed? > > Searched through the xf86-video-omap, and doesn't seem to build anything > but omap_drv.so, but it do contain a file omap_dri2.c. Should I let the > glx warning appear, and just ignore it maybe? Do the driver provide dri2 > by itself? This is fine, you can ignore the glx warning. Only desktop GL (and not GLES) supports GLX. I suppose maybe I should submit a patch in upstream xserver tree to make that warning sound less dire, because it confuses a lot of people Even with DRI2, you'll need the client side GL libs to do much, but you can find those from the PPA that Nicolas pointed at. BR, -R > Thank you so much for your help so far. > > - Martin > > On 04/17/12 01:17, Clark, Rob wrote: >> On Mon, Apr 16, 2012 at 10:07 AM, Martin Ertsås wrote: >>> True, I renamed that file, since I got the message that it couldn't find >>> module omap. First I renamed it to omap_drv.so, which gave me the same >>> error, then I tried pvr_drm.so which is the attatched logfile. Both of them >>> are the omap_pvr_drv.so file. >> yeah, you probably shouldn't really rename the xorg modules.. the >> xorg module loader will look for symbols within the driver matching >> the name. >> >> I expect omap_drv.so is in a different package (maybe missing >> dependency?).. it is opensrc, anyways, you can rebuild it from the git >> tree at freedesktop.org >> >> http://cgit.freedesktop.org/xorg/driver/xf86-video-omap/ >> git://anongit.freedesktop.org/xorg/driver/xf86-video-omap >> >> >> BR, >> -R >> >> >>> Should there be a omap_drv.so file in the same directory as the >>> omap_pvr_drv.so file? In that case there isn't, the omap_pvr_drv.so file is >>> the only one in that directory when extracting that tarball. Actually there >>> is no file at all named omap_drv.so: >>> >>> $ find . -name "omap_drv.so" >>> >>> return nothing, while just omap gives >>> >>> $ find . -name "omap*" >>> ./usr/lib/debug/usr/lib/xorg/modules/drivers/omap_pvr_drv.so >>> ./usr/lib/xorg/modules/drivers/omap_pvr_drv.so >>> >>> which is the same as "*drv*" gives. >>> >>> - Martin >>> >>> >>> >>> On 04/16/12 16:42, Clark, Rob wrote: >>>> There is an omap_drv.so which should be the xorg driver to load.. it >>>> will attempt to load (if present) omap_pvr_drv.so as a submodule for >>>> EXA accel. I'm not entirely sure why it is named pvr_drv.so in your >>>> filesystem, but from list of symbols it seems to match what I would >>>> expect to be omap_pvr_drv.so >>>> >>>> BR, >>>> -R >>>> >>>> >>>> On Mon, Apr 16, 2012 at 8:45 AM, Martin Ertsås >>>> wrote: >>>>> Hi. >>>>> >>>>> I am not 100% sure this is the correct place to ask, but since I know at >>>>> least Ricardo Salveti are working on these drivers for omap4, and I >>>>> haven't heard anything from the ppa's mailing list, I try to ask here. >>>>> If this was completely wrong I'm sorry, but would still appreciate a >>>>> hint as to where to ask and who to contact. >>>>> >>>>> We are compiling what is now HEAD in the tilt-3.3 branch from the TI >>>>> landing team. To compile the module needed for the powervr drivers, we >>>>> had to get the pvr-omap4-dkms-1.7.15 and pvr-omap4-1.7.15 from >>>>> http://ppa.launchpad.net/tiomap-dev/omap-trunk/ubuntu/pool/main/p/ >>>>> >>>>> We downloaded the tar.gz from those, extracted them and compiled them. >>>>> Problem starts when we boot the board and try to run startx. The xorg >>>>> config which comes with the later package is loaded, but when trying to >>>>> start X I get the error: >>>>> >>>>> (EE) Failed to load /usr/lib/xorg/modules/drivers/pvr_drv.so: >>>>> /usr/lib/xorg/
Re: PowerVR, 3.3 kernel and omap_drm
On Thu, May 3, 2012 at 7:29 AM, Martin Ertsås wrote: > Hi. > > I have gotten a lot of help from you guys getting the PowerVR drivers up > and running with the 3.3 kernel on the Pandaboard ES. Problem now is > that all I tested then, was that X was running. After some more work, we > tried out EGL, and found out that this is not working. > > The 3.3 kernel I'm using is revision > f8e851d03e884b60b5207f59a342da9cafdb415f from tilt-3.3 from the > ti-landing team. I'm using the PowerVR drivers in > http://ppa.launchpad.net/tiomap-dev/omap-trunk/ubuntu/pool/main/, that > is pvr-omap4_1.7.15.0.1.57 and pvr-omap4-dkms_1.7.15.0.1.54. I'm also > using the libdrm, libdri2 and xorg server from the same place, using the > versions from: > https://launchpad.net/~tiomap-dev/+archive/omap-trunk?field.series_filter=precise > > Problem is, when trying to run something using EGL, I get the output from: > http://pastebin.com/e5deVmiD > > Running it through gdb on the device, I see that it segfaults in > omap_bo_handle in /usr/lib/libdrm_omap.so.1 any chance you can use current upstream libdrm (http://cgit.freedesktop.org/mesa/drm)? there was a fix for this issue.. I guess what you are using has an earlier version of libdrm_omap patches compared to what is upstream.. BR, -R > This file is compiled, using the patches listed in debian/patches/series > in the latest commit from git://gitorious.org/ubuntu-omap/libdrm.git, > and with configure arguments: > > --enable-omap-experimental-api > --enable-udev > --enable-libkms > --disable-radeon > > Any ideas on what might be wrong or what I can try? I have tried copying > the libdrm_omap binary from the ppa, as it looks like that might be at > fault, but no luck. > > Best Regards > Martin Ertsas > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 11.07 oprofile on panda busted?
Could you try also adding 'nohz=0' to bootargs to disable tickless scheduler? Depending on what is the default in current linaro kernel, this might help.. BR, -R On Mon, Aug 29, 2011 at 1:57 PM, Tom Gall wrote: > > An update on my oprofile adventures with panda. > > I did add the kernel param as Nicolas suggested and am getting a > little more data out of oprofile on panda but it's still pretty awful > as the resolution of the samples is quite poor. > > This data for instance was gathered over 5 runs of djpeg crunching on > a 1920x1280 jpeg image: > > CPU: CPU with timer interrupt, speed 0 MHz (estimated) > Profiling through timer interrupt > samples % image name symbol name > 29 34.5238 libjpeg.so.62.0.0 decode_mcu > 27 32.1429 libjpeg.so.62.0.0 h2v2_fancy_upsample > 8 9.5238 libjpeg.so.62.0.0 jsimd_idct_islow_neon > 7 8. libc-2.13.so /lib/arm-linux-gnueabi/libc-2.13.so > 7 8. libjpeg.so.62.0.0 jsimd_ycc_extrgb_convert_neon > 4 4.7619 libjpeg.so.62.0.0 decompress_onepass > 1 1.1905 libjpeg.so.62.0.0 sep_upsample > 1 1.1905 no-vmlinux /no-vmlinux > > That's not a lot of samples given the time involved. Worse there's no > way to adjust the timer up or down to adjust the number of samples > being captured. It really hurts the usefulness of oprofile for looking > at performance problems in user space code on arm which is what I'm > trying to do in support of the upstream libjpeg-turbo community. > > Siarhei Siamashka for instance has also noted this. See > http://ssvb.github.com/2011/08/23/yet-another-oprofile-tutorial.html > (scan down to ARM Cortex-A8 performance monitoring) > > Not being wise to latest greatest in oprofile kernel mods, perhaps > there's already a solution here... if so I'd love to hear it. > > On Mon, Aug 29, 2011 at 9:23 AM, Christian Robottom Reis > wrote: > > On Fri, Aug 26, 2011 at 11:10:11AM -0500, Tom Gall wrote: > >> I'll give that a try. Still, oprofile ought to work out of the box > >> without fiddling. > > > > That's exactly how I feel. If Nicolas is right, what causes this to > > depend on the kernel's counter selection, and why can't we figure out > > what to use in runtime? > > -- > > Christian Robottom Reis, Engineering VP > > Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 > > Linaro.org: Open Source Software for ARM SoCs > > > > > > -- > Regards, > Tom > > "We want great men who, when fortune frowns will not be discouraged." > - Colonel Henry Knox > Linaro.org │ Open source software for ARM SoCs > w) tom.gall att linaro.org > w) tom_gall att vnet.ibm.com > h) tom_gall att mac.com > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ACTIVITY] Graphics WG status report - wk34.2011 (20110822-20110826)
On Wed, Aug 31, 2011 at 7:19 AM, Dechesne, Nicolas wrote: > > > On Wed, Aug 31, 2011 at 1:08 PM, Ilias Biris wrote: >> >> Also note the development on MM: Jesse is preparing a GIT tree to >> contain the patches available, including components from the >> Video-Multimedia side (eg OMAP DRM driver (maybe others too), >> xf86-video-omap open source xorg driver). The tree can be made available >> as a meta-pkg for the Linaro main release in September (add-on "use at >> own risk" since all this is work still in progress and not upstreamed >> completely). Details on the tree and how to use it will come during >> September. > > note that the OMAP DRM driver will be merged into the TI landing team kernel > since this is what we plan to use for 11.10/11.11 releases. note that what > will be in the LT tree is the OMAP DRM *without* the GEM stuff since we are > not planning to use the new open source X driver in this timeframe. > fwiw we were talking about having some sort of UMM overlay/add-on on top of base filesystem, which added updated kernel, opensrc xorg driver, and other UMM related bits.. I assume it will take a few months, I think, to get it all working together and to same stability/performance/functionality levels as old stuff, hence the add-on approach. Well, maybe this is an over-paranoid view, but there are enough things changing that I wouldn't assume that it will come out of the oven fully baked the first go BR, -R > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Fwd: [gst-devel] Camerabin2 Prototype and IRC Meeting
in case any of the multimedia/middleware folks interested in camerabin2 didn't notice this email from gst-devel list: -- Forwarded message -- From: Thiago Sousa Santos Date: Fri, Dec 3, 2010 at 11:30 PM Subject: Re: [gst-devel] Camerabin2 Prototype and IRC Meeting To: Discussion of the development of GStreamer < gstreamer-de...@lists.sourceforge.net> On Thu, 2010-12-02 at 12:07 -0300, Thiago Sousa Santos wrote: > Hello, > > As mentioned some time ago, we started planning camerabin2. > > The good news is that a small prototype is ready at > http://gitorious.org/gstreamer-camerabin2/gst-plugins-bad > > It is as simple as it gets, being able to take pictures, record videos > and showing a viewfinder. Feedback, code review, patches, tests are > welcome. I'm currently trying to get the code in shape to push it as an > experimental plugin into -bad module. > > I'd like arrange meeting with people interested in camerabin2 to discuss > desired features and problems with this new design. I'm already poking > some people that mentioned interest to set up a date and time. We'd like > to do this soon, so expect it to be early next week (Monday or Tuesday). Based on the feedback I got from the interested people and their timezones: http://www.timeanddate.com/worldclock/meetingtime.html?day=7&month=12&year=2010&p1=101&p2=209&p3=64&p4=37 I guess 14PM UTC, Tuesday is a nice option. We'd meet on IRC on #camerabin2. Any major problems with this? > > Details on camerabin2 design are on the wiki: > http://www.gstreamer.net/wiki/CameraBin > > -- > Thiago > > > > -- > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > ___ > gstreamer-devel mailing list > gstreamer-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ gstreamer-devel mailing list gstreamer-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [gst-devel] Camerabin2 Prototype and IRC Meeting
Hi Sachin, Thiago has pulled in my 3-port src bin patch into the camerabin2 plugin.. only difference is for now everything is in gst/camerabin2 (whereas the basecamsrc would need to be in gst-libs for it to be extended outside of the camerabin2 plugin). I'm not entirely sure why this was changed, but it should be an easy thing to change back. BR, -R On Mon, Dec 6, 2010 at 4:40 AM, Sachin GUPTA wrote: > Hi Rob, > >This doesnot seem to be based upon 3 port camera src bin that was in > your branch.Is it something planned in future or there is someother plan. > > Thanks > Sachin > > -- > *From:* linaro-dev-boun...@lists.linaro.org [mailto: > linaro-dev-boun...@lists.linaro.org] *On Behalf Of *Clark, Rob > *Sent:* Sunday, December 05, 2010 11:00 PM > *To:* linaro-dev@lists.linaro.org > *Subject:* Fwd: [gst-devel] Camerabin2 Prototype and IRC Meeting > > in case any of the multimedia/middleware folks interested in camerabin2 > didn't notice this email from gst-devel list: > > -- Forwarded message -- > From: Thiago Sousa Santos > Date: Fri, Dec 3, 2010 at 11:30 PM > Subject: Re: [gst-devel] Camerabin2 Prototype and IRC Meeting > To: Discussion of the development of GStreamer < > gstreamer-de...@lists.sourceforge.net> > > > On Thu, 2010-12-02 at 12:07 -0300, Thiago Sousa Santos wrote: > > Hello, > > > > As mentioned some time ago, we started planning camerabin2. > > > > The good news is that a small prototype is ready at > > http://gitorious.org/gstreamer-camerabin2/gst-plugins-bad > > > > It is as simple as it gets, being able to take pictures, record videos > > and showing a viewfinder. Feedback, code review, patches, tests are > > welcome. I'm currently trying to get the code in shape to push it as an > > experimental plugin into -bad module. > > > > I'd like arrange meeting with people interested in camerabin2 to discuss > > desired features and problems with this new design. I'm already poking > > some people that mentioned interest to set up a date and time. We'd like > > to do this soon, so expect it to be early next week (Monday or Tuesday). > > Based on the feedback I got from the interested people and their > timezones: > > http://www.timeanddate.com/worldclock/meetingtime.html?day=7&month=12&year=2010&p1=101&p2=209&p3=64&p4=37 > > I guess 14PM UTC, Tuesday is a nice option. We'd meet on IRC on > #camerabin2. > > Any major problems with this? > > > > > Details on camerabin2 design are on the wiki: > > http://www.gstreamer.net/wiki/CameraBin > > > > -- > > Thiago > > > > > > > > > -- > > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > > Tap into the largest installed PC base & get more eyes on your game by > > optimizing for Intel(R) Graphics Technology. Get started today with the > > Intel(R) Software Partner Program. Five $500 cash prizes are up for > grabs. > > http://p.sf.net/sfu/intelisp-dev2dev > > ___ > > gstreamer-devel mailing list > > gstreamer-de...@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > > > > -- > What happens now with your Lotus Notes apps - do you make another costly > upgrade, or settle for being marooned without product support? Time to move > off Lotus Notes and onto the cloud with Force.com, apps are easier to > build, > use, and manage than apps on traditional platforms. Sign up for the Lotus > Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d > ___ > gstreamer-devel mailing list > gstreamer-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Notes & Actions: Linaro Graphics Working Group - Feb 09, 2011
On Fri, Feb 11, 2011 at 7:47 AM, Alexandros Frantzis wrote: > > * First version of Unified Memory Management position: > > https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Projects/UnifiedMemoryManagement btw, the access control aspect of this sort of reminds me of the DRM driver infrastructure, and authentication between direct rendering client and x-server (or whoever the DRM master is).. I wonder if there is, or should be, a connection.. BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] i.MX23/28 framebuffer driver
On Wed, Feb 9, 2011 at 10:31 AM, Arnd Bergmann wrote: > On Wednesday 09 February 2011, Sascha Hauer wrote: > >> The driver patch itself is Cced to linux-fbdev, only the introductory >> mail is not. > > Ok, I see. > >> > Did you consider making the driver a KMS driver instead of >> > a frame buffer? I think the recommendation these days is >> > to start out with KMS for new drivers, which will be somewhat >> > simpler and give you a frame buffer device as well. I don't >> > think that there is a need to change over any drivers from >> > fb to kms though, since you've already done the work. >> >> I tried doing so for the i.MX51 which supports multiple displays on dvi >> and vga outputs and thus could make good use of KMS and friends. Anyway, >> I got stuck quite fast. The KMS stuff is tightly coupled with DRM/DRI >> and needs many many callbacks to implement. Additionally the userspace >> tools expect a nvidia/amd/intel driver and do not have a generic >> fallback. I think this stuff is good for implementing a full blown >> graphics driver, but is lacking support for simple framebuffer grapics. >> I'd love to go this way but it still requires a lot of work. > > Ok. This sounds like a lot of upfront work indeed, to make KMS more > generic, though I think a number of driver would benefit from it > eventually. It could be something for the Linaro graphics working > group to look at in the following 11.11 release, depending on how > many other people are interested in getting there. > fwiw, it seems to me like xorg could have some more common code to deal with the KMS part of DRM.. the various userspace xorg drivers end up having a lot of very similar code to deal with enumerating CRTCs/outputs and modes, handle hotplug, etc. I'd been experimenting a bit on the side w/ the DRM driver framework ( http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu ), but had to add a good chunk of mostly boilerplate code to our xorg driver in order just to test it. Maybe some generic support for KMS in xf86-video-fbdev would have made this easier to develop the kernel part without in parallel having to implement the userspace part. I'm not sure if this is the sort of thing the linaro-wg has in mind? BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] i.MX23/28 framebuffer driver
I'm still in the learning-as-I-go phase here, so definitely not ready to propose a solution, but it does seem to me like there is room for some sort of kms-helper library here to handle more of the boilerplate xf86-video-* stuff.. I guess I'll have a better picture once I have a chance to add support for the various multi-monitor configurations. But certainly would be interested if anyone already has some ideas. BR, -R On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker wrote: > Speaking for the Linaro graphics working group, I think it's great. And, I > think you're right, that if enough of the KMS support in xf86-video-* is > similar enough (I was only aware of intel and nouveau supporting it properly > at current), pulling it out into a common layer would make it easier to > support in new drivers (including fbdev). > > cheers, > Jesse > > On Wed, Feb 16, 2011 at 4:22 AM, Arnd Bergmann wrote: >> >> On Tuesday 15 February 2011, Clark, Rob wrote: >> > I'd been experimenting a bit on the side w/ the DRM driver framework ( >> > >> > http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu >> > ), but had to add a good chunk of mostly boilerplate code to our xorg >> > driver in order just to test it. Maybe some generic support for KMS >> > in xf86-video-fbdev would have made this easier to develop the kernel >> > part without in parallel having to implement the userspace part. I'm >> > not sure if this is the sort of thing the linaro-wg has in mind? >> >> I'm not sure what the the linaro multimedia wg thinks of this, but the >> kernel code you linked looks like it's doing exactly the right thing. >> >> Arnd >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] i.MX23/28 framebuffer driver
Hmm, I was thinking more on the xf86 side of things.. ie. to provide default implementations of xf86CrtcFuncsRec and xf86OutputFuncsRec functions.. BR, -R On Wed, Feb 16, 2011 at 7:24 PM, Jammy Zhou wrote: > > There is already one KMS abstraction layer (libkms.so) in libdrm, maybe it > can serve as what we needed. > > Regards, > Jammy > > On Thu, Feb 17, 2011 at 9:08 AM, Clark, Rob wrote: >> >> I'm still in the learning-as-I-go phase here, so definitely not ready >> to propose a solution, but it does seem to me like there is room for >> some sort of kms-helper library here to handle more of the boilerplate >> xf86-video-* stuff.. I guess I'll have a better picture once I have a >> chance to add support for the various multi-monitor configurations. >> But certainly would be interested if anyone already has some ideas. >> >> BR, >> -R >> >> On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker >> wrote: >> > Speaking for the Linaro graphics working group, I think it's great. And, I >> > think you're right, that if enough of the KMS support in xf86-video-* is >> > similar enough (I was only aware of intel and nouveau supporting it >> > properly >> > at current), pulling it out into a common layer would make it easier to >> > support in new drivers (including fbdev). >> > >> > cheers, >> > Jesse >> > >> > On Wed, Feb 16, 2011 at 4:22 AM, Arnd Bergmann wrote: >> >> >> >> On Tuesday 15 February 2011, Clark, Rob wrote: >> >> > I'd been experimenting a bit on the side w/ the DRM driver framework ( >> >> > >> >> > http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu >> >> > ), but had to add a good chunk of mostly boilerplate code to our xorg >> >> > driver in order just to test it. Maybe some generic support for KMS >> >> > in xf86-video-fbdev would have made this easier to develop the kernel >> >> > part without in parallel having to implement the userspace part. I'm >> >> > not sure if this is the sort of thing the linaro-wg has in mind? >> >> >> >> I'm not sure what the the linaro multimedia wg thinks of this, but the >> >> kernel code you linked looks like it's doing exactly the right thing. >> >> >> >> Arnd >> >> >> >> ___ >> >> linaro-dev mailing list >> >> linaro-dev@lists.linaro.org >> >> http://lists.linaro.org/mailman/listinfo/linaro-dev >> > >> > >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] i.MX23/28 framebuffer driver
I'm all for a more modular drm, although I think the framework of CRTCs, encoders, and connectors is a nice fit, at least for our hw. It would be nice to have a better way to expose overlays. And I'm still thinking about how/if GEM fits in with our various video and 2/3d accelerators. BR, -R On Thu, Feb 17, 2011 at 8:19 PM, Jammy Zhou wrote: > To accommodate the fact of independent display controller and GPU components > in ARM SOC, it will be better if we can separate KMS from DRM both in kernel > space and user space (i.e, create a new drivers/video/kms directory for > kernel side, move KMS related code in libdrm to libkms in user space). Then > we can build xrandr1.2+ support based on KMS for ARM platforms, even if DRM > is still not supported. Besides, for buffer management part (GEM) in DRM, if > possible, we can also make it an independent module leaving DRM just a > wrapper, so that the GEM stuff can be used more flexibly. > > Regards, > Jammy > > On Fri, Feb 18, 2011 at 12:14 AM, James Simmons > wrote: >> >> > I'm still in the learning-as-I-go phase here, so definitely not ready >> > to propose a solution, but it does seem to me like there is room for >> > some sort of kms-helper library here to handle more of the boilerplate >> > xf86-video-* stuff.. I guess I'll have a better picture once I have a >> > chance to add support for the various multi-monitor configurations. >> > But certainly would be interested if anyone already has some ideas. >> >> I have been thinking about this as well. One of the short coming for DRM >> on embedded platforms is the lack of a small well defined library that one >> could use. Right now libkms only handles buffer allocation. The mode >> setting is currently tied to the libdrm library. It would be nice to >> seperate the two out more. Move the mode setting code to libkms and then >> have libdrm be a wrapper around this. This way libdrm can both support >> the legacy drm drivers and the new kms drivers at the same time. It also >> makes a clear seperation. Jakob if you are willing to take this work I >> will gladly seen you patches. >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] i.MX23/28 framebuffer driver
I'm in the process of adding xrandr support to our xorg driver.. definitely more built-in support on the X side would make this easier. BR, -R On Thu, Feb 17, 2011 at 8:25 PM, Jammy Zhou wrote: > I also noticed that default XRandR1.2+ implementation is missing in X side. > If we can implement one, it would be beneficial for all ARM platforms. By > the way, does X driver of TI support XRandR1.2+? > > Regards, > Jammy > > On Thu, Feb 17, 2011 at 11:25 PM, Clark, Rob wrote: >> >> Hmm, I was thinking more on the xf86 side of things.. ie. to provide >> default implementations of xf86CrtcFuncsRec and xf86OutputFuncsRec >> functions.. >> >> BR, >> -R >> >> On Wed, Feb 16, 2011 at 7:24 PM, Jammy Zhou wrote: >> > >> > There is already one KMS abstraction layer (libkms.so) in libdrm, maybe >> > it can serve as what we needed. >> > >> > Regards, >> > Jammy >> > >> > On Thu, Feb 17, 2011 at 9:08 AM, Clark, Rob wrote: >> >> >> >> I'm still in the learning-as-I-go phase here, so definitely not ready >> >> to propose a solution, but it does seem to me like there is room for >> >> some sort of kms-helper library here to handle more of the boilerplate >> >> xf86-video-* stuff.. I guess I'll have a better picture once I have a >> >> chance to add support for the various multi-monitor configurations. >> >> But certainly would be interested if anyone already has some ideas. >> >> >> >> BR, >> >> -R >> >> >> >> On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker >> >> wrote: >> >> > Speaking for the Linaro graphics working group, I think it's great. >> >> > And, I >> >> > think you're right, that if enough of the KMS support in xf86-video-* >> >> > is >> >> > similar enough (I was only aware of intel and nouveau supporting it >> >> > properly >> >> > at current), pulling it out into a common layer would make it easier >> >> > to >> >> > support in new drivers (including fbdev). >> >> > >> >> > cheers, >> >> > Jesse >> >> > >> >> > On Wed, Feb 16, 2011 at 4:22 AM, Arnd Bergmann wrote: >> >> >> >> >> >> On Tuesday 15 February 2011, Clark, Rob wrote: >> >> >> > I'd been experimenting a bit on the side w/ the DRM driver >> >> >> > framework ( >> >> >> > >> >> >> > >> >> >> > http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu >> >> >> > ), but had to add a good chunk of mostly boilerplate code to our >> >> >> > xorg >> >> >> > driver in order just to test it. Maybe some generic support for >> >> >> > KMS >> >> >> > in xf86-video-fbdev would have made this easier to develop the >> >> >> > kernel >> >> >> > part without in parallel having to implement the userspace part. >> >> >> > I'm >> >> >> > not sure if this is the sort of thing the linaro-wg has in mind? >> >> >> >> >> >> I'm not sure what the the linaro multimedia wg thinks of this, but >> >> >> the >> >> >> kernel code you linked looks like it's doing exactly the right >> >> >> thing. >> >> >> >> >> >> Arnd >> >> >> >> >> >> ___ >> >> >> linaro-dev mailing list >> >> >> linaro-dev@lists.linaro.org >> >> >> http://lists.linaro.org/mailman/listinfo/linaro-dev >> >> > >> >> > >> >> >> >> ___ >> >> linaro-dev mailing list >> >> linaro-dev@lists.linaro.org >> >> http://lists.linaro.org/mailman/listinfo/linaro-dev >> > > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [st-ericsson] v4l2 vs omx for camera
On Fri, Feb 18, 2011 at 10:39 AM, Robert Fekete
wrote:
> Hi,
>
> In order to expand this knowledge outside of Linaro I took the Liberty of
> inviting both linux-me...@vger.kernel.org and
> gstreamer-de...@lists.freedesktop.org. For any newcomer I really recommend
> to do some catch-up reading on
> http://lists.linaro.org/pipermail/linaro-dev/2011-February/thread.html
> ("v4l2 vs omx for camera" thread) before making any comments. And sign up
> for Linaro-dev while you are at it :-)
>
> To make a long story short:
> Different vendors provide custom OpenMax solutions for say Camera/ISP. In
> the Linux eco-system there is V4L2 doing much of this work already and is
> evolving with mediacontroller as well. Then there is the integration in
> Gstreamer...Which solution is the best way forward. Current discussions so
> far puts V4L2 greatly in favor of OMX.
> Please have in mind that OpenMAX as a concept is more like GStreamer in many
> senses. The question is whether Camera drivers should have OMX or V4L2 as
> the driver front end? This may perhaps apply to video codecs as well. Then
> there is how to in best of ways make use of this in GStreamer in order to
> achieve no copy highly efficient multimedia pipelines. Is gst-omx the way
> forward?
just fwiw, there were some patches to make v4l2src work with userptr
buffers in case the camera has an mmu and can handle any random
non-physically-contiguous buffer.. so there is in theory no reason
why a gst capture pipeline could not be zero copy and capture directly
into buffers allocated from the display
Certainly a more general way to allocate buffers that any of the hw
blocks (display, imaging, video encoders/decoders, 3d/2d hw, etc)
could use, and possibly share across-process for some zero copy DRI
style rendering, would be nice. Perhaps V4L2_MEMORY_GEM?
>
> Let the discussion continue...
>
>
> On 17 February 2011 14:48, Laurent Pinchart
> wrote:
>>
>> On Thursday 10 February 2011 08:47:15 Hans Verkuil wrote:
>> > On Thursday, February 10, 2011 08:17:31 Linus Walleij wrote:
>> > > On Wed, Feb 9, 2011 at 8:44 PM, Harald Gustafsson wrote:
>> > > > OMX main purpose is to handle multimedia hardware and offer an
>> > > > interface to that HW that looks identical indenpendent of the vendor
>> > > > delivering that hardware, much like the v4l2 or USB subsystems tries
>> > > > to
>> > > > do. And yes optimally it should be implemented in drivers/omx in
>> > > > Linux
>> > > > and a user space library on top of that.
>> > >
>> > > Thanks for clarifying this part, it was unclear to me. The reason
>> > > being
>> > > that it seems OMX does not imply userspace/kernelspace separation, and
>> > > I was thinking more of it as a userspace lib. Now my understanding is
>> > > that if e.g. OpenMAX defines a certain data structure, say for a PCM
>> > > frame or whatever, then that exact struct is supposed to be used by
>> > > the
>> > > kernelspace/userspace interface, and defined in the include file
>> > > exported
>> > > by the kernel.
>> > >
>> > > > It might be that some alignment also needs to be made between 4vl2
>> > > > and
>> > > > other OS's implementation, to ease developing drivers for many OSs
>> > > > (sorry I don't know these details, but you ST-E guys should know).
>> > >
>> > > The basic conflict I would say is that Linux has its own API+ABI,
>> > > which
>> > > is defined by V4L and ALSA through a community process without much
>> > > thought about any existing standard APIs. (In some cases also
>> > > predating
>> > > them.)
>> > >
>> > > > By the way IL is about to finalize version 1.2 of OpenMAX IL which
>> > > > is
>> > > > more than a years work of aligning all vendors and fixing unclear
>> > > > and
>> > > > buggy parts.
>> > >
>> > > I suspect that the basic problem with Khronos OpenMAX right now is
>> > > how to handle communities - for example the X consortium had
>> > > something like the same problem a while back, only member companies
>> > > could partake in the standard process, and they need of course to pay
>> > > an upfront fee for that, and the majority of these companies didn't
>> > > exactly send Linux community members to the meetings.
>> > >
>> > > And now all the companies who took part in OpenMAX somehow
>> > > end up having to do a lot of upfront community work if they want
>> > > to drive the API:s in a certain direction, discuss it again with the
>> > > V4L
>> > > and ALSA maintainers and so on. Which takes a lot of time and
>> > > patience with uncertain outcome, since this process is autonomous
>> > > from Khronos. Nobody seems to be doing this, I javen't seen a single
>> > > patch aimed at trying to unify the APIs so far. I don't know if it'd
>> > > be
>> > > welcome.
>> > >
>> > > This coupled with strict delivery deadlines and a marketing will
>> > > to state conformance to OpenMAX of course leads companies into
>> > > solutions breaking the Linux kernelspace API to be able to present
>> > > this.
>>
>> From my experience with O
Re: [st-ericsson] v4l2 vs omx for camera
On Thu, Feb 24, 2011 at 2:19 PM, Edward Hervey wrote: > > What *needs* to be solved is an API for data allocation/passing at the > kernel level which v4l2,omx,X,GL,vdpau,vaapi,... can use and that > userspace (like GStreamer) can pass around, monitor and know about. yes yes yes yes!! vaapi/vdpau is half way there, as they cover sharing buffers with X/GL.. but sadly they ignore camera. There are a few other inconveniences with vaapi and possibly vdpau.. at least we'd prefer to have an API the covered decoding config data like SPS/PPS and not just slice data since config data NALU's are already decoded by our accelerators.. > That is a *massive* challenge on its own. The choice of using > GStreamer or not ... is what you want to do once that challenge is > solved. > > Regards, > > Edward > > P.S. GStreamer for Android already works : > http://www.elinux.org/images/a/a4/Android_and_Gstreamer.ppt > yeah, I'm aware of that.. someone please convince google to pick it up and drop stagefright so we can only worry about a single framework between android and linux (and then I look forward to playing with pitivi on an android phone :-)) BR, -R > ___ > gstreamer-devel mailing list > gstreamer-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [st-ericsson] v4l2 vs omx for camera
On Thu, Feb 24, 2011 at 7:17 AM, Hans Verkuil wrote: > There are two parts to this: first of all you need a way to allocate large > buffers. The CMA patch series is available (but not yet merged) that does > this. > I'm not sure of the latest status of this series. > > The other part is that everyone can use and share these buffers. There isn't > anything for this yet. We have discussed this in the past and we need > something > generic for this that all subsystems can use. It's not a good idea to tie this > to any specific framework like GEM. Instead any subsystem should be able to > use > the same subsystem-independent buffer pool API. yeah, doesn't need to be GEM.. but should at least inter-operate so we can share buffers with the display/gpu.. [snip] >> But maybe it would be nice to have a way to have sensor driver on the >> linux side, pipelined with hw and imaging drivers on a co-processor >> for various algorithms and filters with configuration all exposed to >> userspace thru MCF.. I'm not immediately sure how this would work, but >> it sounds nice at least ;-) > > MCF? What does that stand for? > sorry, v4l2 media controller framework BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [st-ericsson] v4l2 vs omx for camera
On Thu, Feb 24, 2011 at 7:10 AM, Laurent Pinchart wrote: > On Thursday 24 February 2011 14:04:19 Hans Verkuil wrote: >> On Thursday, February 24, 2011 13:29:56 Linus Walleij wrote: >> > 2011/2/23 Sachin Gupta : >> > > The imaging coprocessor in today's platforms have a general purpose DSP >> > > attached to it I have seen some work being done to use this DSP for >> > > graphics/audio processing in case the camera use case is not being >> > > tried or also if the camera usecases does not consume the full >> > > bandwidth of this dsp.I am not sure how v4l2 would fit in such an >> > > architecture, >> > >> > Earlier in this thread I discussed TI:s DSPbridge. >> > >> > In drivers/staging/tidspbridge >> > http://omappedia.org/wiki/DSPBridge_Project >> > you find the TI hackers happy at work with providing a DSP accelerator >> > subsystem. >> > >> > Isn't it possible for a V4L2 component to use this interface (or >> > something more evolved, generic) as backend for assorted DSP offloading? >> > >> > So using one kernel framework does not exclude using another one >> > at the same time. Whereas something like DSPbridge will load firmware >> > into DSP accelerators and provide control/datapath for that, this can >> > in turn be used by some camera or codec which in turn presents a >> > V4L2 or ALSA interface. >> >> Yes, something along those lines can be done. >> >> While normally V4L2 talks to hardware it is perfectly fine to talk to a DSP >> instead. >> >> The hardest part will be to identify the missing V4L2 API pieces and design >> and add them. I don't think the actual driver code will be particularly >> hard. It should be nothing more than a thin front-end for the DSP. Of >> course, that's just theory at the moment :-) >> >> The problem is that someone has to do the actual work for the initial >> driver. And I expect that it will be a substantial amount of work. Future >> drivers should be *much* easier, though. >> >> A good argument for doing this work is that this API can hide which parts >> of the video subsystem are hardware and which are software. The >> application really doesn't care how it is organized. What is done in >> hardware on one SoC might be done on a DSP instead on another SoC. But the >> end result is pretty much the same. > > I think the biggest issue we will have here is that part of the inter- > processors communication stack lives in userspace in most recent SoCs (OMAP4 > comes to mind for instance). This will make implementing a V4L2 driver that > relies on IPC difficult. > > It's probably time to start seriously thinking about userspace > drivers/librairies/middlewares/frameworks/whatever, at least to clearly tell > chip vendors what the Linux community expects. > I suspect more of the IPC framework needs to move down to the kernel.. this is the only way I can see to move the virt->phys address translation to a trusted layer. I'm not sure how others would feel about pushing more if the IPC stack down to the kernel, but at least it would make it easier for a v4l2 driver to leverage the coprocessors.. BR, -R > -- > Regards, > > Laurent Pinchart > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Yet another memory provider: can linaro organize a meeting?
Then this sounds to me a bit like like GEM.. (or maybe I should say DRM and either TTM/GEM below)? If you can pass buffers back and forth between kernel and various processes by integer id, and then optionally read/write/mmap thru some ioctls if needed.. then the buffer sharing problem is solved. To me it sounds like how libdrm and libva above work. If the problem is already solved for video decode and render, then we just need to extend it to add camera. So if it is explicitly about buffer sharing, and not buffer allocation, then it is still separate from what could/should fit beneath to allocate contiguous memory.. BR, -R On Tue, Mar 8, 2011 at 6:08 AM, Jonghun Han wrote: > > Thanks for interesting. > > As I know, the purpose of UMP is the buffer sharing especially > inter-process > . > Maybe ARM can explain it more detail. > > High resolution video/image processing requires zero-copy operation. > UMP allows zero-copy operation using system unique key, named SecureID. > UMP supports memory allocation. (custom memory allocator can be used.) > It gives a SecureID for each buffer during allocation. > And user virtual address for each process can be made by SecureID. > Application can access the buffer using its own virtual address made by > SecureID. > So application can share the buffer without copy operation. > > For example, video playback application can share the buffer even though it > consists of multiple process. > > Best regards, > Jonghun Han > > > -Original Message- > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > ow...@vger.kernel.org] On Behalf Of Kyungmin Park > > Sent: Tuesday, March 08, 2011 8:06 PM > > To: Hans Verkuil > > Cc: linaro-dev@lists.linaro.org; linux-me...@vger.kernel.org; Jonghun > Han > > Subject: Re: Yet another memory provider: can linaro organize a meeting? > > > > Dear Jonghun, > > > > It's also helpful to explain what's the original purpose of UMP (for GPU, > > MALI) and what's the goal of UMP usage for multimedia stack. > > Especially, what's the final goal of UMP from LSI. > > > > Also consider the previous GPU memory management program, e.g., SGX. > > > > Thank you, > > Kyungmin Park > > > > On Tue, Mar 8, 2011 at 5:13 PM, Hans Verkuil wrote: > > > Hi all, > > > > > > We had a discussion yesterday regarding ways in which linaro can > > > assist > > > V4L2 development. One topic was that of sorting out memory providers > > > like GEM and HWMEM. > > > > > > Today I learned of yet another one: UMP from ARM. > > > > > > http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver- > > > open-source/page__cid__133__show__newcomment/ > > > > > > This is getting out of hand. I think that organizing a meeting to > > > solve this mess should be on the top of the list. Companies keep on > > > solving the same problem time and again and since none of it enters > > > the mainline kernel any driver using it is also impossible to upstream. > > > > > > All these memory-related modules have the same purpose: make it > > > possible to allocate/reserve large amounts of memory and share it > > > between different subsystems (primarily framebuffer, GPU and V4L). > > > > > > It really shouldn't be that hard to get everyone involved together and > > > settle on a single solution (either based on an existing proposal or > > > create a 'the best of' vendor-neutral solution). > > > > > > I am currently aware of the following solutions floating around the > > > net that all solve different parts of the problem: > > > > > > In the kernel: GEM and TTM. > > > Out-of-tree: HWMEM, UMP, CMA, VCM, CMEM, PMEM. > > > > > > I'm sure that last list is incomplete. > > > > > > Regards, > > > > > >Hans > > > > > > -- > > > Hans Verkuil - video4linux developer - sponsored by Cisco > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-media" > > > in the body of a message to majord...@vger.kernel.org More majordomo > > > info at http://vger.kernel.org/majordomo-info.html > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the > > body of a message to majord...@vger.kernel.org More majordomo info at > > http://vger.kernel.org/majordomo-info.html > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Future desktop on dumb frame buffers?
On Wed, Mar 23, 2011 at 9:09 AM, Robert Fekete wrote: > On 21 March 2011 21:08, Alex Deucher wrote: > > On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven > > wrote: > >> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes > wrote: > >>> On Mon, 21 Mar 2011 19:19:43 + > >>> timofonic timofonic wrote: > So if KMS is so cool and provides many advantages over fbdev and > such... Why isn't more widely used intead of still relying on fbdev? > Why still using fbdev emulation (that is partial and somewhat broken, > it seems) instead using KMS directly? > >>> > >>> Used by what? All three major GPU device classes have KMS support > >>> (Intel, ATI, and nVidia). If you want it for a particular device, you > >>> can always port it over. > >> > >> The three major GPU device classes on PC... > > > > Sadly it gets worse. A lot of the SoC vendors are adding an fbdev > > emulation layer on top of v4l rather than using fbdev directly or > > using KMS and v4l has grown it's own edid, hdmi, and cec handling. > > > > I agree, it is sad that as a SoC vendor there are different > kernel/user API's(v4l2/fbdev/drm) to choose from when implementing say > a Display controller driver. One must also remember that there are big > differences between a desktop/PC multimedia/graphics system and the > ones present on an embedded SoC. It is two very different cultures and > HW designs now trying to merge into one Linux Kernel. Of course there > will be some overlaps but I believe it can be sorted out as soon as we > understand each others different possibilities/limitations. Doing > duplicate work like HDMI will not benefit any party. > > Just to list some of the differences. > > - Developments within V4L2 has mainly been driven by embedded devices > while DRM is a result of desktop Graphics cards. And for some extent > also solving different problems. > - Embedded devices usually have several different hw IP's managing > displays, hdmi, camera/ISP, video codecs(h264 accellerators), DSP's, > 2D blitters, Open GL ES hw, all of which have a separate device/driver > in the kernel, while on a desktop nowadays all this functionality > usually resides on ONE graphics card, hence one DRM device for all. > - DRM is closely developed in conjunction with desktop/Xorg, while X11 > on an embedded device is not very 2011...wayland on the other hand is > :-), but do wayland really need the full potential of DRM/DRI or just > parts of it. > - Copying buffers is really bad for embedded devices due to lower > memory bandwidth and power consumption while on a Desktop memory > bandwidth is from an other galaxy (copying still bad but accepted it > seems), AND embedded devices of today records and plays/displays 1080p > content as well. > - Not all embedded devices have MMU's for each IP requiring physical > contiguous memory, while on a desktop MMU's have been present for > ages. > - Embedded devices are usually ARM based SoCs while x86 dominates the > Desktop/Laptop market, and functionality provided is soon the very > same. > - yada yadaThe list can grow very longThere are also > similarities of course. > > The outcome is that SoC vendors likes the embedded friendliness of > v4l2 and fbdev while "we" also glance at the DRM part due to its > de-facto standard on desktop environments. But from an embedded point > of view DRM lacks the support for interconnecting multiple > devices/drivers mentioned above, GEM/TTM is valid within a DRM device, > the execution/context management is not needed,, no overlays(or > similar), the coupling to DRI/X11 not wanted. SoCs like KMS/GEM but > the rest of DRM will likely not be heavily used on SoCs unless running > X11 as well. Most likely this worked on as well within the DRI > community. I can see good features all over the place(sometimes > duplicated) but not find one single guideline/API that solves all the > embedded SoC problems (which involves use-cases optimized for no-copy > cross media/drivers). > > Last but not least... > > On Linaro there is already discussions ongoing to solve one of the > biggest issues from a SoC point of view and that is a "System Wide > Memory manager" which manages buffer sharing and resolves no-copy use > cases between devices/drivers. Read more on the following thread: > http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html. > > At least if you care about X11 (and probably wayland, since I assume it will inherit some of this from X11), one nice thing about drm/dri/gem is that it has already solved the problem with sharing buffers between X11 and video decoders/encoders (although some of that is a bit in vendor specific parts of vaapi).. but still it would be nice to somehow extend existing solutions so we have some better chance of desktop sw working on arm, rather than just throwing existing desktop solutions out the window.. If we add camera/v4l2 support for drm/dri (and maybe vaapi above that?), then I think we have full zero-copy us
Re: Yet another memory provider: can linaro organize a meeting?
On Wed, Mar 16, 2011 at 3:14 AM, Kyungmin Park wrote: > > Rough schedules. > > 1. Warsaw meetings (3/16~3/18): mostly v4l2 person and some SoC vendors > Make a consensence at media developers. and share the information. > Please note that it's v4l2 brainstorming meeting. so memory > management is not the main issue. > 2. ELC (4/11~4/13): DRM, DRI and v4l2 person. Fyi, I should be at ELC, at least for a day or two.. it would be nice, as Andy suggested on other thread, to carve out a timeslot to discuss in advance, because I'm not sure that I'll be able to be there the entire time.. BR, -R > Discuss GEM/TTM is acceptable for non-X86 system and find out the > which modules are acceptable. > We studied the GEM for our environment. but it's too huge and not > much benefit for us since current frameworks are enough. > The missing is that no generic memory passing mechanism. We need the > generic memory passing interface. that's all. > 3. Linaro (5/9~5/13): ARM, SoC vendors and v4l2 persons. > I hope several person are anticipated and made a small step for final goal. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
ION: google's answer to GEM?
hmm, https://review.source.android.com/#change,22239 >From a quick look, it appears to be doing a similar thing as GEM.. although as a stand-alone driver rather than coupled with display driver (drm). BR, -R ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ION: google's answer to GEM?
Well, it is in gerrit so I guess that means we are free to submit review comments ;-) On Tue, Apr 12, 2011 at 1:16 PM, Zach Pfeffer wrote: > It does look really close to drivers/gpu/drm except with priority > sorted rb_tree heaps and a lot less interop code. > > -Zach > > On Tue, Apr 12, 2011 at 11:12 AM, Clark, Rob wrote: >> hmm, >> >> https://review.source.android.com/#change,22239 >> >> From a quick look, it appears to be doing a similar thing as GEM.. >> although as a stand-alone driver rather than coupled with display >> driver (drm). >> >> >> BR, >> -R >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev >> > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
