Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4359283pxj; Mon, 21 Jun 2021 21:05:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzjNqQWkEo+eTQtOdVwq2et4wzMd9FCYwfVyBqA//Jx6VoL3B3D7TtaZJzX+ft1XzHh0w5K X-Received: by 2002:a05:6402:42d2:: with SMTP id i18mr2142947edc.168.1624334732055; Mon, 21 Jun 2021 21:05:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624334732; cv=none; d=google.com; s=arc-20160816; b=kHcyxX9vfNM74zAlyEgCTXyuhbBqnionUhdTwzhfjMBahfYS8jjm/bjhY9U4Dctbc7 v/McUTOjxfrApXik4dLngsGkAKfHzKM192OjLLNGYfH8P3aHjKMc6tnXJ4w2dnHRD8/Q bfMHsa2zE+6HohYzvEHdsDr3pKWbn7M9KhmqVBqBhFRA6qE+ganS5ickKajGHfktpfkb TmRc5qWhxJl/l1wdO7S/+V8N6H3Qd0G6l8MV5n4uQF9G09K3PDTXLv8djulql6R5tgLv d4EfeW0jKjHp6knQbNXQzCSBWrM/8ZkFf7ffVuSq10WpJIpL+QhIvvhp2KLm20L748sV strQ== 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=LCU0yJ9k9lkuiH4BXOzJ8l7LNMuqUv70T9bND/kl8Tc=; b=rN74sEANVkUh5rK3wAdtjvf7hMJcpf+0cYW46ketCdVsLdj266wM9mTR9sztsFByP/ K0LS9lKfyrich5gwCYv08ShCeCGV2f3S3+1E+n+fFTPZS0dTipJnjs2zsG7j0whHcK6Y X3lNU5LCTxY++8YR5Ijb4Mi76cEYd5ZkeTsjePRSQVAcQ+Yz+/w6Z5I4yeN+YRjX9k2b nq/TWj7pLQJl7pdW67vu9S/bhe1aM8/YzTJb4FwLXl1Q8ccYh0bi2OP06stEkqPO8Bfr QEvTMrwBJLclSgGUaCRu6LihGug3K+908x5ENMxzS0Mqkn0qXXoomcM2xNGSZfILKtFb 1lrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@igel-co-jp.20150623.gappssmtp.com header.s=20150623 header.b=2IRIENBo; 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 gv3si12190335ejc.102.2021.06.21.21.04.57; Mon, 21 Jun 2021 21:05:32 -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=2IRIENBo; 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 S229620AbhFVEFV (ORCPT + 99 others); Tue, 22 Jun 2021 00:05:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229452AbhFVEFU (ORCPT ); Tue, 22 Jun 2021 00:05:20 -0400 Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A6ADC061756 for ; Mon, 21 Jun 2021 21:03:05 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id h4so4458223pgp.5 for ; Mon, 21 Jun 2021 21:03:05 -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=LCU0yJ9k9lkuiH4BXOzJ8l7LNMuqUv70T9bND/kl8Tc=; b=2IRIENBoxAqdiYLU9/rOfm8louoM9XJGUrNr4bDU2GLRrypkgatHI8hkFkeTbyRLbG GT8Nb16qpHMXS+sHckMEspeY/jRj+8I0oJ+xQDQY5gwUOxmGciFsHz3INa2KoN5DLghx 887kkP0AQGfaUA7l3YlEg0I4iq//vGSCtuiTAZpnAOyBu3j7nNkuE0F3ZHhE1m/ZRszu YsdAHz3Cv5q0n9L2hHkLVzqTOCsD3GXOzpOyjxV34rQc12+D55Tva5Rpcj3R7b7qcXn5 Y1pc9qLwY7Lt6RKJIVyCzGTtxHovj1ReEzkFjNi5lnJ9NA39zpgHg7q+s9topcsVBFe9 rOjA== 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=LCU0yJ9k9lkuiH4BXOzJ8l7LNMuqUv70T9bND/kl8Tc=; b=iZqhhmgXuLJEGsERvyASSKuXf30ZnQQSN91RySYcuCiQgYYoyqWQABe2fp6st3RSLH cjX5nkx28N5pfYhAojzkQgyuUVFwwzhs1kivjK9mcfZkHmAHm+sHToAqz2/DK0Qqsd7v R0rqPAnt2EXvqyH85dFkDAAltETYdfB0ZIdZGzs+YDmeXXcy7OOSKHed+zLIA7atYdbF c5IACK+p4ZLZ8x4GQ92XWSdfhmkQy25n4Xs4ygcGJEDJKZ5QoU3BITy4jLe+FxXVyeKy g2SbyacS1ychXO5hpTcZDhiKWI3BDa/AjCR6cCSOm3SUMwU+1+QuBxX8bn6mnBhVdm78 7PDQ== X-Gm-Message-State: AOAM532FAqUpk6On2UCa98yBToexmgVzzsfPL8spW9YPSXYujluV/Cyc aE3VH/pAg1Vqysb7N1tb/+CVhQ== X-Received: by 2002:a05:6a00:1515:b029:2f1:d29:2a44 with SMTP id q21-20020a056a001515b02902f10d292a44mr1605587pfu.51.1624334584489; Mon, 21 Jun 2021 21:03:04 -0700 (PDT) Received: from ?IPv6:240b:10:c9a0:ca00:5192:32ad:e5be:23cd? ([240b:10:c9a0:ca00:5192:32ad:e5be:23cd]) by smtp.gmail.com with ESMTPSA id x20sm16719962pfh.112.2021.06.21.21.03.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Jun 2021 21:03:03 -0700 (PDT) Subject: Re: [PATH 0/4] [RFC] Support virtual DRM To: Thomas Zimmermann Cc: Maarten Lankhorst , Maxime Ripard , David Airlie , Daniel Vetter , Laurent Pinchart , Kieran Bingham , dri-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Damian Hobson-Garcia , Takanari Hayama References: <20210621062742.26073-1-etom@igel.co.jp> <9853d0a9-6053-db64-9c79-40b7e0689eec@suse.de> From: Esaki Tomohito Message-ID: <85593f2f-5aa9-6023-ecba-c5275a468b71@igel.co.jp> Date: Tue, 22 Jun 2021 13:02:59 +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: <9853d0a9-6053-db64-9c79-40b7e0689eec@suse.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Thomas Thank you for reply. On 2021/06/21 16:10, Thomas Zimmermann wrote: > Hi > > Am 21.06.21 um 08:27 schrieb Tomohito Esaki: >> 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. > > I briefly looked over your patches. I didn't understand how this is > different to the functionality of a compositor? Shouldn't this be solved > in userspace? I think when latency is important (e.g., AR, VR, for displaying camera images in IVI systems), there may be use cases where the compositor cannot be used. Normally, when the image is passed through the compositor, it is displayed after 2 VSYNC at most, because the compositor combines the image with VSYNC synchronization. On the other hand, if we use vDRM, the image will be displayed at the next VSYNC, so it will be displayed after 1 VSYNC at most. Also, since the compositor is a single point of failure, we may not want to make it dependent on it. Best regards Tomohito Esaki