On Tue, Sep 29, 2020 at 06:56:57PM +0200, Daniel Vetter wrote: > 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 :-) This patch just ignores the ioctl and keeps on going, so userspace "shouldn't" notice it :) And it's in linux-next now, so all should be good. thanks, greg k-h _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
