Hi Am 15.01.21 um 09:06 schrieb Geert Uytterhoeven: > Hi Daniel, > > On Thu, Jan 14, 2021 at 5:11 PM Daniel Vetter wrote: >> On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven wrote: >>> On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter wrote: >>>> On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds >>>> wrote: >>>>> On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi wrote: >>>>>>> Could we pause this madness? Scrollback is still useful. I needed it >>>>>>> today... it was too small, so command results I was looking for >>>>>>> already scrolled away, but... life will be really painful with 0 >>>>>>> scrollback. >>>>>> >>>>>>> You'll need it, too... as soon as you get oops and will want to see >>>>>>> errors just prior to that oops. >>>>>> >>>>>>> If it means I get to maintain it... I'm not happy about it but that's >>>>>>> better than no scrollback. >>>>>> >>>>>> Amen! What self respecting admin installs a gui on servers? What do we >>>>>> have to do to get this back in? What was so buggy with this code that >>>>>> it needed to be removed? Why was it such a burden to just leave it be? >>>>> >>>>> It really was buggy, with security implications. And we have no maintainers. >>>>> >>>>> So the scroll-back code can't come back until we have a maintainer and >>>>> a cleaner and simpler implementation. >>>>> >>>>> And no, maintaining it really doesn't mean "just get it back to the >>>>> old broken state". >>>>> >>>>> So far I haven't actually seen any patches, which means that it's not >>>>> coming back. >>>>> >>>>> The good news? If you have an actual text VGA console, that should >>>>> still work just fine. >>> >>> IIRC, all of this was written for systems lacking VGA text consoles >>> in the first place... >>> >>>> Also on anything that is remotely modern (i.e. runs a drm kernel >>>> modesetting driver undearneath the fbdev/fbcon stack) there's a pile >>>> more issues on top of just the scrollback/fbcon code being a mess. >>> >>> Would it help to remove DRM_FBDEV_EMULATION (instead)? Of the fbdev code, DRM's fbdev emulation is the cleanest. We now even have test cases for the userspace I/O. >> >> It's a problem with the hardware. "Write some registers and done" >> isn't how display blocks work nowadays. So your proposal amounts to >> "no fbdev/fbcon for anything modern-ish". > > With "modern-ish" actually meaning: "desktop/gaming/mobile-style > 3D-accelerated wide-color display hardware". There's plenty of display > hardware that doesn't fall into that class, and is served by fbdev (also > out-of-tree due to the moratorium) because of that. Userspace has been moving away from fbdev. Writing an fbdev driver locks you into a legacy userspace. I also found that DRM drivers are smaller, because of all the DRM helper libraries. Using DRM + fbdev emulation is a win in almost any case. We did have some complaints about performance of the emulation. So that might be worth looking into. Best regards Thomas > >> Also I said "a pile more", most of the issues in fbcon/fbdev code >> apply for all drivers. >> >>>> Specifically the locking is somewhere between yolo and outright >>>> deadlocks. This holds even more so if the use case here is "I want >>>> scrollback for an oops". There's rough sketches for how it could be >>>> solved, but it's all very tricky work. >>> >>> When an oops happens, all bets are off. At that point, all information >>> you can extract from the system is valuable, and additional locking >>> issues are moot. >> >> Except the first oops then scrolls aways because it's getting buried >> under further fail. Your locking needs to be minimally good enough to >> not make the situation worse. > > When an oops happens, all bets are off... > > Gr{oetje,eeting}s, > > Geert > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer