On Fri, Apr 27, 2018 at 10:22:42PM +0200, Mark Kettenis wrote:
> > Date: Fri, 27 Apr 2018 09:33:31 -0500
> > From: joshua stein <[email protected]>
> >
> > On Tue, 17 Apr 2018 at 07:52:28 +0200, Mark Kettenis wrote:
> > > > Date: Mon, 16 Apr 2018 10:45:52 -0500
> > > > From: joshua stein <[email protected]>
> > >
> > > Does this do the right thing for early consoles? The initial
> > > efifb_bs[] doesn't have space for the scrollback. At the point where
> > > the scrollback code gets code, we've replaced that with a malloc'ed
> > > buffer?
> >
> > Here is a new version that puts the scrollback count into each
> > rasops_screen in case it changes later, which allows it to cope with
> > the count being 0 if no scrollback has been allocated.
> >
> > Though the scrollback callback won't be called until wsdisplay
> > formally attaches later after each rasops_screen is allocated
> > anyway.
>
> Two small nits below. Otherwise this looks fine, so ok kettenis@ if
> you fix those.
I haven't tried this on intel yet but on radeon I often see a thin red
vertical line on the right side of the display with the first screen of
the buffer when scrolling back on rv635.
Index: radeon_kms.c
===================================================================
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_kms.c,v
retrieving revision 1.55
diff -u -p -r1.55 radeon_kms.c
--- radeon_kms.c 25 Apr 2018 01:27:46 -0000 1.55
+++ radeon_kms.c 28 Apr 2018 01:39:19 -0000
@@ -202,6 +202,7 @@ struct wsdisplay_accessops radeondrm_acc
.getchar = rasops_getchar,
.load_font = rasops_load_font,
.list_font = rasops_list_font,
+ .scrollback = rasops_scrollback,
.burn_screen = radeondrm_burner
};
