Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp718418pxv; Thu, 24 Jun 2021 18:57:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzoit/NC9sFZhbTSNYt3S2ZvwZNIg7lcmvrlpItehhWpXSQqTjPT55lEkszoEeCKs1UXfcA X-Received: by 2002:a92:dcc5:: with SMTP id b5mr5943183ilr.306.1624586236029; Thu, 24 Jun 2021 18:57:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624586236; cv=none; d=google.com; s=arc-20160816; b=uL+lQQ0T99CZ8eIdzH0Ts9tEE7U7mu7GWYWJ/j+jj+icQgTa3Vxc5tmoVZdm1fFCGI eubrr3jpi8CxR/3Q/S3bUB8ITebvCQUu+O0jyCMEY6WwVtcCxKFWRzlpey3yv8bmyCoB 6hPOJlylvjdmHv3dFZSNbWU+q5Y+D/Meql0PfhKpEJHMf715DzsQ4LYUo+yZ5PDm+VLE b45VofqywemxtV+Q/d66Vvu7eI1NAQmnyKMUW0dlan6sOCZ6dsPWgVfFqOQnD6dEGcFJ 7eJ5cM4yfsBT9p7mMEsZLXCp5m2OXrz89ttUCsN+IajMbGFCSgo6JxbO61aY7C020AvY pRFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=DgvXn3PwiL33+V2MPigrwm2vtPfix09cjVm/yIwhB0s=; b=R/xlUV6W0Fc5iBKCkK6W5ZtJb8O+pmQgKH17p5u+DKJobAd5UvXxVclpb/w3uJoCO+ pvWpIgC5RseL+lWYSMq+NeTdWU/38ZaUsaagDRDq3ezmyc52ui4s9HfYjeJ/LlFgQqnM ZRNpv4Y/bXRIYlI6La/sO5c+qC5GPErTv0NcuKNYllEU4rVlMx/m7eso/CuvYUY2nRrL 2BZ3XpHZcfmMv8R+lsCd4DA1vW8CwC8SV0TElewzecP9qzq/urbEw8j4ULXbAnIPy14f +kXDe8s26VTmGiL8wCZZnux5axuimyIfY3CihdGC7bNE3R2S6HyFJLkIB6X9awPLE8fu i0ZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@igel-co-jp.20150623.gappssmtp.com header.s=20150623 header.b=s504KnWS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v6si6058080ilu.109.2021.06.24.18.57.03; Thu, 24 Jun 2021 18:57:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@igel-co-jp.20150623.gappssmtp.com header.s=20150623 header.b=s504KnWS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232917AbhFYB5r (ORCPT + 99 others); Thu, 24 Jun 2021 21:57:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232933AbhFYB5q (ORCPT ); Thu, 24 Jun 2021 21:57:46 -0400 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C45F6C061574 for ; Thu, 24 Jun 2021 18:55:26 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id i6so6802350pfq.1 for ; Thu, 24 Jun 2021 18:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=igel-co-jp.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=DgvXn3PwiL33+V2MPigrwm2vtPfix09cjVm/yIwhB0s=; b=s504KnWSPBnvlcVjrEkj0svXJJPV6FPA89XUVCkhTJUFi3FXCxXk0vrr+kE/IWAQLw COILHQO/0uk6k4XjWfxli245zRoL5KQrd3PzK9eyzyl69Dc44ZS90zepOBMSuPFKqNdC NPqrg9y7CMaLdTSygxpqPWstw4cIfQtBJp5qV50EzWtU6QgDeUdyik0NdWC4dBXlYf+7 XsGa0Nsow2vmK8WHFEroSERvbLoGgxq15Fn02eSDy+uiO2b5cvI6duDNHv4e3KTBmMFE mHesyVocr9PpxKjE4gWng4Wxb3CbAKBGZuf53Xc8lK4WGIWUyIdBedPkVn0kVV2qe21z FXSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DgvXn3PwiL33+V2MPigrwm2vtPfix09cjVm/yIwhB0s=; b=RfLvwvBA7rA3+tMh5WKWRrI5tsvH23wDx/fZHEx3re/1tCggR7X+73cx23g7DmjhDy E2Cz+0/CxCGAVCijHliZtauN8v3vroJcolpYJy0232NjxRRM+9GJNBXEjsIHxRM0Zj+X z/2U+7C6+y1YCNOkhYcsvlLWaVXp7ShtXEk0pr5dkA4auGzMFP+NpGNqCDlG54xka+iA MYJKKfi7L3garZ3P7WBpFYkPf743Vm5RD9R+DTYiVCj+rNMQaIBjsM2jO5T3cbvrSiym 3mLPfOHLktbycnvGuocQXBD0ztNvShqZWYWosaH9ojqoPATn01Bb1wU7lkjpzNbhZhdt eVcw== X-Gm-Message-State: AOAM531H052zD7+SGkTJ4w3lT1PZ2Z2h0UVb8oa3KlSPERS8KlkyZuiU nf2Q2djfDyRqH1qJRfYEt5YM6A== X-Received: by 2002:a62:5444:0:b029:2e9:c69d:dc64 with SMTP id i65-20020a6254440000b02902e9c69ddc64mr7771482pfb.32.1624586126291; Thu, 24 Jun 2021 18:55:26 -0700 (PDT) Received: from ?IPv6:240b:10:c9a0:ca00:55ca:cffa:65dd:ae53? ([240b:10:c9a0:ca00:55ca:cffa:65dd:ae53]) by smtp.gmail.com with ESMTPSA id n69sm4037663pfd.132.2021.06.24.18.55.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Jun 2021 18:55:25 -0700 (PDT) Subject: Re: [PATH 0/4] [RFC] Support virtual DRM To: Pekka Paalanen Cc: "Enrico Weigelt, metux IT consult" , devicetree@vger.kernel.org, Takanari Hayama , Thomas Zimmermann , linux-doc@vger.kernel.org, David Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Kieran Bingham , Laurent Pinchart , Damian Hobson-Garcia References: <20210621062742.26073-1-etom@igel.co.jp> <7cde82a9-c60c-e527-eeac-eaad0c5842a1@metux.net> <1cfab5f9-f275-aa53-00de-5da3fcea71c5@igel.co.jp> <20210622111239.73aa87aa@eldfell> <20210623113922.1e603139@eldfell> <20210623144115.1bc55db1@eldfell> From: Esaki Tomohito Message-ID: Date: Fri, 25 Jun 2021 10:55:20 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210623144115.1bc55db1@eldfell> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/06/23 20:41, Pekka Paalanen wrote: > On Wed, 23 Jun 2021 18:22:47 +0900 > Esaki Tomohito wrote: > >> On 2021/06/23 17:39, Pekka Paalanen wrote: >>> On Wed, 23 Jun 2021 15:56:05 +0900 >>> Esaki Tomohito wrote: >>> >>>> Hi, >>>> Thank you all for your comments. >>>> >>>> On 2021/06/22 17:12, Pekka Paalanen wrote: >>>>> On Tue, 22 Jun 2021 13:03:39 +0900 >>>>> Esaki Tomohito wrote: >>>>> >>>>>> Hi, Enrico Weigelt >>>>>> Thank you for reply. >>>>>> >>>>>> On 2021/06/22 1:05, Enrico Weigelt, metux IT consult wrote: >>>>>>> On 21.06.21 08:27, Tomohito Esaki wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>>> Virtual DRM splits the overlay planes of a display controller into multiple >>>>>>>> virtual devices to allow each plane to be accessed by each process. >>>>>>>> >>>>>>>> This makes it possible to overlay images output from multiple processes on a >>>>>>>> display. For example, one process displays the camera image without compositor >>>>>>>> while another process overlays the UI. >>>>>>> >>>>>>> Are you attempting to create an simple in-kernel compositor ? >>>>>> >>>>>> I think the basic idea is the same as DRMlease. >>>>> >>>>> Hi, >>>>> >>>>> indeed. Why not use DRM leases instead? >>>>> >>>> >>>> In this use case, I understand that this is not possible with DRM lease, >>>> am I wrong? >>>> I understand that it’s not possible to lease a plane and update planes >>>> on the same output independently from different processes in current DRM >>>> lease. >>>> >>>> If this is correct, what do you think of adding support for plane leases >>>> to the DRM lease to handle this case? >>> >>> Hi, >>> >>> I would love to see support added for leasing individual planes, >>> especially to replace the virtual DRM proposal which seems to be >>> eradicating everything that atomic modesetting and nuclear pageflip >>> have built over the many years. >>> >>> However, please note that "on the same output independently" is >>> physically impossible. Semantically, the planes define what a CRTC >>> scans out, and the CRTC defines the scanout timings. Therefore it is not >>> possible to update individual planes independently, they will all >>> always share the timings of the CRTC. >>> >>> That combined with KMS not allowing multiple updates to be queued at >>> the same time for the same CRTC (atomic commits and legacy pageflips >>> returning EBUSY) makes the plane updates very much inter-dependent. >>> >>> If you want to avoid EBUSY and have planes update on the vblank you >>> intended, you really need a userspace compositor to pull everything >>> together *before* submitting anything to the kernel. >> >> Hi, >> >> Thank you for your comments and advice. >> I will consider leasing a plane. > > Hi, > > I wish you considered a userspace compositor first, once more, with > passion. > > It does not need to be Weston, and it does not need to use Wayland. > Just a userspace daemon that owns the whole display device and somehow > talks to whatever else wants stuff on screen. > > I have not seen any evidence that leasing individual planes would do > you any good. I can easily see it doing you harm. I'm only saying that > it would be better than the virtual DRM proposal if you absolutely have > to go there. Please, consider not going there at all. > > "On the same output independently" is not possible for the very simple > reason that the pixel data needs to be streamed serially to a monitor. > Hi, Thank you for your advice. Once again, I'll consider a userspace compositor first. Best regards Esaki