From: Arnd Bergmann <arnd@xxxxxxxx> Sent: Wednesday, March 18, 2020 2:27 AM > > On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <mikelley@xxxxxxxxxxxxx> wrote: > > From: Arnd Bergmann <arnd@xxxxxxxx> > > > On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <mikelley@xxxxxxxxxxxxx> wrote: > > > > > > > > The Hyper-V frame buffer driver may be built as a module, and > > > > it needs access to screen_info. So export screen_info. > > > > > > > > Signed-off-by: Michael Kelley <mikelley@xxxxxxxxxxxxx> > > > > > > Is there any chance of using a more modern KMS based driver for the screen > > > than the old fbdev subsystem? I had hoped to one day completely remove > > > support for the old CONFIG_VIDEO_FBDEV and screen_info from modern > > > architectures. > > > > > > > The current hyperv_fb.c driver is all we have today for the synthetic Hyper-V > > frame buffer device. That driver builds and runs on both ARM64 and x86. > > > > I'm not knowledgeable about video/graphics drivers, but when you > > say "a more modern KMS based driver", are you meaning one based on > > DRM & KMS? Does DRM make sense for a "dumb" frame buffer device? > > Are there any drivers that would be a good pattern to look at? > > It used to be a lot harder to write a DRM driver compared to an fbdev > driver, but this has changed to the opposite over the years. > > A fairly minimal example would be drivers/gpu/drm/pl111/pl111_drv.c > or anything in drivers/gpu/drm/tiny/, but you may want to look at the > other hypervisor platforms first, i.e drivers/gpu/drm/virtio/virtgpu_drv.c, > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c, drivers/gpu/drm/xen/xen_drm_front.c, > drivers/gpu/drm/qxl/qxl_drv.c, and drivers/gpu/drm/bochs/bochs_drv.c. > Thanks for the pointers, especially for the other hypervisors. Michael
