On Sun, May 24, 2020 at 05:01:16PM -0700, [email protected] wrote: > The efifb driver behaves almost identically to the inteldrm driver > for wscons, but did not implement the getchar() accessops, so > wsmoused would fail at startup.
This seems reasonable, though your mail client has line wrapped the patch so it won't apply. In this case it is simple enough to apply by hand. > Separately, I increased the maximum screen dimensions to 160x50 to > allow the 12x24 font to be used on an 1920 monitor, which looks great! Something similiar was done and reverted as it somehow broke inteldrm taking the fb over from efifb on a 4k display. Perhaps someone with a 4k display can confirm if this is still a problem. https://marc.info/?l=openbsd-bugs&m=155337866226121&w=2 That was back before we deferred most of inteldrm to when the root fs is mounted and interrupts are available. And just before the last big drm update by the look of it. ---------------------------- revision 1.22 date: 2019/03/25 14:17:58; author: fcambus; state: Exp; lines: +3 -3; commitid: hL9P1vyWGBp5FHhE; Revert back to using previous values for EFIFB_WIDTH and EFIFB_HEIGHT, as raising them expose an issue which breaks inteldrm on large screen resolutions. Reported by chris@, and by Lucas Raab on bugs@. Thanks! ---------------------------- revision 1.21 date: 2019/03/16 13:16:49; author: fcambus; state: Exp; lines: +3 -3; commitid: wsqjyS7rXDKbqGS3; Now that efifb(4) supports remapping the framebuffer in write combining mode, it's fast enough to raise the maximum size of the EFI framebuffer console. Set it to 160 columns and 160 rows, to match inteldrm and radeondrm. OK jcs@, kettenis@ ---------------------------- > > Unlike the intel driver, efifb has a static buffer of that size, > which is a non-trivial amount of memory. Not setting the backing > store to save the memory results in an ultra-slow console until the > driver gets fully initialized, because it is doing scrolls by reading > from write combined memory instead of the redrawing all the > characters. > > I plan on changing that to a dynamic allocation once I am more > comfortable with the reinitialization that goes on when autoconf > gets around to the console display device, so feel free to punt on > that if you want to wait. Drivers which can act as a console have a cnattach function for very early init and then later probe again and run attach. In the case of efifb there is also efifb_cnremap() which is called when mainbus attaches. The drm drivers call efifb_detach() to stop autoconf from doing the normal probe/attach when taking over the console.
