[Linaro-mm-sig] CFP: Budapest Mini-summit update

[Hans Verkuil]

> On Thu, Apr 28, 2011 at 1:43 AM, Hans Verkuil <hverkuil at xs4all.nl> wrote:
>> On Thursday, April 28, 2011 00:37:33 Jesse Barker wrote:
>>> Hi all,
>>>
>>> The good news is that largely everything is as I announced previously.
>>>  The tracks have been cleaned up a bit, so the memory management
>>> mini-summit is now driven out of the Linaro Graphics track, but the
>>> room (Ond) and schedule (M-W afternoons) is still the same.  All the
>>> info you need on the schedule is here:
>>>
>>> http://summit.ubuntu.com/uds-o/
>>>
>>> The room is supposed to have a projector, be mic'd for live audio and
>>> have an IRC channel.  Those participating remotely will be interested
>>> in the details around the audio and IRC access here:
>>>
>>> http://uds.ubuntu.com/participate/remote/
>>>
>>> A link for the mini-summit event found here:
>>>
>>> https://wiki.linaro.org/Events
>>>
>>> goes to the (work in progress) agenda and there is a registration link
>>> as well.  Please let me know if I've missed any components that need
>>> representation, if there are some on there that you feel don't need
>>> it, or if there are additional items you'd like to see on the agenda.
>>
>> The Media Controller doesn't belong in this discussion. It has nothing
>> to
>> do with buffer handling. The same is true AFAICT for KMS. It is no doubt
>> useful to have a discussion about V4L/KMS/MC, but that's a separate
>> topic.
>
> I think separate but a bit related topic, so it would be good to
> cover..  ie. if the conclusion is that something new is needed to
> replace GEM (rather than enhancements to GEM), we should see how this
> fits in to DRM.

DRM is obviously relevant, but KMS isn't as far as I know.

>  (Although the main connection I could see at the
> moment, I think you'd need to be able to represent an allocated buffer
> as a __u32 handle so you have an association between a drm_framebuffer
> object and the actual buffer memory.)
>
> if less people are interested (or at least less that are joining
> remotely) we could perhaps cover these in one of the morning timeslots

We could have a morning session on the relationships between
DRM/KMS/FB/V4L/MC. It is not always obvious what API/subsystem should
control what (and that's even more complex for SoCs that can dynamically
switch from a framebuffer to a v4l node and back depending on the use
case).

At the very least some mutual education would be useful. But this has
nothing to do with the memory handling topics and it would only distract
from that if we mixed those topics.

Regards,

     Hans

>
> BR,
> -R
>
>>> I have 2 requests of the people that will participate in person:
>>>
>>> 1) Please "register" to indicate you'll be there in person (or even if
>>> you plan on participating remotely).  There are a few reasons for
>>> this, but the critical one is to make sure we have a big enough room.
>>> 2) Sign-up to represent a component, at least in the overview
>>> sessions.  This is important for sane discussion afterwards.
>>
>> I'll prepare a short V4L presentation, focussing on the buffer handling
>> API and buffer handling internals.
>>
>> Regards,
>>
>>        Hans
>>
>>>
>>> If you don't or can't get write access to the Linaro wiki, just send
>>> me email directly and I'll do it by proxy.  Also, if you have material
>>> that you will "show" people (slides, etc.), please send it to the list
>>> ahead of time for the benefit of those participating remotely.
>>> Finally, the "project page" for this effort is here on the Linaro
>>> wiki:
>>>
>>> https://wiki.linaro.org/OfficeofCTO/MemoryManagement
>>>
>>> Thanks again to everyone for their contributions.
>>>
>>> cheers,
>>> Jesse
>>>
>>> _______________________________________________
>>> Linaro-mm-sig mailing list
>>> Linaro-mm-sig at lists.linaro.org
>>> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>>>
>>
>> _______________________________________________
>> Linaro-mm-sig mailing list
>> Linaro-mm-sig at lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>>
>
>