> Date: Thu, 26 Jul 2018 17:56:03 -0500
> From: joshua stein <[email protected]>
>
> On Thu, 26 Jul 2018 at 22:26:51 +0200, Mark Kettenis wrote:
> > I'm hesitant to change this code. How does Linux behave on tese
> > machines? Does it use the invisible part of the framebuffer? Or have
> > they done away with actually using the kernel framebuffer completely
> > like some developers threatened a couple of years ago...
>
> I booted a Linux USB drive and it just shows a purple/black screen
> for a few seconds while the kernel loads until some text flashes for
> half a second (systemd?) and then X loads. When I switch back to
> the console, it doesn't draw off the screen. I have no idea what
> it's doing under the hood to figure out the resolution for the
> console.
All the information about the size of the connected displays is there.
But it is unclear to me how that information is propagated to the
Linux kernel framebuffer code.
Anyway, here is an alternative diff. This keeps the BIOS framebuffer
but only uses the area that corresponds to the size we want. Keeping
the BIOS framebuffer has some benefits. On many systems that
framebuffer lives in "stolen" memory that we can't really use for any
other purpose because the BIOS owns it. Also keeping the BIOS
framebuffer would avoid a mode switch (at least in theory) and speed
up the boot processes.
Index: dev/pci/drm/i915/intel_fbdev.c
===================================================================
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_fbdev.c,v
retrieving revision 1.3
diff -u -p -r1.3 intel_fbdev.c
--- dev/pci/drm/i915/intel_fbdev.c 1 Jul 2017 16:14:10 -0000 1.3
+++ dev/pci/drm/i915/intel_fbdev.c 27 Jul 2018 17:26:33 -0000
@@ -220,8 +220,10 @@ static int intelfb_create(struct drm_fb_
} else {
DRM_DEBUG_KMS("re-using BIOS fb\n");
prealloc = true;
+#ifdef __linux__
sizes->fb_width = intel_fb->base.width;
sizes->fb_height = intel_fb->base.height;
+#endif
}
obj = intel_fb->obj;
