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=DKIM_ADSP_ALL,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 0627FC433E0 for ; Thu, 9 Jul 2020 07:08:14 +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 CF47320674 for ; Thu, 9 Jul 2020 07:08:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=cs.helsinki.fi header.i=@cs.helsinki.fi header.b="HMfi5i0P" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CF47320674 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=cs.helsinki.fi 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 DFB8B6EA3C; Thu, 9 Jul 2020 07:05:45 +0000 (UTC) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) by gabe.freedesktop.org (Postfix) with ESMTPS id D97DD6E11E for ; Wed, 8 Jul 2020 13:46:20 +0000 (UTC) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Wed, 08 Jul 2020 16:46:18 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type:content-id; s=dkim20130528; bh=awTCU/ E1F8AYEGzQtyDg5Z6lb8ussm3bjtld0DbVbaM=; b=HMfi5i0P1A4Az0bU/zikuo 3nENrfgCYzx7MuVAPvS81ZESs5qRWT1zA3PeFJs8THMUDFOkurnZ4HC1e20GhP9X Hd2l6y4qUHncwrRWH+XF+diRjJ5rGKpWOve+Qg07RLV++S7vS1u+LKzw+ZJhRhaM poZrhNrH/KJhaRRsXWV88= Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) (TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPS; Wed, 08 Jul 2020 16:46:18 +0300 id 00000000005A014E.000000005F05CE2A.00002DD1 Date: Wed, 8 Jul 2020 16:46:18 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi To: Thomas Zimmermann Subject: Re: drm/ast something ate high-res modes (5.3->5.6 regression) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-11752-1594215978-0001-2" Content-ID: X-Mailman-Approved-At: Thu, 09 Jul 2020 07:05:03 +0000 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: dri-devel@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-11752-1594215978-0001-2 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-ID: On Wed, 8 Jul 2020, Thomas Zimmermann wrote: > Hi >=20 > Am 08.07.20 um 12:05 schrieb Ilpo J=E4rvinen: > > Hi, > >=20 > > After upgrading kernel from 5.3 series to 5.6.16 something seems to=20 > > prevent me from achieving high resolutions with the ast driver. >=20 > Thanks for reporting. It's not a bug, but a side effect of atomic > modesetting. >=20 > During pageflips, the old code used to kick out the currently displayed > framebuffer and then load in the new one. If that failed, the display > went garbage. >=20 > In v5.6-rc1, we merged atomic modesetting for ast. This means that > screen updates are more reliable, but we have to over-commit resources. > Specifically, we have to reserve space for two buffers in video memory > while a pageflip happens. 1920x1200@32 are ~9MiB of framebuffer memory. > If your device has 16 MiB of VRAM, there's no space left for the second > framebuffer. Hence, the resolution is no longer supported. >=20 > On the positive side, you can now use Wayland compositors with ast. > Atomic modesetting adds the necessary interfaces. Ok, thanks for the info although it's quite disappointing (not the first=20 time to lose features with kms, migrating to it made me to lose dpms) ;-)= . As it's quite annoying to lose a high resolution mode (or be stuck in=20 some old kernel), would it be technically feasible to make the framebuffe= r=20 allocation asymmetrical? That is, the switch to high-res mode would get rejected when it would be into the smaller of the two buffers but not whe= n=20 the arrangement is the other way around? --=20 i. --=_script-11752-1594215978-0001-2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel --=_script-11752-1594215978-0001-2--