From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6BC04C33CAD for ; Mon, 13 Jan 2020 13:27:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3D82D2080D for ; Mon, 13 Jan 2020 13:27:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KwLq3BNc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726450AbgAMN1G (ORCPT ); Mon, 13 Jan 2020 08:27:06 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:20638 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726277AbgAMN1G (ORCPT ); Mon, 13 Jan 2020 08:27:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578922024; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Vykt4k4qo/INxJ6O9wmCyfd7P58Y/nieoYyULTzMm3E=; b=KwLq3BNcV5sKkHdDQBN0HtrXQdE202FO0YkRg3n9h5WuASyGRvQvgfF8WKwotyQxwb+AXh dKHSLSSey1CpjtI9zcOlPxZpA0p6mOyw1Kt4bnqOKgeCwpZ50M9vJ2HWLqNkxjhRUt8dTX wf9HamIpICOW5qbjhO5RJz7QERpW/N4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-61-O64qwIR7OV-8kJcWPu0KEA-1; Mon, 13 Jan 2020 08:27:01 -0500 X-MC-Unique: O64qwIR7OV-8kJcWPu0KEA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EF49E800A02; Mon, 13 Jan 2020 13:26:58 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-106.ams2.redhat.com [10.36.116.106]) by smtp.corp.redhat.com (Postfix) with ESMTP id CF76C60C63; Mon, 13 Jan 2020 13:26:55 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id E0E5931E49; Mon, 13 Jan 2020 14:26:54 +0100 (CET) Date: Mon, 13 Jan 2020 14:26:54 +0100 From: Gerd Hoffmann To: Tomasz Figa Cc: Dmitry Sepp , spice-devel@lists.freedesktop.org, Keiichi Watanabe , virtio-dev@lists.oasis-open.org, Linux Media Mailing List , Alexandre Courbot , Alex Lau , Daniel Vetter , Dylan Reid , Enrico Granata , Frediano Ziglio , Hans Verkuil , =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Pawel Osciak , David Stevens , uril@redhat.com Subject: Re: [virtio-dev] Re: [PATCH v2 0/1] VirtIO video device specification Message-ID: <20200113132654.r4lhspfx2z7zse2v@sirius.home.kraxel.org> References: <20191218130214.170703-1-keiichiw@chromium.org> <7740094.NyiUUSuA9g@os-lin-dmo> <20200113095636.blov62o4gbf27om5@sirius.home.kraxel.org> <12433898.dW097sEU6C@os-lin-dmo> <20200113110521.5ogc3fcy4zq32yzg@sirius.home.kraxel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi, > > Well, no. Tomasz Figa had splitted the devices into three groups: > > > > (1) requires single buffer. > > (2) allows any layout (including the one (1) devices want). > > (3) requires per-plane buffers. > > > > Category (3) devices are apparently rare and old. Both category (1)+(2) > > devices can handle single buffers just fine. So maybe support only > > that? > > From the guest implementation point of view, Linux V4L2 currently > supports 2 cases, if used in allocation-mode (i.e. the buffers are > allocated locally by V4L2): > > i) single buffer with plane offsets predetermined by the format, (can > be handled by devices from category 1) and 2)) > ii) per-plane buffers with planes at the beginning of their own > buffers. (can be handled by devices from category 2) and 3)) > > Support for ii) is required if one wants to be able to import buffers > with arbitrary plane offsets, so I'd consider it unavoidable. If you have (1) hardware you simply can't import buffers with arbitrary plane offsets, so I'd expect software would prefer the single buffer layout (i) over (ii), even when using another driver + dmabuf export/import, to be able to support as much hardware as possible. So (ii) might end up being unused in practice. But maybe not, was just an idea, feel free to scratch it. cheers, Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-6653-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 40F0D985CD4 for ; Mon, 13 Jan 2020 13:27:05 +0000 (UTC) Date: Mon, 13 Jan 2020 14:26:54 +0100 From: Gerd Hoffmann Message-ID: <20200113132654.r4lhspfx2z7zse2v@sirius.home.kraxel.org> References: <20191218130214.170703-1-keiichiw@chromium.org> <7740094.NyiUUSuA9g@os-lin-dmo> <20200113095636.blov62o4gbf27om5@sirius.home.kraxel.org> <12433898.dW097sEU6C@os-lin-dmo> <20200113110521.5ogc3fcy4zq32yzg@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: Subject: Re: [virtio-dev] Re: [PATCH v2 0/1] VirtIO video device specification Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline To: Tomasz Figa Cc: Dmitry Sepp , spice-devel@lists.freedesktop.org, Keiichi Watanabe , virtio-dev@lists.oasis-open.org, Linux Media Mailing List , Alexandre Courbot , Alex Lau , Daniel Vetter , Dylan Reid , Enrico Granata , Frediano Ziglio , Hans Verkuil , =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Pawel Osciak , David Stevens , uril@redhat.com List-ID: Hi, > > Well, no. Tomasz Figa had splitted the devices into three groups: > > > > (1) requires single buffer. > > (2) allows any layout (including the one (1) devices want). > > (3) requires per-plane buffers. > > > > Category (3) devices are apparently rare and old. Both category (1)+(2= ) > > devices can handle single buffers just fine. So maybe support only > > that? >=20 > From the guest implementation point of view, Linux V4L2 currently > supports 2 cases, if used in allocation-mode (i.e. the buffers are > allocated locally by V4L2): >=20 > i) single buffer with plane offsets predetermined by the format, (can > be handled by devices from category 1) and 2)) > ii) per-plane buffers with planes at the beginning of their own > buffers. (can be handled by devices from category 2) and 3)) >=20 > Support for ii) is required if one wants to be able to import buffers > with arbitrary plane offsets, so I'd consider it unavoidable. If you have (1) hardware you simply can't import buffers with arbitrary plane offsets, so I'd expect software would prefer the single buffer layout (i) over (ii), even when using another driver + dmabuf export/import, to be able to support as much hardware as possible. So (ii) might end up being unused in practice. But maybe not, was just an idea, feel free to scratch it. cheers, Gerd --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org