Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1183867pxb; Fri, 21 Jan 2022 11:42:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJwCZFuiciqFJCVMWdLJbRAMorAg/2xlSFR3fNC3mFCclSYjNu0oMT1Wo0AgqtZFUAZMT/CU X-Received: by 2002:a17:902:d4c3:b0:14a:3575:2843 with SMTP id o3-20020a170902d4c300b0014a35752843mr5261723plg.40.1642794143110; Fri, 21 Jan 2022 11:42:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642794143; cv=none; d=google.com; s=arc-20160816; b=IrI9SPFXcKzWA7DY4CHSvvR/oQm6ZHxe4UU78iAwIiiNjPLDpzAUz95yDLAx4iSlzJ sQZzfFPY4nv5fFD6g6DblNs4oIcq3eE2haC5utaYakBpV2o2LRJbb0LOTe8uxXua0WvJ fHD2rDkOPNPp8RVRbBzIZgq4BTP8iXQGWVlJASXw26Y5DKPtjCbechWJ4e9NJcz1/mU4 vRyKUmFBVITxcVyYW9/Sat/s7sM1U4qVXwGjuePj/B/MKO/aw64Ha6HNFlBWlsBKNZFk n/HOl8T7m6h+YkrEgTuPRof5THHRoMSONZEW91r9Ul26MpchDd7x7bt5e55tdg4w4Xuz Rb2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=YI7Q13xa1667GBXT2yWDs/SWe72Hu8X9+CPfpHuc99A=; b=tmVBnnZOYJSSMzOY5DHzVeydFB3KnsLYhcq1xbpUjnrue+s07OGc2Jg3URJiZ/1Ozl uHQqFmCj/ovsCbhcnp5KiLTeSJsSWcy7gtautokKa53FSVZVwuwDhULPOvL6OFtaEKOq IM1NNhj4mkt4s3M1HTDszssWg4smeNf/ih0+HYwH0lBvlLV2OREkuV9hTqBtAA1OOROW 9OvfBsfOWwrQ79aB84p218aw0GGepG4WZH9My1X8SKs9ieI815aaTIyTbjZf2C93QX+y MzvQAKmDA90e5NSGkJ/8JH1wQJOpl9MIEjDYMI+DkR7y47ZNIfMzIZA9h0ntUCC+YiGj tKkA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmx.net header.s=badeba3b8450 header.b=RC+x85sZ; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=gmx.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e3si7237154pls.57.2022.01.21.11.42.10; Fri, 21 Jan 2022 11:42:23 -0800 (PST) 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=@gmx.net header.s=badeba3b8450 header.b=RC+x85sZ; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=gmx.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355996AbiASP4G (ORCPT + 99 others); Wed, 19 Jan 2022 10:56:06 -0500 Received: from mout.gmx.net ([212.227.17.22]:53475 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355991AbiASP4E (ORCPT ); Wed, 19 Jan 2022 10:56:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1642607743; bh=YI7Q13xa1667GBXT2yWDs/SWe72Hu8X9+CPfpHuc99A=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=RC+x85sZczSRAQWVSK8ejYomi/BNayTf6lz+afsU5eO7YusQ2ncqCoHFNxMxUjvR0 vAmlv6UFbjP6YNbPtfZxEYMgcq8L5c4+XOMDfx318IGA5xu4rr1WyWIgNHoaWnrIV/ YOf1IiGj08Q29S2whMs79fIBCln49zZ4sBicRPO8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.20.60] ([92.116.183.52]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M72sJ-1nEKR61YVT-008d9h; Wed, 19 Jan 2022 16:55:43 +0100 Message-ID: <40d39363-bae8-93f2-71c6-7d5531f144bf@gmx.de> Date: Wed, 19 Jan 2022 16:54:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling" Content-Language: en-US To: Daniel Vetter , Sven Schnelle Cc: Linus Torvalds , Linux Fbdev development list , Pavel Machek , Sam Ravnborg , Greg Kroah-Hartman , Javier Martinez Canillas , DRI Development , Linux Kernel Mailing List , Claudio Suarez , Tomi Valkeinen , Geert Uytterhoeven , Thomas Zimmermann , Daniel Vetter , Gerd Hoffmann References: <20220119110839.33187-1-deller@gmx.de> <20220119110839.33187-3-deller@gmx.de> <4d8950c7-5f51-ca2b-4c93-741c7805a214@gmx.de> <8735ljkboo.fsf@x1.stackframe.org> From: Helge Deller In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:2z0TYX9D3a0a7Bay37UHJF18IENXDzXFGI/rMc7qUMCnERrLHXu 9R0jxsNowo9md+SFIj73tzJAjebZpZS64c7i7Q8tU1il0PCTOt2HV7jfJjJHUznf9pO6/ml OCm7TtXAy7Oa1Yh46JU4VVNQ8Z7Bj5i/59YTFRRyj8m7BLXQTb5su9A/fd+8bXSu66a0LGn ooDTr7eLMAua5vXEINtCA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:T6BME9pdjQI=:tOIf66w0c6tKIjq1IicbBO aPMVUZDDlBJrLWD8XkXldQuAUYwKDyOcKPYTqUoQHitI5+Sw0rkgOgjT3fvbNx1psgTqc3SQf 55fa841sVz9lVwIqAK5+lZrRMiMIvVM9bdrjvDypEquCQjtzVJyossFPsi2/TW4FULy7I0GQA pXMuGM0oNOkf4Dk5G8WKAvyUBt3/43puLz7rWkhjpzi2QbS15QTXG+3TF6UxO8IWrinDhimeb ZxTNTBHSRPCsoUoxm62mH9q0N+Re4c10RfaSWN+BC/BOxMv+fJlAu9jGhxTZIMAVB/C6Kr5Zj bClr46VFt0J9aqfNy788OWsiEkP8W1K4yZKZmCX77oDIsoTJk14EWX3s/zFtlyuUYaoFH3/Qx W4vJhQEprkk3nDuRclolD3Uxsd6drmXavOucrzoYBnQaktFP58dID0q9NjSUimcd44986mnAN GdByH7Oss5tSQwQDragzNc85Ym9/31yIqGihIoZFQqBIfhmKNJTI1T4B/Sz6UHtrliIttc2ad WRhwPELOu3ypJ4yHVYLXoTufdCbMFtkxRcDdiLLzBgkIlJOlQlfh3BeZHg1Xmf8eShSTTQ+mJ bIOEXS3CpAbwDo1/aWTqhJooWSnTnvWk61HF7EkoLJb7DTNfoMxKlaFPSgef67RMDxsN5hJ3q FFXpZ+UAw2fIKJLVU85EAMGw8wd9pxCcjJ/vYu3bqgMzfKRDHAXCXTjecGok/bz5APIFD9eBn T/13dg+ChWvz7S40E+XGeV/hqhKfJdnW1yGsmTcMhvB0wz8diP/BEw+uy/ZM8qp61sqz2cRZ6 XGxLwzKaz3ccLJNm6c3zZ6zFPqRcu1n1KpyNfeNmGeY47yB/7F0jbBq3CAuXTj5OqaEKEMku0 u+U1EVqV0K3zu2DYxTsliLSKw03amUPypqzNuFKcdFmc9O6QAcWED0B/1JYWqCuq2b71x1ixb y3AXZzA32WUisTTAiL14v5TdN01x3W4zShjuluzP8pz3mO2EvwWqMEzwpkrEDshgHovX+vpmh +kv7ZOT9IzR/GggInaXpodzeysbJAOpA1Pk/bM3hvf0ottZgUFOblptQqCH0CTkaJJN0BBE4y bACFjuhhFAciJE= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/19/22 16:42, Daniel Vetter wrote: > On Wed, Jan 19, 2022 at 4:06 PM Sven Schnelle wro= te: >> >> Daniel Vetter writes: >> >>> On Wed, Jan 19, 2022 at 3:01 PM Linus Torvalds >>> wrote: >>> Irrespective of this code being buggy or not buggy I think the bigger >>> pictures, and really the reason I want to see as much code ditched >>> from the fbdev/fbcon stack as we possible can, are very clear: >>> >>> - it's full of bugs >>> - there's no test coverage/CI to speak of >>> - it's very arcane code which is damn hard to understand and fix issue= s within >>> - the locking is busted (largely thanks to console_lock, and the >>> effort to make that reasonable from -rt folks has been slowly creeping >>> forward for years). >>> >>> Iow this subsystem is firmly stuck in the 90s, and I think it's best >>> to just leave it there. There's also not been anyone actually capable >>> and willing to put in the work to change this (pretty much all actual >>> changes/fixes have been done by drm folks anyway, like me having a >>> small pet project to make the fbdev vs fbcon locking slightly less >>> busted). >> >> Saying it's stuck in the 90ies, and actively trying to prevent >> Helge from taking over maintainership at the same time looks odd. >> I think Helge should at least get a chance to fix the issues. If the >> state is still the same in a year or so it should be discussed again. > > You don't need maintainership to fix issues. You need to submit patches. The very first email of this thread is my patch. And you just added your comments to this patch. > If otoh you get the maintainership first to be able to cram in reverts > without discussions, then it's very backwards. I'm working on the Linux kernel since at least 23 years and am a maintaine= r of parts of it. I know that and would never push something which is controversal without d= iscussions. >>> The other side is that being a maintainer is about collaboration, and >>> this entire fbdev maintainership takeover has been a demonstration of >>> anything but that. MAINTAINERS entry was a bit confusing since defacto >>> drm has been maintaining it for years. >> >> It was marked as 'Orphaned'. Anyone is free to send a Patch/PR to take >> over maintainership. If you have strong opinions about that code (And y= ou >> obviously have reading your mail, set it to 'maintained' and care about >> it. Everything else is just wrong in my opinion. > > I already added dri-devel so anything we drastically change can be > discussed first. If that's indeed not strong enough then yes I can > whack in full maintainer entry with a bugfix-only status. > > But really I try to not create facts with just editing MAINTAINERS > first and ask questions later, that's just not a great way to > collaborate. Helge