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=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 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 94165C4743C for ; Wed, 23 Jun 2021 11:41:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7CA9F60249 for ; Wed, 23 Jun 2021 11:41:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230273AbhFWLnm (ORCPT ); Wed, 23 Jun 2021 07:43:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230121AbhFWLni (ORCPT ); Wed, 23 Jun 2021 07:43:38 -0400 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5220CC061574; Wed, 23 Jun 2021 04:41:21 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id r5so3600768lfr.5; Wed, 23 Jun 2021 04:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=4jXNkZBkJCroCZHEHJk4Yl0iihmMmzV2M0MO5HkyT6Q=; b=YYkBUkBpU74bPcyMCofnr6vYjMEV/taXJMbO203C+UhmzYMZlLtfIj6jjYVfkot34R FRyZMgx0hOwJNSjaJgn3ZOrlsluA8fZdlaumVe0xerzgjPQJxZrJa4mtYIAs/LaBOTbo ewVkZ9FycNDqwmYWW6cgAHTtmI0xJHp4OCk2qEJOoT+tBqJtDXzz0iaNEK77VOU/eCRD lUWBEWcMnE40AGTXpElCm1wymHKCcpGZ3gAdO1qxfGTqFqGb+wIM2iy9eFKW2LZ0lffi SbtHGSiq/ZNnIBSpy+Q1eRqbzNjFSx6103ZvlmIIE5VySWxlOozjSZX6LO5Iu9FC8FWL a3aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=4jXNkZBkJCroCZHEHJk4Yl0iihmMmzV2M0MO5HkyT6Q=; b=cvwyC2KcUyrJ3GORW6Bw2jBEFtkKXwsX7zI3DqnwrphoIrVt0C8eJoEd3naMEPPigq ECebahYq02xL3E3bJVscV2sGvyf+1ZpWrf6empyxHl5BD/JqW2bgA+Up67UfC8pRYZkh A/T2Wo5YkI9ALJpUkLg8xVaGqwnRbnBW6S0xpgaSxixXTEXIlsqAhgDKQhNE+ZXUy2iK GEfCGNTgjnlOS6VEmh/H0DambS3zf8CJYV4y/6gXVDHG/2Wlc77YWUihvzCUDvzbplfL 3Yo0TCIQ8BS/vZv1XG9hFce/6NBwJpMbPtwPkdLlRhw53tqeaNmZyp1S2KcEDHz3g3SX idgw== X-Gm-Message-State: AOAM5338tLZw0yskCHxhOD+TBSb4IW7Fe3R2SXKprvQocqiaHbw+3/tl uIEjy+oyJEtVzowEJfrDfLU= X-Google-Smtp-Source: ABdhPJzQLBEqhzr9/Fy6xHJQZ8lzEEnYgFyW2SIS8NS68pVkr6MWIEVK/UvsgUwXnzeArDL4SiA5+A== X-Received: by 2002:a05:6512:1191:: with SMTP id g17mr4457991lfr.347.1624448479689; Wed, 23 Jun 2021 04:41:19 -0700 (PDT) Received: from eldfell ([194.136.85.206]) by smtp.gmail.com with ESMTPSA id c12sm2067401lfc.32.2021.06.23.04.41.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Jun 2021 04:41:19 -0700 (PDT) Date: Wed, 23 Jun 2021 14:41:15 +0300 From: Pekka Paalanen To: Esaki Tomohito 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 Subject: Re: [PATH 0/4] [RFC] Support virtual DRM Message-ID: <20210623144115.1bc55db1@eldfell> In-Reply-To: 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> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/ljMzJSbhx05gG.4fz0yC81V"; protocol="application/pgp-signature"; micalg=pgp-sha256 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Sig_/ljMzJSbhx05gG.4fz0yC81V Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: > > =20 > >> Hi, > >> Thank you all for your comments. > >> > >> On 2021/06/22 17:12, Pekka Paalanen wrote: =20 > >>> On Tue, 22 Jun 2021 13:03:39 +0900 > >>> Esaki Tomohito wrote: > >>> =20 > >>>> Hi, Enrico Weigelt > >>>> Thank you for reply. > >>>> > >>>> On 2021/06/22 1:05, Enrico Weigelt, metux IT consult wrote: =20 > >>>>> On 21.06.21 08:27, Tomohito Esaki wrote: > >>>>> > >>>>> Hi, > >>>>> =20 > >>>>>> 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 proc= esses on a > >>>>>> display. For example, one process displays the camera image withou= t compositor > >>>>>> while another process overlays the UI. =20 > >>>>> > >>>>> Are you attempting to create an simple in-kernel compositor ? = =20 > >>>> > >>>> I think the basic idea is the same as DRMlease. =20 > >>> > >>> Hi, > >>> > >>> indeed. Why not use DRM leases instead? > >>> =20 > >> > >> In this use case, I understand that this is not possible with DRM leas= e, > >> am I wrong? > >> I understand that it=E2=80=99s not possible to lease a plane and updat= e planes > >> on the same output independently from different processes in current D= RM > >> lease. > >> > >> If this is correct, what do you think of adding support for plane leas= es > >> to the DRM lease to handle this case? =20 > >=20 > > Hi, > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. =20 >=20 > Hi, >=20 > 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. Thanks, pq --Sig_/ljMzJSbhx05gG.4fz0yC81V Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmDTHdsACgkQI1/ltBGq qqcLZg//QkFy2hWZeB2Fkh+0ETzd5SkUgpmcL5x8+DLBH71YJk0Z3+sb9EhK1jl+ kfcuHCiAE9p1f3VpiOp8c0R7zpPqanhi6epHZ8iUQHksXrt6IG84GntHafCOeTeW 6xhQrCfV9RdhASfrKFTt0AFIcP1nw7daACtGDVMMKoUH5NzdrmEZClqxHFQ+3sti NQZ96YGUNWkbmJ9UMki4qeJ/2Rp77YKUcFXBy4qZ2MZufuAB1iRt85C3DEWJQZOp 0JXxYEfFmaLj+9fEVeI5bMAWlIGbP9tzNhCc74xUhUTnryAOvhb/9X0C0hNiHG9T aJrNBvTEYWayx28S6w8rLSCAoJ3CpMr9pAfZSehxzZDyaRpJf0+Lj55xb9VRUT7V Hx5Wu+2bDdC3BFP0puhbD/bgWTcgHNGmPvVinqFfGoZYsp9nz+q2g4IEB7zYrDyt yJsfPl8b1lGSzWvESjzNVE3QyP99142rULB3YvZa8zbgQuYkIlOMRGWeaJw9FxkI w0zGDMQYZoaJ1kC615SweChTRkkN52CW49MKIsvtVDHdxhIKuD7P3ij6Cq9OAyuW uqa/lz2uBZOrWEfv3S1f/O1fdWO0U1juNIF1DIvszZo4KDjn1Z9flOqd1/gKSzaa NOaKo0UKDqzSrnj/gMdQRk+3aoxOA5WrQ5Uq3wh3juagyeHW1BA= =+5tU -----END PGP SIGNATURE----- --Sig_/ljMzJSbhx05gG.4fz0yC81V-- 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=-2.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 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 71AECC49EA4 for ; Wed, 23 Jun 2021 11:41:23 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3941E60249 for ; Wed, 23 Jun 2021 11:41:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3941E60249 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BC5566E8B5; Wed, 23 Jun 2021 11:41:22 +0000 (UTC) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8AC5F6E8B5 for ; Wed, 23 Jun 2021 11:41:21 +0000 (UTC) Received: by mail-lf1-x12d.google.com with SMTP id j4so3550353lfc.8 for ; Wed, 23 Jun 2021 04:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=4jXNkZBkJCroCZHEHJk4Yl0iihmMmzV2M0MO5HkyT6Q=; b=YYkBUkBpU74bPcyMCofnr6vYjMEV/taXJMbO203C+UhmzYMZlLtfIj6jjYVfkot34R FRyZMgx0hOwJNSjaJgn3ZOrlsluA8fZdlaumVe0xerzgjPQJxZrJa4mtYIAs/LaBOTbo ewVkZ9FycNDqwmYWW6cgAHTtmI0xJHp4OCk2qEJOoT+tBqJtDXzz0iaNEK77VOU/eCRD lUWBEWcMnE40AGTXpElCm1wymHKCcpGZ3gAdO1qxfGTqFqGb+wIM2iy9eFKW2LZ0lffi SbtHGSiq/ZNnIBSpy+Q1eRqbzNjFSx6103ZvlmIIE5VySWxlOozjSZX6LO5Iu9FC8FWL a3aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=4jXNkZBkJCroCZHEHJk4Yl0iihmMmzV2M0MO5HkyT6Q=; b=P/2S7bhu3i0krw5daZ2UvQ45cu1b9LRDLnjra4Axrzo+qmI+ny535M2mg3kyEd2llv R8TPOILw/eUVj3gaN59eLUjWjG+Quc6ttRSzQPQb8n6DWHxmX564a++/LI1XkLt8Kdse qxJAsCTyy36SzZMUX5LxUAPlxLQIJUevOF6zWKL3dUqMTD3hdcR4q/hFvz/2eZpqds3L UKQ9QS5+kQHz+pGjQHgfB08ztJQWeCPpN6kzolLtwo+KOOYT0DlkgmuCKNDg5cYaHay6 QAjPHdmyH2OHpTFEobuXpdLCnJeDRZUo9ZMrUTnEwJmf3Sie5VqFNN/SyGFDlV5v6S7G IiiA== X-Gm-Message-State: AOAM533S8zg2NAissvlSqOD3N/9kP+2XkTr7aYSa8lKyqt9cBsB/O4xv gxx98nQF7RF+hk3pGUTA4Zc= X-Google-Smtp-Source: ABdhPJzQLBEqhzr9/Fy6xHJQZ8lzEEnYgFyW2SIS8NS68pVkr6MWIEVK/UvsgUwXnzeArDL4SiA5+A== X-Received: by 2002:a05:6512:1191:: with SMTP id g17mr4457991lfr.347.1624448479689; Wed, 23 Jun 2021 04:41:19 -0700 (PDT) Received: from eldfell ([194.136.85.206]) by smtp.gmail.com with ESMTPSA id c12sm2067401lfc.32.2021.06.23.04.41.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Jun 2021 04:41:19 -0700 (PDT) Date: Wed, 23 Jun 2021 14:41:15 +0300 From: Pekka Paalanen To: Esaki Tomohito Subject: Re: [PATH 0/4] [RFC] Support virtual DRM Message-ID: <20210623144115.1bc55db1@eldfell> In-Reply-To: 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> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/ljMzJSbhx05gG.4fz0yC81V"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Takanari Hayama , linux-doc@vger.kernel.org, David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org, Kieran Bingham , "Enrico Weigelt, metux IT consult" , Laurent Pinchart , Thomas Zimmermann , Damian Hobson-Garcia Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --Sig_/ljMzJSbhx05gG.4fz0yC81V Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: > > =20 > >> Hi, > >> Thank you all for your comments. > >> > >> On 2021/06/22 17:12, Pekka Paalanen wrote: =20 > >>> On Tue, 22 Jun 2021 13:03:39 +0900 > >>> Esaki Tomohito wrote: > >>> =20 > >>>> Hi, Enrico Weigelt > >>>> Thank you for reply. > >>>> > >>>> On 2021/06/22 1:05, Enrico Weigelt, metux IT consult wrote: =20 > >>>>> On 21.06.21 08:27, Tomohito Esaki wrote: > >>>>> > >>>>> Hi, > >>>>> =20 > >>>>>> 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 proc= esses on a > >>>>>> display. For example, one process displays the camera image withou= t compositor > >>>>>> while another process overlays the UI. =20 > >>>>> > >>>>> Are you attempting to create an simple in-kernel compositor ? = =20 > >>>> > >>>> I think the basic idea is the same as DRMlease. =20 > >>> > >>> Hi, > >>> > >>> indeed. Why not use DRM leases instead? > >>> =20 > >> > >> In this use case, I understand that this is not possible with DRM leas= e, > >> am I wrong? > >> I understand that it=E2=80=99s not possible to lease a plane and updat= e planes > >> on the same output independently from different processes in current D= RM > >> lease. > >> > >> If this is correct, what do you think of adding support for plane leas= es > >> to the DRM lease to handle this case? =20 > >=20 > > Hi, > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. =20 >=20 > Hi, >=20 > 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. Thanks, pq --Sig_/ljMzJSbhx05gG.4fz0yC81V Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmDTHdsACgkQI1/ltBGq qqcLZg//QkFy2hWZeB2Fkh+0ETzd5SkUgpmcL5x8+DLBH71YJk0Z3+sb9EhK1jl+ kfcuHCiAE9p1f3VpiOp8c0R7zpPqanhi6epHZ8iUQHksXrt6IG84GntHafCOeTeW 6xhQrCfV9RdhASfrKFTt0AFIcP1nw7daACtGDVMMKoUH5NzdrmEZClqxHFQ+3sti NQZ96YGUNWkbmJ9UMki4qeJ/2Rp77YKUcFXBy4qZ2MZufuAB1iRt85C3DEWJQZOp 0JXxYEfFmaLj+9fEVeI5bMAWlIGbP9tzNhCc74xUhUTnryAOvhb/9X0C0hNiHG9T aJrNBvTEYWayx28S6w8rLSCAoJ3CpMr9pAfZSehxzZDyaRpJf0+Lj55xb9VRUT7V Hx5Wu+2bDdC3BFP0puhbD/bgWTcgHNGmPvVinqFfGoZYsp9nz+q2g4IEB7zYrDyt yJsfPl8b1lGSzWvESjzNVE3QyP99142rULB3YvZa8zbgQuYkIlOMRGWeaJw9FxkI w0zGDMQYZoaJ1kC615SweChTRkkN52CW49MKIsvtVDHdxhIKuD7P3ij6Cq9OAyuW uqa/lz2uBZOrWEfv3S1f/O1fdWO0U1juNIF1DIvszZo4KDjn1Z9flOqd1/gKSzaa NOaKo0UKDqzSrnj/gMdQRk+3aoxOA5WrQ5Uq3wh3juagyeHW1BA= =+5tU -----END PGP SIGNATURE----- --Sig_/ljMzJSbhx05gG.4fz0yC81V--