Re: [Xen-devel] [PATCH v5 0/1] cameraif: add ABI for para-virtual camera

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.03.19 at 11:43, <george.dunlap@xxxxxxxxxx> wrote:
> On 3/12/19 9:07 AM, Jan Beulich wrote:
>>>>> On 12.03.19 at 09:48, <jgross@xxxxxxxx> wrote:
>>> On 12/03/2019 09:19, Oleksandr Andrushchenko wrote:
>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
>>>>
>>>> Hello!
>>>>
>>>> At the moment Xen [1] already supports some virtual multimedia
>>>> features [2] such as virtual display, sound. It supports keyboards,
>>>> pointers and multi-touch devices all allowing Xen to be used in
>>>> automotive appliances, In-Vehicle Infotainment (IVI) systems
>>>> and many more.
>>>>
>>>> Frontend implementation is available at [3] and the corresponding
>>>> backend at [4]. These are work in progress, but frontend already
>>>> passes v4l2-compliance test for V4L2 drivers. libxl preliminary
>>>> changes are available at [5].
>>>>
>>>> This work adds a new Xen para-virtualized protocol for a virtual
>>>> camera device which extends multimedia capabilities of Xen even
>>>> farther: video conferencing, IVI, high definition maps etc.
>>>>
>>>> The initial goal is to support most needed functionality with the
>>>> final idea to make it possible to extend the protocol if need be:
>>>>
>>>> 1. Provide means for base virtual device configuration:
>>>>  - pixel formats
>>>>  - resolutions
>>>>  - frame rates
>>>> 2. Support basic camera controls:
>>>>  - contrast
>>>>  - brightness
>>>>  - hue
>>>>  - saturation
>>>> 3. Support streaming control
>>>
>>> So since the first post in July 2018 there has been no reaction from
>>> Konrad to this interface. I guess he has plenty of other things to do.
>> 
>> Having gone through all the versions' threads (just their titles) I can't
>> find any explicit ping to him. Yes, five versions should have been
>> enough to draw attention, but then again this may have indicated to
>> him that things are still too much in flux.
>> 
>>> Maybe it would be a good idea to add someone else as a maintainer for
>>> the "PUBLIC I/O INTERFACES AND PV DRIVERS DESIGNS" section in
>>> MAINTAINERS to avoid such stalls in the future?
>> 
>> Well, iirc he had volunteered himself for that role, so I guess the
>> preferred action in such a case would be for him to also step back if
>> his other duties no longer permit him fulfilling the maintainer role here.
>> Without the specific MAINTAINERS entry, as in the old days, THE
>> REST would assume responsibility again, which personally I'd prefer
>> over adding a second individual to the section. Unless someone else
>> (like you) volunteered again.
> 
> The "unless" between "adding a second individual to the section" and
> "someone else... volunteered again" indicates that they're in contrast
> somehow; but I don't understand what contrast you mean.  We certainly
> can't *assign* anyone to that responsibility, so the only way someone
> would get their name down there is to volunteer.

What I meant to express is - if there's no-one to volunteer anyway,
rather than trying to find (read: of course not blindly assign) someone,
I'd prefer responsibility to fall back to THE REST.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel