[CAVEATS: Please remember that I'm not an english native speaker, and
that what follows is not a "lecture" or a judgement about what is done,
but a home made translation in some english of some of the notes---there
is more documentation to come later.
if I wanted to look at the DR
newly created branch, to still
> > optionally use the current implementation of DRM/KMS is an open
> > question, and this goal is beyond the objectives of the first stage.
>
> You know you can just omit the drm drivers from the kernel, right?
> For example, on amd64:
>
> no i915
> Date: Thu, 13 Jul 2023 11:35:50 +0200
> From: tlaro...@polynum.com
>
> Severing will be the first thing done. Whether I will be able, in this
> first stage, to allow, from this newly created branch, to still
> optionally use the current implementation of DRM/KMS is an open
&g
I have received today, sent by Martin Husemann (thanks!), a copy of the
trees: cvs, git and hg.
So the countdown is started. I give me at most 3 months to disentangle
the tree in order for the present Linux originated DRM/KMS
implementation to be clearly severed so that alien and awkward
t; > On Fri, Jul 07, 2023 at 02:30:14PM +0100, David Brownlee wrote:
> > > > > 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 Fri, 7 Jul 2023 at 18:19, wrote:
>
> Le Fri, Jul 07, 2023 at 03:08:25PM +0100, David Brownlee a écrit :
> > On Fri, 7 Jul 2023 at 15:03, Martin Husemann wrote:
> > >
> > > On Fri, Jul 07, 2023 at 02:30:14PM +0100, David Brownlee wrote:
> > > > drm/km
Le Fri, Jul 07, 2023 at 03:08:25PM +0100, David Brownlee a écrit :
> On Fri, 7 Jul 2023 at 15:03, Martin Husemann wrote:
> >
> > On Fri, Jul 07, 2023 at 02:30:14PM +0100, David Brownlee wrote:
> > > drm/kms definitely is hugely complicated, overly Linux focussed, and
>
On Fri, Jul 07, 2023 at 03:08:25PM +0100, David Brownlee wrote:
> So far some good changes (cribbing shamelessly from other suggestions) might
> be:
> - Implement "boot -D" (or similar) to boot with all DRM disabled, to
> make it easier for hardware with issues
That should be quite easy.
> - All
On Fri, 7 Jul 2023 at 15:03, Martin Husemann wrote:
>
> On Fri, Jul 07, 2023 at 02:30:14PM +0100, David Brownlee wrote:
> > drm/kms definitely is hugely complicated, overly Linux focussed, and
> > difficult to maintain and update. A lot of effort has been put into
> > get
On Fri, Jul 07, 2023 at 02:30:14PM +0100, David Brownlee wrote:
> 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
SB 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 asid
Le Thu, Jul 06, 2023 at 05:57:01PM +, Bruno Melo a écrit :
> > What is frightening me now, is that the impressive amount of work needed
> > to make the thing "work", and only temporarily, is a work that will
> > be lost because the code base will continue to evolve (not to say:
> > dissolve...)
the estimate. I will then make a donation of that amount
(margin included) to the NetBSD foundation;
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 orth
> 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 sa
> What is frightening me now, is that the impressive amount of work needed
> to make the thing "work", and only temporarily, is a work that will
> be lost because the code base will continue to evolve (not to say:
> dissolve...).
I think here is real problem. For these you need a team, not any tea
Le Fri, Jul 07, 2023 at 01:05:03AM +0900, PHO a écrit :
> On 7/6/23 20:32, tlaro...@polynum.com wrote:
> > So I'm proposing to go back to the fork (for this part starting by
> > identifying what is immune, orthogonal to the thing) when the Linux
> > DRM way was taken and
On 7/6/23 20:32, tlaro...@polynum.com wrote:
> So I'm proposing to go back to the fork (for this part starting by
> identifying what is immune, orthogonal to the thing) when the Linux
> DRM way was taken and to eject the Linux DRM/KMS.
>
> If DRM has to be addressed, it wil
17 matches
Mail list logo
