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.1 required=3.0 tests=BAYES_00,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 B2F66C4346E for ; Tue, 29 Sep 2020 10:52:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 66309208FE for ; Tue, 29 Sep 2020 10:52:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=uchuujin.de header.i=@uchuujin.de header.b="kQ5SCbFz" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728275AbgI2KwG (ORCPT ); Tue, 29 Sep 2020 06:52:06 -0400 Received: from static.85-10-192-230.clients.your-server.de ([85.10.192.230]:49477 "EHLO mxout.uchuujin.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727403AbgI2KwF (ORCPT ); Tue, 29 Sep 2020 06:52:05 -0400 Received: by neutronstar.dyndns.org (Postfix, from userid 1000) id 95E361430A410; Tue, 29 Sep 2020 12:52:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uchuujin.de; s=h; t=1601376723; bh=S4qRhmQnANACcgAsVG/DL9GYSVFl4YpEydWlE5Zr2Ds=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kQ5SCbFzDRm4dN6U+6m/9xGYPd9nKBC0cDUYWnO70jRjSK1W6dsLgFyeYAHhRRkK4 hGvGy2CfTg+VS/p2BwjSZvM7VU/0YSpcRkDH2kyYOHmIr6gi1q3vz/cWxZiySJHhsj /QdFJQt/aJOQqzNYzWtK5xjTmBCa2JSOFUnjnlpVbzDVH/WYHFlIbUpSPfJJVi/Ofv bPPRXvGYyq2xbfho+O+8CxyeN5ryfqTSejVkrZBp4whlcwSwAsqReID7WjQNgUbk8p lCTmS673EGxk/BpX9j7jzcaISeLJq44r+QtnpNnjeZP/RSw3x9GbctyGQawjVtn5F8 vvfWOcjWk3/Hw== Date: Tue, 29 Sep 2020 12:52:03 +0200 From: Martin Hostettler To: Tetsuo Handa Cc: Martin Hostettler , gregkh@linuxfoundation.org, jirislaby@kernel.org, Peilin Ye , syzbot , b.zolnierkie@samsung.com, daniel.vetter@ffwll.ch, deller@gmx.de, syzkaller-bugs@googlegroups.com, Linus Torvalds , dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, George Kennedy Subject: Re: [PATCH] vt_ioctl: make VT_RESIZEX behave like VT_RESIZE Message-ID: <20200929105203.GG24673@neutronstar.dyndns.org> References: <000000000000226d3f05b02dd607@google.com> <47907f77-b14b-b433-45c6-a315193f0c1a@i-love.sakura.ne.jp> <494395bc-a7dd-fdb1-8196-a236a266ef54@i-love.sakura.ne.jp> <20200927092701.GA1037755@PWN> <4933b81b-9b1a-355b-df0e-9b31e8280ab9@i-love.sakura.ne.jp> <20200928175956.GF24673@neutronstar.dyndns.org> <100dfd3f-3415-80ae-a6cf-30d15f7ca49f@i-love.sakura.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <100dfd3f-3415-80ae-a6cf-30d15f7ca49f@i-love.sakura.ne.jp> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 29, 2020 at 10:12:46AM +0900, Tetsuo Handa wrote: > On 2020/09/29 2:59, Martin Hostettler wrote: > > On Sun, Sep 27, 2020 at 08:46:30PM +0900, Tetsuo Handa wrote: > >> VT_RESIZEX was introduced in Linux 1.3.3, but it is unclear that what > >> comes to the "+ more" part, and I couldn't find a user of VT_RESIZEX. > >> > > > > It seems this is/was used by "svgatextmode" which seems to be at > > http://www.ibiblio.org/pub/Linux/utils/console/ > > > > Not sure if that kind of software still has a chance to work nowadays. > > > > Thanks for the information. > > It seems that v.v_vlin = curr_textmode->VDisplay / (MOFLG_ISSET(curr_textmode, ATTR_DOUBLESCAN) ? 2 : 1) > and v.v_clin = curr_textmode->FontHeight . Thus, v.v_clin is font's height and seems to be non-zero. > But according to https://bugs.gentoo.org/19485 , people are using kernel framebuffer instead. > Yes, this seems to be from pre framebuffer times. Back in the days "svga" was the wording you got for "pokes svga card hardware registers from userspace drivers". And textmode means font rendering is done via (fixed function in those times) hardware scanout engine. Of course having only to update 2 bytes per character was a huge saving early on. Likely this is also before vesa VBE was reliable. So i guess the point where this all starts going wrong allowing the X parts of the api to be combined with FB based rendering at all? Sounds the only user didn't use that combination and so it was never tested? Then again, this all relates to hardware from 20 years ago... - Martin Hostettler