Re: CVS commit: src

[Andrius V <vezhlys%gmail.com@localhost>]

I would agree with Taylor, it is not tested well enough to be enabled
by default and mainly unmaintained by now. I guess the better solution
would be to attempt to integrate openchrome-drm instead at some point
in the future. I think making viadrmums as kernel module is quite a
good trade off right now for those who need/want to use it and it
saves from kernel compilation. Will do pull-up to netbsd-10 soon for
this change.

I may try to do some additional testing to verify how much it is
utilized right now and were performance makes a difference (and likely
would need to investigate what is wrong with VX900). I believe 3D
acceleration is unsupported.


On Sun, Aug 13, 2023 at 8:05 PM Taylor R Campbell
<campbell+netbsd-source-changes-d%mumble.net@localhost> wrote:
>
> > Date: Thu, 10 Aug 2023 07:42:53 +1000
> > from: matthew green <mrg%eterna.com.au@localhost>
> >
> > > Log Message:
> > > viadrmums(4): build legacy VIA DRM UMS driver module for amd64.
> > >
> > > This driver is not built-in by default, thus loadable module can help (un)lucky
> >
> > if it works, why isn't it in GENERIC as well as a module?
>
> Couple reasons:
>
> 1. I never adequately tested it.  I started X a few years ago (and a
>    couple drm updates ago) but that's it.  (Also only on 32-bit VIA.)
>    Maybe andvar can test it more extensively now, though -- glxgears,
>    x11perf, firefox, &c.
>
>    Even better if we can get a sampling of code coverage, e.g. maybe
>    with dtrace to count function calls at least, to confirm it's
>    actually getting exercised.
>
> 2. It's a legacy UMS driver, which is inherently sketchy (display
>    configuration requires granting userland direct access to pci and
>    device registers) and increasingly unmaintained even upstream.
>
>    So I put in some infrastructure to allow UMS drivers to be loaded
>    dynamically, so it wouldn't be necessary to have sketchy business
>    like that in the kernel by default.
>
>    I kind of intended to give the same treatment to the other legacy
>    UMS drivers like mga (matrox), r128, sis, tdfx, &c., but it's been
>    a very low priority so I haven't gotten a round tuit (and I only
>    have hardware for mga and that's in a build server I don't like to
>    mess with).