Re: DRM/KMS: report

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Sat, 14 Oct 2023 19:57:59 +0200
> From: tlaronde%kergis.com@localhost
> 
> [I'm sending this to the tech-kern since the previous message on
> tech-userlevel is only: the list seems dead?]

Not dead, just quiet so far this month.

> DRM or now DRM2 (aka DRM/KMS) are inherently and heavily linked to
> X11 and to Linux.  Due to the size of the thing, NetBSD is deriving
> a version from the one FreeBSD tries to derive.

Not sure what you mean about FreeBSD, but our drm2 code base was
developed largely independent of whatever is in FreeBSD, and as far as
I know was started well before FreeBSD adopted the same approach of
writing Linux API shims.

> To make things even worse, the abuse of acronyms is blurring things that
> didn't need to be made even less clear. Not to mention the fact that DRM
> is also used for Digital Rights Management---that has strictly nothing
> to do with the thing---, DRI (a part of the X11 stuff) is also used
> instead of DRM for the X11 part, and DRM2 is also referred too as 
> DRM/KMS.

sys/external/bsd/drm is the previous generation of the drm code base,
from before it did any kernel mode-setting (KMS).  Display
configuration was done by peeking and poking device registers from
userland through /dev/mem and /dev/pci -- the legacy user mode-setting
approach (UMS).  The /dev/dri/ nodes were used by userland only to map
some registers and manage graphics buffers bound into the GPU address
space.

sys/external/bsd/drm2 is the current generation of the drm code base,
including both UMS and KMS.  With KMS, display configuration is done
by a set of structured ioctls on /dev/dri/ nodes, with all device
register access done by the kernel.  (The /dev/dri/ nodes are also
used to manage graphics buffers.)

When I more or less started over from scratch, I called it drm2 just
so it would have a distinct place in the source tree while people
still relied on the previous generation of the code.

By now I think we should just delete sys/external/bsd/drm; it has been
unmaintained for so long it is unlikely to work.  If there's interest
in the legacy UMS drivers, they should all still be in the drm2 tree
and can be adapted like I did with viadrmums.  But I have no hardware
for most of them.

> The drivers using the new API have sometimes "kms" in the name (for
> i915, I guess to make a difference with the previous "legacy"
> i915drm), but generally not, or if this is the case, this is not the
> device attaching early:
> 
> # DRMKMS drivers 
> i915drmkms*     at pci? dev ? function ?
> intelfb*        at intelfbbus?

`i915drmkms' happened because `i915' is not allowed (ends with a
digit) and `i915drm' was already taken.

> To illustrate the namespace problem, take "radeon":
> 
> radeondrm* is the legacy DRM driver and:
> 
> radeon* is the DRM2 and this is its child, the fb, that has the "kms"
> substring:
> 
> radeondrmkmsfb* at radeonfbbus?

`radeondrmkms' happened because `radeonfb' was already taken.

I'm not attached to these names, but they've been around for long
enough they are probably named in existing boot.cfg files, so changing
them might is likely to break people's bootloaders.

Not hard to imagine creating a new way to tag drivers that can be
referenced by userconf so that renaming isn't necessary.

> For the ARM part, the API is implemented but, from what I gather,
> totally independantly from the external sources in order to use the
> framebuffer.

I don't know how you conclude this, but access to the display
configuration is exposed to userland through the drm ioctls on
/dev/dri/ nodes.

The external sources implement all those ioctls and the
device-independent logic to process display configuration options and
apply them to the hardware with the device-dependent callbacks in,
e.g., sunxi_drm.c, sunxi_lcdc.c, &c.

We don't have anything remotely resembling the display configuration
API of DRM KMS.  You could redo that API from scratch, but it's the
easiest part of the upstream drm code base to maintain, so you'd end
up with a huge amount of wasted effort and none of the really
important drivers (intel, radeon, amdgpu, nouveau).

> There are no syscalls added related to the DRM.

syscalls, no.  Ioctls, yes.