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=-5.8 required=3.0 tests=BAYES_00,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 B0E58C433EF for ; Tue, 14 Sep 2021 13:45:28 +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 5BC4060187 for ; Tue, 14 Sep 2021 13:45:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5BC4060187 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 79CDC89F06; Tue, 14 Sep 2021 13:45:27 +0000 (UTC) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9C77089F06 for ; Tue, 14 Sep 2021 13:45:25 +0000 (UTC) Received: by mail-wr1-x434.google.com with SMTP id m9so20361549wrb.1 for ; Tue, 14 Sep 2021 06:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=q88PHoVb5jvhEfJnS/DCAVr7Ruy8cemNefYxYmwyLPg=; b=VtLFTNghM0LZuPJF89yYY0uOgmTI/iJzJV6UIhyHRpZYR1rfLWohpNmulB7/jFURw/ fNpb5b3YzTDm/WVsPpqQGQ03HVGqsu0BXwMu6j7bxvC8mrjnATLp7oeXU5KGeWVry+6A 3H/aC7uJEjy7ovV5YJxdZec7n4JdbIJzqZMoo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=q88PHoVb5jvhEfJnS/DCAVr7Ruy8cemNefYxYmwyLPg=; b=gjcSa2RvuxT8kl5TfGHAT73GrKmRyWcsVCvOn42NVVkjwW/2XPWsL9Tcl1JOZHjV1k oDb2M2KiZH1xFFlm34888Hc7ZwJjsaimCggvIx5fT62zSnuEQmusGMg+pKg+rALKLAVz 894uUyC+gO1+oavIiVffTbmeJTU7gkwpX2bCVwlHcCaPvPMhTdeennPoArgOVz+52ylp O94Wb8Nkdl/HQW3Fv1X7q9dlB5JK+SdmbeU6G5zE3s7z9+PWdZo+vlofDNrYrz6CRqBX mvzF+9fwfQ7wftBBHuyU7mUFuTxEPSos8mdC4Q9WkJ1ZAsB9zi9O6qOF5L2+XTi/kyve t48g== X-Gm-Message-State: AOAM533DMvG2XFg3m6WUoqvUxYbAMEXXkuB4O8oo9NI/0A9TCqUWHx4G 88bDMQR1luB5RPsUiICv1lk9kg== X-Google-Smtp-Source: ABdhPJyq3Ugx3TTf5dB/kirmHu9/SKZVJmwF+NgKj8J2HtRd4EzCe+4a5EW0VSVxBxZZhlp9UzwJOw== X-Received: by 2002:adf:d239:: with SMTP id k25mr9868206wrh.383.1631627124049; Tue, 14 Sep 2021 06:45:24 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id l3sm1170307wms.4.2021.09.14.06.45.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Sep 2021 06:45:23 -0700 (PDT) Date: Tue, 14 Sep 2021 15:45:21 +0200 From: Daniel Vetter To: Pekka Paalanen Cc: Daniel Vetter , Hans de Goede , Dennis Filder , dri-devel Subject: Re: Handling DRM master transitions cooperatively Message-ID: References: <20210907130746.7b667dac@eldfell> <20210908103603.44a533bb@eldfell> <20210909103703.09a573e4@eldfell> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210909103703.09a573e4@eldfell> X-Operating-System: Linux phenom 5.10.0-8-amd64 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: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, Sep 09, 2021 at 10:37:03AM +0300, Pekka Paalanen wrote: > On Wed, 8 Sep 2021 18:27:09 +0200 > Daniel Vetter wrote: > > > On Wed, Sep 8, 2021 at 9:36 AM Pekka Paalanen wrote: > > > > > > On Tue, 7 Sep 2021 14:42:56 +0200 > > > Hans de Goede wrote: > > > > > > > Hi, > > > > > > > > On 9/7/21 12:07 PM, Pekka Paalanen wrote: > > > > > On Fri, 3 Sep 2021 21:08:21 +0200 > > > > > Dennis Filder wrote: > > > > > > > > > >> Hans de Goede asked me to take a topic from a private discussion here. > > > > >> I must also preface that I'm not a graphics person and my knowledge of > > > > >> DRI/DRM is cursory at best. > > > > >> > > > > >> I initiated the conversation with de Goede after learning that the X > > > > >> server now supports being started with an open DRM file descriptor > > > > >> (this was added for Keith Packard's xlease project). I wondered if > > > > >> that could be used to smoothen the Plymouth->X transition somehow and > > > > >> asked de Goede if there were any such plans. He denied, but mentioned > > > > >> that a new ioctl is in the works to prevent the kernel from wiping the > > > > >> contents of a frame buffer after a device is closed, and that this > > > > >> would help to keep transitions smooth. > > > > > > > > > > Hi, > > > > > > > > > > I believe the kernel is not wiping anything on device close. If > > > > > something in the KMS state is wiped, it originates in userspace: > > > > > > > > > > - Plymouth doing something (e.g. RmFB on an in-use FB will turn the > > > > > output off, you need to be careful to "leak" your FB if you want a > > > > > smooth hand-over) > > > > > > > > The "kernel is not wiping anything on device close" is not true, > > > > when closing /dev/dri/card# any remaining FBs from the app closing > > > > it will be dealt with as if they were RmFB-ed, causing the screen > > > > to show what I call "the fallback fb", at least with the i915 driver. > > > > > > No, that's not what should happen AFAIK. > > > > > > True, all FBs that are not referenced by active CRTCs or planes will > > > get freed, since their refcount drops to zero, but those CRTCs and > > > planes that are active will remain active and therefore keep their > > > reference to the respective FBs and so the FBs remain until replaced or > > > turned off explicitly (by e.g. fbcon if you switch to that rather than > > > another userspace KMS client). I believe that is the whole reason why > > > e.g. DRM_IOCTL_MODE_GETFB2 can be useful, otherwise the next KMS client > > > would not have anything to scrape. > > > > > > danvet, what is the DRM core intention? > > > > Historical accidents mostly. There's two things that foil easy > > handover to the next compositor: > > - RMFB instead of CLOSEFB semantics, especially when closing the > > drmfd. This is uapi, so anything we change needs to be opt-in > > What does this mean and refer to? > > Are you trying to say, that closing the DRM device fd (freeing the file > description) causes an implicit RmFB on all the FBs tied to that DRM > device file description? > > I never realised that before. Yes, final close does iterate over fb and do an RMFB. Which is why we've had this discussion whether closefb semantics should be an ADDFB2 flag at creation time instead. > > - Forced fbdev restore on final close of all drm fd. This is only > > prevented if there's a drm master left around (systemd-logind can keep > > that instead of forcing the compositor to survive until the other has > > taken over, which it needs to do anyway to prevent the drm master > > handover from going sideways). This can be fixed by simply disabling > > fbdev completely, which you really want to do anyway. Again it's uabi, > > people will complain if we break this I think. > > Do you mean that it is not enough to leave the tty in KD_GRAPHICS mode > to stop fbcon/fbdev from taking over? Nope. You need an open drm master. This is because we do actually support /dev/fb clients rendering in KD_GRAPHICS mode for backwards compat with the fbdev subsystem. > Is it really fbdev on its own rather than fbcon (poking at fbdev) that > will change the KMS state? > > That is, it's not enough to disable fbcon? fbcon doesn't disable fbdev, and the only way to block fbdev is to have a drm master around. I guess we could try and make this smarter by creating some kind of weak master status for fbdev, but only when either fbcon or fbdev is opened. Maybe this would help? fbdev already keep track of this open count, so wouldn't be too onerous to wire that up into drm_client. The problem there is then that not yet all drivers use the drm_client stuff for fbdev emulation, so you'd need to either convert more, or hack up a few more things to make this consistent. > > > Or am I confused because display servers do not tend to close the DRM > > > device fd on switch-out but Plymouth does (too early)? > > > > Yeah, that stops both forced restore/disable from kicking in. > > Which "that"? that = open drm master. Open drm master alwasy wins agains fbdev/fbcon, and with latest patches it's guaranteed to be race free. > > > If so, why can't Plymouth keep the device open longer and quit only > > > when the hand-off is complete? Not quitting too early would be a > > > prerequisite for any explicit hand-off protocol as well. > > > > With closefb semantics and fbdev disabled plymouth could quit early, > > and things still work. > > What is "closefb semantics"? closefb semantics = no forced plane/crtc disable, active plane keeps a drm_fb reference rmfb semantics = forced plane/crtc disable, the drm_fb is guaranteed to be forcefully removed from the system Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch