On Mon, May 25, 2020 at 09:13:43PM +1000, Jonathan Gray wrote: > On Sun, May 24, 2020 at 05:01:16PM -0700, jo...@armadilloaerospace.com 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.
I tried out the patch twice, once with John's value for EFIFB_HEIGHT of 50 and once with the original original value of 160. The behavior of the bug report I submitted doesn't reappear so it looks everything is working as intended. This is with the same monitor as in the bug report > > ---------------------------- > 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. >
