Re: DRM/KMS

[David Brownlee <abs%netbsd.org@localhost>]

On Fri, 7 Jul 2023 at 12:02, <tlaronde%polynum.com@localhost> wrote:
>
> Le Thu, Jul 06, 2023 at 03:31:13PM -0400, Mouse a écrit :
> > > 4. And of course, GPU is hard.  [...]
> >
> > This is true.
> >
> > I know someone who works on GPU support _with_ the benefit of NDAed
> > documentation.  He says typical GPUs have documentation errata lists
> > substantially longer than the documentation itself (as in 400 pages of
> > doc, 900 pages of errata).
> >
> > That said, if tlaronde@ is willing to try, I say go for it.  In case of
> > failure, NetBSD is no worse off; in case of success, substantially
> > better.  And there's enough track record there that I don't consider it
> > nearly as unlikely to succeed as I would for most people (myself
> > included).
>
> OK, so I take up the challenge.
>
> What I need from core (someone who has access to the CVS server), is a
> copy of the CVS tree. I have only GSM access to Internet, with varying
> speed and paying by the byte, so "downloading", supposing it was
> available, is not an option.
>
> So to whoever from core:
>
> 1) Make the estimate of costs in USB keys needed, time needed for the
> operator and shipping costs to France and add a margin/profit for the
> foundation;

I'm in the UK and could easily post you a USB key. I assume a copy of
the anoncvs repo should be easy enough (would also suggest a copy of
the autogenerated git and or hg mirrors as they tend to be easier to
manipulate - just let me know. (I'm just a generic NetBSD dev, not in
core@)

> 2) Send me the estimate. I will then make a donation of that amount
> (margin included) to the NetBSD foundation;

If I'm sending a USB key to someone willing to spend significant time
to dig into DRM for NetBSD, the code of a USB key and postage is not a
factor :)

> 3) Once I have received the USB key(s), the countdown for a delay of 3
> months will start for the achievement of the first step: put DRM/KMS
> clearly aside so that the remaining of the kernel will be orthogonal to
> its present design and that there will be a framebuffer working,
> independant from any code coming from DRM/KMS (or X11, BTW...), DRM/KMS
> being only an optional addition.
>
> After three months, I will report success or failure (or enough success
> to extend once the period for 3 months to achieve the work).
>
> Whether core is OK or not, please let me know.

NetBSD uses wsdisplay to manage console and display devices. wsdisplay
can run with or without DRM/KMS. Many ports can easily present a dumb
framebuffer genfb(4) to wsdisplay, which can then manage it as a
console with configurable font (anti-aliasing etc), and simple X
server wsfb(4). In some cases both the console and X drivers can use
some form of acceleration on top (See sparc sx, cgfourteen etc)

For x86 (read "arbitrary display cards") presenting a dumb framebuffer
is more complex - EFI booting x86 can usually present something on
which genfb can be run, and older machines used to be able to present
vesafb.

For an EFI booting machine you can usually drop to the boot prompt,
use "gop" to select a resolution (cannot be later changed), then "boot
-c" and "disable i915drmkms" (or similar) and it should boot up with
something like:
  genfb0: framebuffer at 0xc0000000, size 1920x1080, depth 32, stride 7680
  wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation),
using wskbd0

drm/kms definitely is hugely complicated, overly Linux focussed, and
difficult to maintain and update. A lot of effort has been put into
getting it to run on NetBSD (and updating from previous versions), but
it's currently the only viable game in town.

What might be interesting would be a way to boot with a non DRM
console (either vga style text only or genfb), and then a way to
activate DRM later on (I think that would be potentially inherent in
what you are suggesting). That should allow just about any system to
safely boot into console mode, and then "risk" DRM as & when.

The stretch goal on top of that would be the ability to switch a
display back and forth between a "dumb" FB and DRM code, allowing the
shutdown and release of resources from one to the other. I suspect
that would be... more involved :-p

David