On Fri, 7 Jul 2023 at 12:02, <tlaro...@polynum.com> 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
