[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MW2PR2101MB1052E413218D295EF24E5E05D7F40@MW2PR2101MB1052.namprd21.prod.outlook.com>
Date: Thu, 19 Mar 2020 21:46:30 +0000
From: Michael Kelley <mikelley@...rosoft.com>
To: Arnd Bergmann <arnd@...db.de>
CC: Will Deacon <will@...nel.org>, Ard Biesheuvel <ardb@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Mark Rutland <mark.rutland@....com>,
Marc Zyngier <maz@...nel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
gregkh <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
linux-efi <linux-efi@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
"olaf@...fle.de" <olaf@...fle.de>,
Andy Whitcroft <apw@...onical.com>,
vkuznets <vkuznets@...hat.com>, Jason Wang <jasowang@...hat.com>,
"marcelo.cerri@...onical.com" <marcelo.cerri@...onical.com>,
KY Srinivasan <kys@...rosoft.com>,
Sunil Muthuswamy <sunilmut@...rosoft.com>,
Boqun Feng <boqun.feng@...il.com>
Subject: RE: [PATCH v6 09/10] arm64: efi: Export screen_info
From: Arnd Bergmann <arnd@...db.de> Sent: Wednesday, March 18, 2020 2:27 AM
>
> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <mikelley@...rosoft.com> wrote:
> > From: Arnd Bergmann <arnd@...db.de>
> > > On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <mikelley@...rosoft.com> 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@...rosoft.com>
> > >
> > > 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
Powered by blists - more mailing lists