Le Thu, Jul 13, 2023 at 11:25:40AM +, Taylor R Campbell a écrit :
> > 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
> > opti
> 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
> question, and this g
Le Fri, Jul 07, 2023 at 08:02:22PM +0100, David Brownlee a écrit :
> 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, D
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/kms definitely is hugely complicated, overly L
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
> > > difficult to maintain an
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
> > getting it to run on NetBSD (
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's currently the
On Fri, 7 Jul 2023 at 12:02, 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 documentatio
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...)
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 docu
> 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 to eject the Linux DRM/KMS.
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 will be addressed after, bu
15 matches
Mail list logo
