From: Daniel Vetter <firstname.lastname@example.org> To: Martin Hostettler <email@example.com> Cc: syzbot <firstname.lastname@example.org>, email@example.com, George Kennedy <firstname.lastname@example.org>, email@example.com, Tetsuo Handa <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Linus Torvalds <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Peilin Ye <email@example.com> Subject: Re: [PATCH] vt_ioctl: make VT_RESIZEX behave like VT_RESIZE Date: Tue, 29 Sep 2020 16:56:57 +0000 [thread overview] Message-ID: <20200929165657.GS438822@phenom.ffwll.local> (raw) In-Reply-To: <20200929105203.GG24673@neutronstar.dyndns.org> On Tue, Sep 29, 2020 at 12:52:03PM +0200, Martin Hostettler wrote: > 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... Imo userspace modesetting should be burned down anywhere we can. We've gotten away with this in drivers/gpu by just seamlessly transitioning to kernel drivers. Since th only userspace we've found seems to be able to cope if this ioctl doesn't do anything, my vote goes towards ripping it out completely and doing nothing in there. Only question is whether we should error or fail with a silent success: Former is safer, latter can avoid a few regression reports since the userspace tools keep "working", and usually people don't notice for stuff this old. It worked in drivers/gpu :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
next prev parent reply other threads:[~2020-09-29 16:56 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-23 17:30 KASAN: use-after-free Read in bit_putcs syzbot 2020-09-26 2:03 ` syzbot 2020-09-26 16:25 ` Tetsuo Handa 2020-09-26 19:39 ` Peilin Ye 2020-09-27 0:25 ` Tetsuo Handa 2020-09-27 8:28 ` Tetsuo Handa 2020-09-27 9:27 ` Peilin Ye 2020-09-27 11:46 ` [PATCH] vt_ioctl: make VT_RESIZEX behave like VT_RESIZE Tetsuo Handa 2020-09-27 12:06 ` Greg KH 2020-09-28 17:59 ` Martin Hostettler 2020-09-29 1:12 ` Tetsuo Handa 2020-09-29 10:52 ` Martin Hostettler 2020-09-29 16:56 ` Daniel Vetter [this message] 2020-09-29 17:10 ` Greg KH 2021-04-11 21:43 ` Maciej W. Rozycki 2021-04-11 22:15 ` Linus Torvalds 2021-04-12 7:01 ` Daniel Vetter 2021-04-12 13:30 ` Maciej W. Rozycki
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200929165657.GS438822@phenom.ffwll.local \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] vt_ioctl: make VT_RESIZEX behave like VT_RESIZE' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).