On 16/02/14 15:52, Christian König wrote: > Am 16.02.2014 13:53, schrieb Emil Velikov: >> On 16/02/14 10:20, Christian König wrote: >>> Am 15.02.2014 20:35, schrieb Emil Velikov: >>>> Query of the driver support AVC_HIGH encode before reporting >>>> the total number of supported components. >>>> >>>> v2: drop if (name_specific_length) check >>> I considered this as well, but as far as I understand it that's not >>> necessary correct. >>> >> Hi Christian >> >> I'm not sure I see your concern. >> >> If you consider this an individual project one will not implement nor >> advertise an encoder (second component) if they know it is not going to >> work (would that be missing hardware capability or other reason). Same >> thing here - there is no point in saying "we have two components" only >> to die later after realising that is not the case. > > As far as I understood it the number of components and the name of them > should be statically and never change without rebulding the component > registry. Actually that we concatenate the component name and have > dynamically specific names/roles is already quite questionable > > See for example the ".omxregister" file that the bellagio loader builds > up while loading the library. Not sure if it was bellagios caching or > that of gstreamer, but while working on the code I had to clear and > rebuild them a couple of times to make it work. > >> I suspect that this may even help with the following bug >> https://bugs.freedesktop.org/show_bug.cgi?id=74944 > > Actually to fix this bug we shouldn't check at all while being queried > for available components, but rather fail while creating them. To be > honest I don't have much experience with applications using this > interface (except for gstreamer), so I can't really judge what's the > right approach here. > > Anyway, the proper fix for this bug is probably to use the pipe loader > instead. > >>> Have you checked the spec on how exactly we should do it? >>> >> I have skimmed through the openmax IL 1.1.2 spec and it does not seem to >> cover this topic. Or perhaps I should be looking at the >> libomxil-bellagio documentation ? > > I couldn't find anything clear on this topic either. > So to put things mildly - it's rather messy.
We have do to either one of the following two - Shout "I can do everything" and fail a handful of times. Then hope that everyone can pick up the pieces. - Have to constantly redo the cache(re-register). And scratch our heads how do we control this, considering mesa changes, user switching between two codecs. We could also cleanup/drop all the caching mess in bellagio ... I'd rather not. I will go with option 1 (+ pipe-fication of omx) some time this week and add some comments along the way about the (imho) unorthodox behaviour. -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
