Hi all,
I have three topics I'd like to discuss at the upcoming workshop:
- CEC framework: v9 was recently posted and other than some documentation work I believe it is ready to be merged. I would like to give a presentation on what CEC is and the design of the framework. Est. 30 minutes + questions.
- VIDIOC_SUBDEV_QUERYCAP: we never got an agreement about this, so I'd like to discuss it. Est. 30 minutes (but since it touches on the MC, it could just as easily be several hours!)
- Support for HW colorspace conversion. I've been working on this on-and-off and I'd like to discuss how to integrate this in V4L2. Est. 30-45 minutes.
Regards,
Hans
On 09/14/2015 10:48 AM, Hans Verkuil wrote:
Hi all,
I have three topics I'd like to discuss at the upcoming workshop:
CEC framework: v9 was recently posted and other than some documentation work I believe it is ready to be merged. I would like to give a presentation on what CEC is and the design of the framework. Est. 30 minutes + questions.
VIDIOC_SUBDEV_QUERYCAP: we never got an agreement about this, so I'd like to discuss it. Est. 30 minutes (but since it touches on the MC, it could just as easily be several hours!)
Support for HW colorspace conversion. I've been working on this on-and-off and I'd like to discuss how to integrate this in V4L2. Est. 30-45 minutes.
- Should we replace v4l2_buffer with a new struct that is y2038-safe and that can be cleaned up and extended? (Think proper support for HW timestamps, etc.)
See: https://patchwork.linuxtv.org/patch/31413/
Regards,
Hans
On 16-09-15 08:31, Hans Verkuil wrote:
On 09/14/2015 10:48 AM, Hans Verkuil wrote:
Hi all,
I have three topics I'd like to discuss at the upcoming workshop:
CEC framework: v9 was recently posted and other than some documentation work I believe it is ready to be merged. I would like to give a presentation on what CEC is and the design of the framework. Est. 30 minutes + questions.
VIDIOC_SUBDEV_QUERYCAP: we never got an agreement about this, so I'd like to discuss it. Est. 30 minutes (but since it touches on the MC, it could just as easily be several hours!)
Support for HW colorspace conversion. I've been working on this on-and-off and I'd like to discuss how to integrate this in V4L2. Est. 30-45 minutes.
- Should we replace v4l2_buffer with a new struct that is y2038-safe and that can be cleaned up and extended? (Think proper support for HW timestamps, etc.)
And perhaps use this redesign to add support for multiple streams over one video node? (just saw an example where the HW combines two streams into one, basically an m2m device, but today you'd need three nodes: two out and one capture). Just brainstorming here...
Hans
See: https://patchwork.linuxtv.org/patch/31413/
Regards,
Hans
media-workshop mailing list media-workshop@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
Hi Hans,
On Monday 21 September 2015 09:59:51 Hans Verkuil wrote:
On 16-09-15 08:31, Hans Verkuil wrote:
On 09/14/2015 10:48 AM, Hans Verkuil wrote:
Hi all,
I have three topics I'd like to discuss at the upcoming workshop:
CEC framework: v9 was recently posted and other than some documentation work I believe it is ready to be merged. I would like to give a presentation on what CEC is and the design of the framework. Est. 30 minutes + questions.
VIDIOC_SUBDEV_QUERYCAP: we never got an agreement about this, so I'd like to discuss it. Est. 30 minutes (but since it touches on the MC, it could just as easily be several hours!)
Support for HW colorspace conversion. I've been working on this on-and-off and I'd like to discuss how to integrate this in V4L2. Est. 30-45 minutes.
- Should we replace v4l2_buffer with a new struct that is y2038-safe and that can be cleaned up and extended? (Think proper support for HW timestamps, etc.)
And perhaps use this redesign to add support for multiple streams over one video node? (just saw an example where the HW combines two streams into one, basically an m2m device, but today you'd need three nodes: two out and one capture). Just brainstorming here...
The Renesas VSP1 is a composer with up to 5 inputs and up to 4 outputs and also uses multiple video nodes.
On 16-09-15 08:31, Hans Verkuil wrote:
On 09/14/2015 10:48 AM, Hans Verkuil wrote:
Hi all,
I have three topics I'd like to discuss at the upcoming workshop:
CEC framework: v9 was recently posted and other than some documentation work I believe it is ready to be merged. I would like to give a presentation on what CEC is and the design of the framework. Est. 30 minutes + questions.
VIDIOC_SUBDEV_QUERYCAP: we never got an agreement about this, so I'd like to discuss it. Est. 30 minutes (but since it touches on the MC, it could just as easily be several hours!)
Support for HW colorspace conversion. I've been working on this on-and-off and I'd like to discuss how to integrate this in V4L2. Est. 30-45 minutes.
Should we replace v4l2_buffer with a new struct that is y2038-safe and that can be cleaned up and extended? (Think proper support for HW timestamps, etc.)
- should the v4l2 core just call try_format to validate the format passed in by VIDIOC_CREATE_BUFFERS? Few drivers validate the format and if they do they usually do only partial validation. It's unclear what should happen here.
Regards,
Hans
I would like to add the following topics for discussion at the upcoming Media Workshop
- ENT_F_IO appears to be too generic, requiring additional steps to determine what kind of IO function it is really is. I propose preserving and allowing enough uniqueness to enable drivers to tag the functions when they create them. For example, if AUDIO functions are all tagged ENT_F_IO, bridge driver has to determine what kind of IO it really is. This requires finding the Interface entity associated with the function entity or comparing entity name strings. Instead, if a function can be tagged as Audio Capture when it gets created, these additional steps aren't necessary.
- Discuss snd-usb-audio control interface mapping to media. snd-usb-audio creates a control device file which could be exposed in a media graph. In some cases, it is a simple mixer control. Expose ENT_F_MIXER entity with an associated interface node MEDIA_INTF_T_ALSA_CONTROL
thanks, -- Shuah
I would also like to attend this workshop, if it is being held next week in Dublin.
Thanks & best regards,
Michael Ira Krufky Samsung Electronics America
On Thu, Oct 1, 2015 at 12:48 PM, Shuah Khan shuahkh@osg.samsung.com wrote:
I would like to add the following topics for discussion at the upcoming Media Workshop
ENT_F_IO appears to be too generic, requiring additional steps to determine what kind of IO function it is really is. I propose preserving and allowing enough uniqueness to enable drivers to tag the functions when they create them. For example, if AUDIO functions are all tagged ENT_F_IO, bridge driver has to determine what kind of IO it really is. This requires finding the Interface entity associated with the function entity or comparing entity name strings. Instead, if a function can be tagged as Audio Capture when it gets created, these additional steps aren't necessary.
Discuss snd-usb-audio control interface mapping to media. snd-usb-audio creates a control device file which could be exposed in a media graph. In some cases, it is a simple mixer control. Expose ENT_F_MIXER entity with an associated interface node MEDIA_INTF_T_ALSA_CONTROL
thanks, -- Shuah
-- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shuahkh@osg.samsung.com | (970) 217-8978
media-workshop mailing list media-workshop@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
I think that it is in Korea :(. Otherwise I am also in, if possible.
Who will be in Dublin next week? Couldn't we arrange something? At least a dinner?
Regards! On 1 Oct 2015 7:35 pm, "Michael Ira Krufky" mkrufky@linuxtv.org wrote:
I would also like to attend this workshop, if it is being held next week in Dublin.
Thanks & best regards,
Michael Ira Krufky Samsung Electronics America
On Thu, Oct 1, 2015 at 12:48 PM, Shuah Khan shuahkh@osg.samsung.com wrote:
I would like to add the following topics for discussion at the upcoming Media Workshop
ENT_F_IO appears to be too generic, requiring additional steps to determine what kind of IO function it is really is. I propose preserving and allowing enough uniqueness to enable drivers to tag the functions when they create them. For example, if AUDIO functions are all tagged ENT_F_IO, bridge driver has to determine what kind of IO it really is. This requires finding the Interface entity associated with the function entity or comparing entity name strings. Instead, if a function can be tagged as Audio Capture when it gets created, these additional steps aren't necessary.
Discuss snd-usb-audio control interface mapping to media. snd-usb-audio creates a control device file which could be exposed in a media graph. In some cases, it is a simple mixer control. Expose ENT_F_MIXER entity with an associated interface node MEDIA_INTF_T_ALSA_CONTROL
thanks, -- Shuah
-- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shuahkh@osg.samsung.com | (970) 217-8978
media-workshop mailing list media-workshop@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
media-workshop mailing list media-workshop@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
Em Thu, 01 Oct 2015 19:39:23 +0200 Ricardo Ribalda Delgado ricardo.ribalda@gmail.com escreveu:
I think that it is in Korea :(. Otherwise I am also in, if possible.
Yes, it will be in Korea together with the Kernel Summit.
Who will be in Dublin next week? Couldn't we arrange something? At least a dinner?
I won't.
Regards, Mauro
On October 1, 2015 6:39:23 PM GMT+01:00, Ricardo Ribalda Delgado ricardo.ribalda@gmail.com wrote:
I think that it is in Korea :(. Otherwise I am also in, if possible.
Who will be in Dublin next week? Couldn't we arrange something? At least a dinner?
Regards! On 1 Oct 2015 7:35 pm, "Michael Ira Krufky" mkrufky@linuxtv.org wrote:
I would also like to attend this workshop, if it is being held next week in Dublin.
Thanks & best regards,
Michael Ira Krufky Samsung Electronics America
On Thu, Oct 1, 2015 at 12:48 PM, Shuah Khan shuahkh@osg.samsung.com wrote:
I would like to add the following topics for discussion at the upcoming Media Workshop
- ENT_F_IO appears to be too generic, requiring additional steps to determine what kind of IO function it is really is. I propose preserving and allowing enough uniqueness to enable drivers to tag the functions when they create them. For example, if AUDIO functions are all tagged ENT_F_IO, bridge driver has to determine what kind of IO it really is. This requires finding the Interface entity associated with the function entity or comparing entity
name
strings. Instead, if a function can be tagged as Audio Capture
when
it gets created, these additional steps aren't necessary.
- Discuss snd-usb-audio control interface mapping to media. snd-usb-audio creates a control device file which could be exposed in a media graph. In some cases, it is a simple mixer control. Expose ENT_F_MIXER entity with an associated interface node MEDIA_INTF_T_ALSA_CONTROL
thanks, -- Shuah
-- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shuahkh@osg.samsung.com | (970) 217-8978
media-workshop mailing list media-workshop@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
media-workshop mailing list media-workshop@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
media-workshop mailing list media-workshop@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
I'll arrive in Dublin tomorrow and stay there until October 10th.
Dinner sounds good. Sunday or Tuesday? (I'm assuming you want to go to the speaker's event on Monday, that's usually pretty good).
Regards,
Hans
Le jeudi 01 octobre 2015 à 21:06 +0100, Hans Verkuil a écrit :
I'll arrive in Dublin tomorrow and stay there until October 10th.
Dinner sounds good. Sunday or Tuesday? (I'm assuming you want to go to the speaker's event on Monday, that's usually pretty good).
I'll arrive Saturday (3rd) morning and will be in Dublin till 10th too. I would be happy to join for a diner (both days works for me).
cheers, Nicolas
Hello
On 1 Oct 2015 22:07, "Hans Verkuil" hverkuil@xs4all.nl wrote:
On October 1, 2015 6:39:23 PM GMT+01:00, Ricardo Ribalda Delgado <
ricardo.ribalda@gmail.com> wrote:
I think that it is in Korea :(. Otherwise I am also in, if possible.
Who will be in Dublin next week? Couldn't we arrange something? At least a dinner?
Regards! On 1 Oct 2015 7:35 pm, "Michael Ira Krufky" mkrufky@linuxtv.org wrote:
I would also like to attend this workshop, if it is being held next week in Dublin.
Thanks & best regards,
Michael Ira Krufky Samsung Electronics America
On Thu, Oct 1, 2015 at 12:48 PM, Shuah Khan shuahkh@osg.samsung.com wrote:
I would like to add the following topics for discussion at the upcoming Media Workshop
- ENT_F_IO appears to be too generic, requiring additional steps to determine what kind of IO function it is really is. I propose preserving and allowing enough uniqueness to enable drivers to tag the functions when they create them. For example, if AUDIO functions are all tagged ENT_F_IO, bridge driver has to determine what kind of IO it really is. This requires finding the Interface entity associated with the function entity or comparing entity
name
strings. Instead, if a function can be tagged as Audio Capture
when
it gets created, these additional steps aren't necessary.
- Discuss snd-usb-audio control interface mapping to media. snd-usb-audio creates a control device file which could be exposed in a media graph. In some cases, it is a simple mixer control. Expose ENT_F_MIXER entity with an associated interface node MEDIA_INTF_T_ALSA_CONTROL
thanks, -- Shuah
-- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shuahkh@osg.samsung.com | (970) 217-8978
media-workshop mailing list media-workshop@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
media-workshop mailing list media-workshop@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
media-workshop mailing list media-workshop@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
I'll arrive in Dublin tomorrow and stay there until October 10th.
Dinner sounds good. Sunday or Tuesday? (I'm assuming you want to go to
the speaker's event on Monday, that's usually pretty good).
On Tuesday I have the technical showcase. I rather do it on Sunday.
Like most of you I will be from the 3rd to the 10th.
Anyone knows a good place in Dublin to meet?
See you
Regards,
Hans
Hi Hans,
On Thursday 01 October 2015 21:06:18 Hans Verkuil wrote:
On October 1, 2015 6:39:23 PM GMT+01:00, Ricardo Ribalda Delgado wrote:
On 1 Oct 2015 7:35 pm, "Michael Ira Krufky" wrote:
I would also like to attend this workshop, if it is being held next week in Dublin.
I think that it is in Korea :(. Otherwise I am also in, if possible.
Who will be in Dublin next week? Couldn't we arrange something? At least a dinner?
I'll arrive in Dublin tomorrow and stay there until October 10th.
Dinner sounds good. Sunday or Tuesday? (I'm assuming you want to go to the speaker's event on Monday, that's usually pretty good).
I'll arrive on Sunday the 4th and will leave on Saturday the 10th. Dinner on Sunday or Tuesday is fine.
On 10/01/2015 10:48 AM, Shuah Khan wrote:
I would like to add the following topics for discussion at the upcoming Media Workshop
ENT_F_IO appears to be too generic, requiring additional steps to determine what kind of IO function it is really is. I propose preserving and allowing enough uniqueness to enable drivers to tag the functions when they create them. For example, if AUDIO functions are all tagged ENT_F_IO, bridge driver has to determine what kind of IO it really is. This requires finding the Interface entity associated with the function entity or comparing entity name strings. Instead, if a function can be tagged as Audio Capture when it gets created, these additional steps aren't necessary.
Discuss snd-usb-audio control interface mapping to media. snd-usb-audio creates a control device file which could be exposed in a media graph. In some cases, it is a simple mixer control. Expose ENT_F_MIXER entity with an associated interface node MEDIA_INTF_T_ALSA_CONTROL
Another topic:
Discuss the following patch series to Update ALSA, and au0828 drivers to use Managed Media Controller API. This patch series is based on current MC API. I am working on porting the patch series to MC next gen. Hope to have the patch series out for that in a week.
Let's discuss this to see if this work should be held off until MC next gen.
https://www.mail-archive.com/linux-media@vger.kernel.org/msg92572.html
thanks, -- Shuah
Em Thu, 01 Oct 2015 16:43:21 -0600 Shuah Khan shuahkh@osg.samsung.com escreveu:
On 10/01/2015 10:48 AM, Shuah Khan wrote:
I would like to add the following topics for discussion at the upcoming Media Workshop
ENT_F_IO appears to be too generic, requiring additional steps to determine what kind of IO function it is really is. I propose preserving and allowing enough uniqueness to enable drivers to tag the functions when they create them. For example, if AUDIO functions are all tagged ENT_F_IO, bridge driver has to determine what kind of IO it really is. This requires finding the Interface entity associated with the function entity or comparing entity name strings. Instead, if a function can be tagged as Audio Capture when it gets created, these additional steps aren't necessary.
Discuss snd-usb-audio control interface mapping to media. snd-usb-audio creates a control device file which could be exposed in a media graph. In some cases, it is a simple mixer control. Expose ENT_F_MIXER entity with an associated interface node MEDIA_INTF_T_ALSA_CONTROL
Another topic:
Discuss the following patch series to Update ALSA, and au0828 drivers to use Managed Media Controller API. This patch series is based on current MC API. I am working on porting the patch series to MC next gen. Hope to have the patch series out for that in a week.
Let's discuss this to see if this work should be held off until MC next gen.
https://www.mail-archive.com/linux-media@vger.kernel.org/msg92572.html
Why?
What's exactly your proposal for the userspace API? Will that change after MC next gen?
Regards, Mauro
On 10/02/2015 05:06 AM, Mauro Carvalho Chehab wrote:
Em Thu, 01 Oct 2015 16:43:21 -0600 Shuah Khan shuahkh@osg.samsung.com escreveu:
On 10/01/2015 10:48 AM, Shuah Khan wrote:
I would like to add the following topics for discussion at the upcoming Media Workshop
ENT_F_IO appears to be too generic, requiring additional steps to determine what kind of IO function it is really is. I propose preserving and allowing enough uniqueness to enable drivers to tag the functions when they create them. For example, if AUDIO functions are all tagged ENT_F_IO, bridge driver has to determine what kind of IO it really is. This requires finding the Interface entity associated with the function entity or comparing entity name strings. Instead, if a function can be tagged as Audio Capture when it gets created, these additional steps aren't necessary.
Discuss snd-usb-audio control interface mapping to media. snd-usb-audio creates a control device file which could be exposed in a media graph. In some cases, it is a simple mixer control. Expose ENT_F_MIXER entity with an associated interface node MEDIA_INTF_T_ALSA_CONTROL
Another topic:
Discuss the following patch series to Update ALSA, and au0828 drivers to use Managed Media Controller API. This patch series is based on current MC API. I am working on porting the patch series to MC next gen. Hope to have the patch series out for that in a week.
Let's discuss this to see if this work should be held off until MC next gen.
https://www.mail-archive.com/linux-media@vger.kernel.org/msg92572.html
Why?
Maybe it is not necessary and my ALSA MC patch series and ALSA MC next gen will get reviewed before the summit.
What's exactly your proposal for the userspace API? Will that change after MC next gen?
It has no bearing on userspace API. I should have elaborated what is on my mind better. My question is related to:
1. The scope and the effort involved on my part. i.e if ALSA MC goes in first, ALSA MC next gen patches will change to just the ports to account for new API. 2. Would it make sense to introduce this feature now without coupling it to MC next gen. Pros and cons for both.
My intent is to run this by the maintainers and sub-system maintainers at this summit. If this topic isn't appropriate for the summit, then I withdraw my proposal for this topic.
thanks, -- Shuah
Em Tue, 06 Oct 2015 07:17:07 -0600 Shuah Khan shuahkh@osg.samsung.com escreveu:
On 10/02/2015 05:06 AM, Mauro Carvalho Chehab wrote:
Em Thu, 01 Oct 2015 16:43:21 -0600 Shuah Khan shuahkh@osg.samsung.com escreveu:
On 10/01/2015 10:48 AM, Shuah Khan wrote:
I would like to add the following topics for discussion at the upcoming Media Workshop
ENT_F_IO appears to be too generic, requiring additional steps to determine what kind of IO function it is really is. I propose preserving and allowing enough uniqueness to enable drivers to tag the functions when they create them. For example, if AUDIO functions are all tagged ENT_F_IO, bridge driver has to determine what kind of IO it really is. This requires finding the Interface entity associated with the function entity or comparing entity name strings. Instead, if a function can be tagged as Audio Capture when it gets created, these additional steps aren't necessary.
Discuss snd-usb-audio control interface mapping to media. snd-usb-audio creates a control device file which could be exposed in a media graph. In some cases, it is a simple mixer control. Expose ENT_F_MIXER entity with an associated interface node MEDIA_INTF_T_ALSA_CONTROL
Another topic:
Discuss the following patch series to Update ALSA, and au0828 drivers to use Managed Media Controller API. This patch series is based on current MC API. I am working on porting the patch series to MC next gen. Hope to have the patch series out for that in a week.
Let's discuss this to see if this work should be held off until MC next gen.
https://www.mail-archive.com/linux-media@vger.kernel.org/msg92572.html
Why?
Maybe it is not necessary and my ALSA MC patch series and ALSA MC next gen will get reviewed before the summit.
What's exactly your proposal for the userspace API? Will that change after MC next gen?
It has no bearing on userspace API.
Sorry, but that makes no sense ;) the MC is a Kernel->userspace API.
Whatever you do in order to add support for ALSA, you'll need to add entities/functions/interfaces at the userspace API, and we don't add new APIs that we know in advance that they will be changed soon. That's basically the reason why we marked the DVB MC part as BROKEN: because we new that we would be mapping the entities and interfaces on some different way.
What I'm asking is if merging your RFC patches without MC next gen and then moving to next gen, the userspace API won't change? If the answer is yes, then we can't do that even if we want.
We're basically stuck on merging any new things related to MC until we fix the API.
I should have elaborated what is on my mind better. My question is related to:
- The scope and the effort involved on my part. i.e if ALSA MC goes in first, ALSA MC next gen patches will change to just the ports to account for new API.
- Would it make sense to introduce this feature now without coupling it to MC next gen. Pros and cons for both.
My intent is to run this by the maintainers and sub-system maintainers at this summit. If this topic isn't appropriate for the summit, then I withdraw my proposal for this topic.
thanks, -- Shuah
On 10/06/2015 09:37 AM, Mauro Carvalho Chehab wrote:
Em Tue, 06 Oct 2015 07:17:07 -0600 Shuah Khan shuahkh@osg.samsung.com escreveu:
On 10/02/2015 05:06 AM, Mauro Carvalho Chehab wrote:
Em Thu, 01 Oct 2015 16:43:21 -0600 Shuah Khan shuahkh@osg.samsung.com escreveu:
On 10/01/2015 10:48 AM, Shuah Khan wrote:
I would like to add the following topics for discussion at the upcoming Media Workshop
ENT_F_IO appears to be too generic, requiring additional steps to determine what kind of IO function it is really is. I propose preserving and allowing enough uniqueness to enable drivers to tag the functions when they create them. For example, if AUDIO functions are all tagged ENT_F_IO, bridge driver has to determine what kind of IO it really is. This requires finding the Interface entity associated with the function entity or comparing entity name strings. Instead, if a function can be tagged as Audio Capture when it gets created, these additional steps aren't necessary.
Discuss snd-usb-audio control interface mapping to media. snd-usb-audio creates a control device file which could be exposed in a media graph. In some cases, it is a simple mixer control. Expose ENT_F_MIXER entity with an associated interface node MEDIA_INTF_T_ALSA_CONTROL
Another topic:
Discuss the following patch series to Update ALSA, and au0828 drivers to use Managed Media Controller API. This patch series is based on current MC API. I am working on porting the patch series to MC next gen. Hope to have the patch series out for that in a week.
Let's discuss this to see if this work should be held off until MC next gen.
https://www.mail-archive.com/linux-media@vger.kernel.org/msg92572.html
Why?
Maybe it is not necessary and my ALSA MC patch series and ALSA MC next gen will get reviewed before the summit.
What's exactly your proposal for the userspace API? Will that change after MC next gen?
It has no bearing on userspace API.
Sorry, but that makes no sense ;) the MC is a Kernel->userspace API.
Whatever you do in order to add support for ALSA, you'll need to add entities/functions/interfaces at the userspace API, and we don't add new APIs that we know in advance that they will be changed soon. That's basically the reason why we marked the DVB MC part as BROKEN: because we new that we would be mapping the entities and interfaces on some different way.
What I'm asking is if merging your RFC patches without MC next gen and then moving to next gen, the userspace API won't change? If the answer is yes, then we can't do that even if we want.
We're basically stuck on merging any new things related to MC until we fix the API.
The ALSA entities represented in MC userspace will change from MC to MC Next Gen as a result of new types of entities in MC next gen. These changes could be looked at as an evolution as opposed to change.
The important feature ALSA work brings is the resource sharing which happens to use MC framework. Introducing this feature sooner is better than later. So my concern is that if this feature might get delayed if gets linked to MC Next Gen. Maybe we should get MC Next Gen in as soon as possible. :)
thanks, -- Shuah
Em Wed, 07 Oct 2015 07:23:06 -0600 Shuah Khan shuahkh@osg.samsung.com escreveu:
On 10/06/2015 09:37 AM, Mauro Carvalho Chehab wrote:
Em Tue, 06 Oct 2015 07:17:07 -0600 Shuah Khan shuahkh@osg.samsung.com escreveu:
We're basically stuck on merging any new things related to MC until we fix the API.
The ALSA entities represented in MC userspace will change from MC to MC Next Gen as a result of new types of entities in MC next gen. These changes could be looked at as an evolution as opposed to change.
The important feature ALSA work brings is the resource sharing which happens to use MC framework. Introducing this feature sooner is better than later. So my concern is that if this feature might get delayed if gets linked to MC Next Gen. Maybe we should get MC Next Gen in as soon as possible. :)
I agree that this is an important feature, but it only makes sense when we have DVB support at MC.
So, yes, we need to get MC Next Gen as soon as possible.
Regards, Mauro
-
Hans Verkuil -
Laurent Pinchart -
Mauro Carvalho Chehab -
Michael Ira Krufky -
Nicolas Dufresne -
Ricardo Ribalda Delgado -
Shuah Khan