Re: DRM/KMS: report

[tlaronde%kergis.com@localhost]

On Sun, Oct 15, 2023 at 10:13:18AM +0000, Taylor R Campbell wrote:
> 
> > 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.

Then this is a difference with the first version, according to drm(4)
that is referring exclusively to DRM (first version) and is partial
(not mentionning DRM2 / DRMKMS) or obsolete.

For the record, I started first by trying to review _all_ the commits
starting from 2007-03-20 (the first import of the first---for NetBSD---
version)... But I realised, after some time and considering how fast I
was going through, it was hopeless... So I have a view, but far from
complete or even accurate.

> 
> > 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.

I will put all the documentation bits together some place for reference.

Thanks for the clarifications!

> 
> > 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.
> 

If the drivers were matching a rule, I have already implemented in
sys/kern/subr_userconf.c (on my git fork on
https://github.com/tlaronde/src) the use of "patterns" to change,
disable, enable, find and list matching driver names.

I could add specifiers to the "patterns" to match parent device or child
device.

I could extend too cfdata in order to allow to take into account a
devclass and to match against it.

Modules are setting a class and it would be the simpler to be able to
use such a tag in userconf to disable the devices without having to
resort to ad hoc lists---and even worse, to expand a magic name in MD
bootinfo stuff, with the obligation to update lists and the risk to
have to augment the size of bootinfo data.

I wanted and still want to implement something general and not ad hoc
for drm in userconf.

If somebody knows already enough about autoconf and userconf to point me
to the more elegant and consistent way, I will gladly take advices!

> > 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.

When saying "independantly", I'm not referring to the X11 code that is a
sine qua non for the stuff.

> 
> 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.

Yes, I've seen this.

For now, I will work in order to find a way to allow to disable simply
drmkms from userconf, with one rule---when I tried to install NetBSD on
a bare metal dedicated remote server, NetBSD "didn't work", while
Linuces distributions did; but their only "magic" was that they disallow
all the drm stuff from Grub: even them didn't attempt to use it.

If NetBSD is working without it, user can then attempt to enable it to
see how it works. It's rather frustrating to have the kernel crashing on
first attempt. And it's a real problem when you are installing from
remote, without anyway of seeing the booting process.

And after that, I will tackle all the "terminal" (console, ws, fb) i.e.
the representation/interaction from the NetBSD kernel side (what I have
already started, from the simplest: the end, the monitors) so
that is is orthogonal to whatever external.
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C