[RFC] Deprecation and removal of the drm2 driver

classic Classic list List threaded Threaded
65 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[RFC] Deprecation and removal of the drm2 driver

Niclas Zeising-6
[ Cross posted to freebsd-current@ and freebsd-x11@.  Please respect
reply-to and send all replies to freebsd-x11@.  Thanks! ]


Hi!
I propose that we remove the old drm2 driver (sys/dev/drm2) from
FreeBSD.  I suggest the driver is marked as deprecated in 11.x and
removed from 12.0, as was done for other drivers recently.  Some
background and rationale:

The drm2 driver was the original port of a KMS driver to FreeBSD.  It
was done by Konstantin Belousov to support Intel graphics cards, and
later extended by Jean-Sébastien Pédron as well as Konstantin to match
what's in Linux 3.8.  This included unstable support from Haswell, but
nothing newer than that.

For quite some time now we have had the graphics/drm-stable-kmod and
graphics/drm-next-kmods which provides support for modern AMD and Intel
graphics cards.  These ports, together with the linuxkpi, or lkpi, has
made it significantly easier to port and update our graphics drivers.
Further, these new drivers cover the same drivers as the old drm2 driver.

What does the community think?  Is there anyone still using the drm2
driver on 12-CURRENT?  If so, what is preventing you from switching to
the port?

Thank you
Regards
--
Niclas Zeising
FreeBSD x11/graphics team
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: [RFC] Deprecation and removal of the drm2 driver

Cy Schubert-4
The port doesn't support i386.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<[hidden email]> or <[hidden email]>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Niclas Zeising
Sent: 18/05/2018 11:00
To: [hidden email]
Subject: [RFC] Deprecation and removal of the drm2 driver

[ Cross posted to freebsd-current@ and freebsd-x11@.  Please respect
reply-to and send all replies to freebsd-x11@.  Thanks! ]


Hi!
I propose that we remove the old drm2 driver (sys/dev/drm2) from
FreeBSD.  I suggest the driver is marked as deprecated in 11.x and
removed from 12.0, as was done for other drivers recently.  Some
background and rationale:

The drm2 driver was the original port of a KMS driver to FreeBSD.  It
was done by Konstantin Belousov to support Intel graphics cards, and
later extended by Jean-Sébastien Pédron as well as Konstantin to match
what's in Linux 3.8.  This included unstable support from Haswell, but
nothing newer than that.

For quite some time now we have had the graphics/drm-stable-kmod and
graphics/drm-next-kmods which provides support for modern AMD and Intel
graphics cards.  These ports, together with the linuxkpi, or lkpi, has
made it significantly easier to port and update our graphics drivers.
Further, these new drivers cover the same drivers as the old drm2 driver.

What does the community think?  Is there anyone still using the drm2
driver on 12-CURRENT?  If so, what is preventing you from switching to
the port?

Thank you
Regards
--
Niclas Zeising
FreeBSD x11/graphics team
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Warner Losh
In reply to this post by Niclas Zeising-6
On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
[hidden email]> wrote:

> On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote:
> > On Fri, May 18, 2018, 20:00 Niclas Zeising <[hidden email]> wrote:
> >
> > > I propose that we remove the old drm2 driver (sys/dev/drm2) from
> > > FreeBSD.  I suggest the driver is marked as deprecated in 11.x and
> > > removed from 12.0, as was done for other drivers recently.  Some
> > > background and rationale:
> > >
> > > The drm2 driver was the original port of a KMS driver to FreeBSD.  It
> > > was done by Konstantin Belousov to support Intel graphics cards, and
> > > later extended by Jean-Sébastien Pédron as well as Konstantin to match
> > > what's in Linux 3.8.  This included unstable support from Haswell, but
> > > nothing newer than that.
> > >
> > > For quite some time now we have had the graphics/drm-stable-kmod and
> > > graphics/drm-next-kmods which provides support for modern AMD and Intel
> > > graphics cards.  These ports, together with the linuxkpi, or lkpi, has
> > > made it significantly easier to port and update our graphics drivers.
> > > Further, these new drivers cover the same drivers as the old drm2
> driver.
> > >
> > > What does the community think?  Is there anyone still using the drm2
> > > driver on 12-CURRENT?  If so, what is preventing you from switching to
> > > the port?
> > >
> > > Thank you
> > > Regards
> > > --
> > > Niclas Zeising
> > > FreeBSD x11/graphics team
> > > _______________________________________________
> > > [hidden email] mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
> > >
> >
> > Sounds good ( deprecate resp remove ). It causes more confusion and
> > problems and it solves nothing.
> >
>
> Check the Makefiles
>
> % more /usr/ports/graphics/drm-next-kmod/Makefile
>
> ONLY_FOR_ARCHS= amd64
> ONLY_FOR_ARCHS_REASON=  the new KMS components are only supported on amd64
>
> Not to ia32 friendly.
>

So do people use i386 for desktop? And need the latest KMS stuff?

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Daniel Eischen
On Fri, 18 May 2018, Warner Losh wrote:

> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
> [hidden email]> wrote:
>>
>> Check the Makefiles
>>
>> % more /usr/ports/graphics/drm-next-kmod/Makefile
>>
>> ONLY_FOR_ARCHS= amd64
>> ONLY_FOR_ARCHS_REASON=  the new KMS components are only supported on amd64
>>
>> Not to ia32 friendly.
>>
>
> So do people use i386 for desktop? And need the latest KMS stuff?

I can easily imagine an embedded x86 kiosk type appliance.  Does
basic xorg stuff work without drm?

--
DE
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Cy Schubert-4
In reply to this post by Niclas Zeising-6
In message <CANCZdfosFaPJ_C7+-_9z0enyuK8ff=-[hidden email]
il.com>
, Warner Losh writes:

> On Fri, May 18, 2018 at 2:12 PM, Johannes Lundberg <[hidden email]>
> wrote:
>
> >
> >
> > On Fri, May 18, 2018 at 9:03 PM, Warner Losh <[hidden email]> wrote:
> >
> >> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
> >> [hidden email]> wrote:
> >>
> >> > On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote:
> >> > > On Fri, May 18, 2018, 20:00 Niclas Zeising <[hidden email]>
> >> wrote:
> >> > >
> >> > > > I propose that we remove the old drm2 driver (sys/dev/drm2) from
> >> > > > FreeBSD.  I suggest the driver is marked as deprecated in 11.x and
> >> > > > removed from 12.0, as was done for other drivers recently.  Some
> >> > > > background and rationale:
> >> > > >
> >> > > > The drm2 driver was the original port of a KMS driver to FreeBSD.
> >> It
> >> > > > was done by Konstantin Belousov to support Intel graphics cards, and
> >> > > > later extended by Jean-Sébastien Pédron as well as Konstantin to
> >> match
> >> > > > what's in Linux 3.8.  This included unstable support from Haswell,
> >> but
> >> > > > nothing newer than that.
> >> > > >
> >> > > > For quite some time now we have had the graphics/drm-stable-kmod and
> >> > > > graphics/drm-next-kmods which provides support for modern AMD and
> >> Intel
> >> > > > graphics cards.  These ports, together with the linuxkpi, or lkpi,
> >> has
> >> > > > made it significantly easier to port and update our graphics
> >> drivers.
> >> > > > Further, these new drivers cover the same drivers as the old drm2
> >> > driver.
> >> > > >
> >> > > > What does the community think?  Is there anyone still using the drm2
> >> > > > driver on 12-CURRENT?  If so, what is preventing you from switching
> >> to
> >> > > > the port?
> >> > > >
> >> > > > Thank you
> >> > > > Regards
> >> > > > --
> >> > > > Niclas Zeising
> >> > > > FreeBSD x11/graphics team
> >> > > > _______________________________________________
> >> > > > [hidden email] mailing list
> >> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> >> > freebsd.org"
> >> > > >
> >> > >
> >> > > Sounds good ( deprecate resp remove ). It causes more confusion and
> >> > > problems and it solves nothing.
> >> > >
> >> >
> >> > Check the Makefiles
> >> >
> >> > % more /usr/ports/graphics/drm-next-kmod/Makefile
> >> >
> >> > ONLY_FOR_ARCHS= amd64
> >> > ONLY_FOR_ARCHS_REASON=  the new KMS components are only supported on
> >> amd64
> >> >
> >> > Not to ia32 friendly.
> >> >
> >>
> >> So do people use i386 for desktop? And need the latest KMS stuff?
> >>
> >
> > Yeah I was wondering the same.. If you're running i386, do you need drm
> > drivers? Will scfb work an i386? (probably has legacy bios and if I
> > remember correctly, scfb is UEFI only)
> > I do feel sorry for anyone who would have to revert back to VESA...
> >
> > Would it be too much trouble to move it to a port?
> >
>
> If there's someone who needs it for i386, and wants to do the work and
> maintain it, we should allow it. But the drm2 maintainers have said its
> likely totally broken anyway.

Many Linux distros don't even support i386 any more. RHEL 5 was the
last for Red Hat (though Fedora still does). In all fairness, we will
need to bite the bullet one day too. Not suggesting anything but we
should start thinking about 32-bit and planning for it (& 2038).

I still have one i386 (the rest being amd64). VESA does suck on a
1280x768 monitor. The 915resolution port stopped working on it long ago.

I'm not saying keep it just for this one machine, this is just a data
point to the discussion. I'm also not saying to deprecate i386 now,
however we should start planning for the eventuality. Maybe FreeBSD 14,
16 or beyond.




--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

        The need of the many outweighs the greed of the few.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Johannes Lundberg
In reply to this post by Warner Losh
On Fri, May 18, 2018 at 9:22 PM, Ben Widawsky <[hidden email]> wrote:

> On 18-05-18 14:15:03, Warner Losh wrote:
> > On Fri, May 18, 2018 at 2:12 PM, Johannes Lundberg <[hidden email]>
> > wrote:
> >
> > >
> > >
> > > On Fri, May 18, 2018 at 9:03 PM, Warner Losh <[hidden email]> wrote:
> > >
> > >> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
> > >> [hidden email]> wrote:
> > >>
> > >> > On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote:
> > >> > > On Fri, May 18, 2018, 20:00 Niclas Zeising <[hidden email]>
> > >> wrote:
> > >> > >
> > >> > > > I propose that we remove the old drm2 driver (sys/dev/drm2) from
> > >> > > > FreeBSD.  I suggest the driver is marked as deprecated in 11.x
> and
> > >> > > > removed from 12.0, as was done for other drivers recently.  Some
> > >> > > > background and rationale:
> > >> > > >
> > >> > > > The drm2 driver was the original port of a KMS driver to
> FreeBSD.
> > >> It
> > >> > > > was done by Konstantin Belousov to support Intel graphics
> cards, and
> > >> > > > later extended by Jean-Sébastien Pédron as well as Konstantin to
> > >> match
> > >> > > > what's in Linux 3.8.  This included unstable support from
> Haswell,
> > >> but
> > >> > > > nothing newer than that.
> > >> > > >
> > >> > > > For quite some time now we have had the
> graphics/drm-stable-kmod and
> > >> > > > graphics/drm-next-kmods which provides support for modern AMD
> and
> > >> Intel
> > >> > > > graphics cards.  These ports, together with the linuxkpi, or
> lkpi,
> > >> has
> > >> > > > made it significantly easier to port and update our graphics
> > >> drivers.
> > >> > > > Further, these new drivers cover the same drivers as the old
> drm2
> > >> > driver.
> > >> > > >
> > >> > > > What does the community think?  Is there anyone still using the
> drm2
> > >> > > > driver on 12-CURRENT?  If so, what is preventing you from
> switching
> > >> to
> > >> > > > the port?
> > >> > > >
> > >> > > > Thank you
> > >> > > > Regards
> > >> > > > --
> > >> > > > Niclas Zeising
> > >> > > > FreeBSD x11/graphics team
> > >> > > > _______________________________________________
> > >> > > > [hidden email] mailing list
> > >> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > >> > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> > >> > freebsd.org"
> > >> > > >
> > >> > >
> > >> > > Sounds good ( deprecate resp remove ). It causes more confusion
> and
> > >> > > problems and it solves nothing.
> > >> > >
> > >> >
> > >> > Check the Makefiles
> > >> >
> > >> > % more /usr/ports/graphics/drm-next-kmod/Makefile
> > >> >
> > >> > ONLY_FOR_ARCHS= amd64
> > >> > ONLY_FOR_ARCHS_REASON=  the new KMS components are only supported on
> > >> amd64
> > >> >
> > >> > Not to ia32 friendly.
> > >> >
> > >>
> > >> So do people use i386 for desktop? And need the latest KMS stuff?
> > >>
> > >
> > > Yeah I was wondering the same.. If you're running i386, do you need drm
> > > drivers? Will scfb work an i386? (probably has legacy bios and if I
> > > remember correctly, scfb is UEFI only)
> > > I do feel sorry for anyone who would have to revert back to VESA...
> > >
> > > Would it be too much trouble to move it to a port?
> > >
> >
> > If there's someone who needs it for i386, and wants to do the work and
> > maintain it, we should allow it. But the drm2 maintainers have said its
> > likely totally broken anyway.
> >
> > Warner
>
> As a long time developer in drm/i915, and newly interested in FreeBSD (ie.
> no
> history on the matter), is there some upside and/or desire to have native
> support, or is the drm-next-kmod solution good enough?
>

Given the fast evolution of graphics hardware and the amount of code in
only the AMD and Intel drivers, keep several native implementations seems
impossible, if not wasteful.
If you are referring to drm2 in the kernel, that's not much more native
than the drm kmods, it still uses a linux compatibility layer (but not as
sophisticated).

If we were to focus our effort somewhere, it should be to create a Common
Kernel Programming Interface for Linux and *BSDs, especially for DRM
drivers. Something a bit more stable that what we see in Linux today.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Cy Schubert-4
In reply to this post by Niclas Zeising-6
In message <[hidden email]>, Daniel
Eischen wr
ites:

> On Fri, 18 May 2018, Warner Losh wrote:
>
> > On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
> > [hidden email]> wrote:
> >>
> >> Check the Makefiles
> >>
> >> % more /usr/ports/graphics/drm-next-kmod/Makefile
> >>
> >> ONLY_FOR_ARCHS= amd64
> >> ONLY_FOR_ARCHS_REASON=  the new KMS components are only supported on amd64
> >>
> >> Not to ia32 friendly.
> >>
> >
> > So do people use i386 for desktop? And need the latest KMS stuff?
>
> I can easily imagine an embedded x86 kiosk type appliance.  Does
> basic xorg stuff work without drm?

Yes, with VESA, albeit aspect ratios are off.


--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

        The need of the many outweighs the greed of the few.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Boris Samorodov-2
In reply to this post by Niclas Zeising-6
20.05.2018 16:03, Johannes Lundberg пишет:

> On Sun, May 20, 2018 at 1:36 PM, Boris Samorodov <[hidden email]> wrote:
>
>> 18.05.2018 20:58, Niclas Zeising пишет:
>>
>>> Is there anyone still using the drm2 driver on 12-CURRENT?  If so, what
>>> is preventing you from switching to the port?
>>
>> I use base packages and can not use port:
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069329.html
>
> If we remove drm.ko from base (which is suggested)  you would be able to
> install the drm-stable/next-kmod packages without conflict.

Great, thanks.

--
WBR, bsam
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Rozhuk Ivan-2
In reply to this post by Warner Losh
On Fri, 18 May 2018 21:12:26 +0100
Johannes Lundberg <[hidden email]> wrote:

Is Ryzen 2200G integrated graphic supported?


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Niclas Zeising-5
In reply to this post by Warner Losh
On 05/20/18 18:40, Steve Kargl wrote:

> On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh wrote:
>> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
>> [hidden email]> wrote:
>>
>>> On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote:
>>>> On Fri, May 18, 2018, 20:00 Niclas Zeising <[hidden email]> wrote:
>>>>
>>>>> I propose that we remove the old drm2 driver (sys/dev/drm2) from
>>>>> FreeBSD.  I suggest the driver is marked as deprecated in 11.x and
>>>>> removed from 12.0, as was done for other drivers recently.  Some
>>>>> background and rationale:
>>>>>
>>>>
>>>> Sounds good ( deprecate resp remove ). It causes more confusion and
>>>> problems and it solves nothing.
>>>>
>>>
>>> Check the Makefiles
>>>
>>> % more /usr/ports/graphics/drm-next-kmod/Makefile
>>>
>>> ONLY_FOR_ARCHS= amd64
>>> ONLY_FOR_ARCHS_REASON=  the new KMS components are only supported on amd64
>>>
>>> Not to ia32 friendly.
>>>
>>
>> So do people use i386 for desktop? And need the latest KMS stuff?
>>
>
> Just a data point.  I had to replace the dead disk in my laptop,
> and after 2 days of doing a re-install and update of -current
> on a shiny new SSD.
>
> Before loading Xorg.
>
> % kldstat
> Id Refs Address    Size     Name
>   1    7 0x800000 1ac31d4  kernel
>   2    1 0x1e9ae000 5000     ums.ko
>   3    1 0x1e9b9000 4000     uhid.ko
>
> After starting Xorg without an xorg.conf in /etc/X11.
>
> Id Refs Address    Size     Name
>   1   27 0x800000 1ac31d4  kernel
>   2    1 0x1e9ae000 5000     ums.ko
>   3    1 0x1e9b9000 4000     uhid.ko
>   4    1 0x1eaa9000 96000    i915kms.ko
>   5    1 0x1eb40000 4a000    drm2.ko
>   6    4 0x1eb8b000 5000     iicbus.ko
>   7    1 0x1ebc9000 3000     iic.ko
>   8    1 0x1ebcf000 4000     iicbb.ko
>
> So, drm2.ko and i915kms.ko are loaded automatically.  It is
> unclear why functionality that works should be removed.
>
> xwininfo shows
>
>    Width: 1400
>    Height: 1050
>    Depth: 24
>    Visual: 0x21
>

One of the reasons for the deprecation and removal of the drm2 bits is
that they prevent us from automatically loading the drm-next/stable-kmod
kernel modules, since the two collide.
Regards
--
Niclas
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Rozhuk Ivan-2
In reply to this post by Rozhuk Ivan-2
On Sun, 20 May 2018 16:32:50 +0100
Johannes Lundberg <[hidden email]> wrote:

> Not in the current port.
> I think it should be usable in 4.15 but need some more tweaking and
> updated firmware modules before we can update the port.
> Active development going on here
> https://github.com/FreeBSDDesktop/kms-drm/issues


Thanks!
What futures will avaible in 4.15 - 4.16?
Video decoding acceleration?
3d acceleration?

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Oliver Pinter-4
In reply to this post by Niclas Zeising-5
On 5/21/18, Steve Kargl <[hidden email]> wrote:

> On Mon, May 21, 2018 at 10:29:54AM -0700, Pete Wright wrote:
>>
>> On 05/21/2018 10:07, Steve Kargl wrote:
>> > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote:
>> >> On Sun, 20 May 2018 21:10:28 +0200
>> >> Oliver Pinter <[hidden email]> wrote:
>> >>
>> >>>> One of the reasons for the deprecation and removal of the drm2 bits
>> >>>> is that they prevent us from automatically loading the
>> >>>> drm-next/stable-kmod kernel modules, since the two collide.
>> >>>> Regards
>> >>>
>> >>> Then it wold be better to resolve this problem, rather then removing
>> >>> a
>> >>> working solution. What's about module versioning what in other cases
>> >>> works?
>> >>>
>> >> May be just move old drm2 to ports?
>> > Why?  "If it isn't broken, why fix it?"
>> >
>> > The conflict affects x86_64-*-freebsd aka amd64.  The
>> > conflict does not affect any other architecture.  The
>> > Makefile infrastructure can use MACHINE_ARCH to exclude
>> > drm2 from build of amd64.
>> >
>> > I don't use netgraph or any of the if_*.ko modules.
>> > Can we put all of that into ports?  I don't use any
>> > scsi controllers, so those can go too.  Why make it
>> > insanely fun for users to configure a FreeBSD system.
>> to play devils advocate - why include a kernel module that causes
>> conflicts for a vast majority of the laptop devices that you can
>> purchase today (as well as for the foreseeable future), while forcing
>> the up to date and actively developed driver to not work out of the box?
>
> Poor advocacy.  I stated old drm2 can be excluded by the
> Makefile infrastructure and I've already provided a barebones
> patch.
>
> Index: sys/modules/Makefile
> ===================================================================
> --- sys/modules/Makefile        (revision 333609)
> +++ sys/modules/Makefile        (working copy)
> @@ -112,7 +112,9 @@
>         ${_dpms} \
>         ${_dpt} \
>         ${_drm} \
> +.if ${MACHINE_ARCH} != amd64
>         ${_drm2} \
> +.endif
>         dummynet \
>         ${_ed} \
>         ${_efirt} \

I prefer something like this:

op@opn src# git diff
diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC
index 195b66daab51..034e2f8126fd 100644
--- a/sys/amd64/conf/GENERIC
+++ b/sys/amd64/conf/GENERIC
@@ -23,6 +23,7 @@ ident         GENERIC

 makeoptions    DEBUG=-g                # Build kernel with gdb(1) debug symbols
 makeoptions    WITH_CTF=1              # Run ctfconvert(1) for DTrace support
+makeoptions    WITHOUT_MODULES="drm drm2" # by default disable the
building of DRM* for GENERIC

 options        SCHED_ULE               # ULE scheduler
 options        PREEMPTION              # Enable kernel thread preemption


>
> Those interested in killing old drm2 on amd64 can add the
> requisite .if ... .endif to remove obsolscent *.ko.
>
>> IMHO it is issues like this (having out of date code that supports some
>> edge cases) which makes it harder for developers to dog-food the actual
>> OS they are developing on.
>
> You're talking to 1 of the 3 contributors that has tried over
> the last 2 decades to improve libm (both its quality and
> conformance to standards).  The development and testing is
> done on my old i386 laptop (which happily uses drm2), my
> amd64 systems, and at one time sparc64 (flame.freebsd.org).
> So, yeah, i386 and sparc64 allowed me to dog-food my code.
>
> BTW, there are uncountable many integers.  How about avoiding
> the conflict by using, say, '3' as in drm3.
>
> --
> Steve
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Johannes Lundberg
In reply to this post by Niclas Zeising-5
On Mon, May 21, 2018 at 23:50 Steve Kargl <[hidden email]>
wrote:

> On Mon, May 21, 2018 at 03:20:49PM -0700, K. Macy wrote:
> > >
> > > I just ask.
> > > Or why not include drm-next to base svn repo and add some
> > > option to make.conf to swith drm2/dem-next ?
> >
> > Even if it's not being built on amd64 we're still responsible for
> > keeping it building on !amd64 so long as it's in base. This makes
> > changing APIs and universe runs more burdensome. The graphics
> > developers have given you notice that it will now be your collective
> > responsibility to keep it up to date.
> >
>
> Not quite.  One graphics developer has indicated a desire
> to remove working code, because it interferes with the
> graphics developers' port on a single architecture.  There
> is no indication by that graphics developer that drm2 will
> be available in ports.  You can go read the original post
> here:
>
> https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069401.html
>
> The last paragraph is
>
>    What does the community think?  Is there anyone still using
>    the drm2 driver on 12-CURRENT?  If so, what is preventing
>    you from switching to the port?
>
> The answer to the last two questions are "yes" and "the port
> does not work on i386".
>
> Yes, I recognize that you're clever enough to purposefully
> break the API so that you can thumb your nose at those of
> us who have older hardware.
>
> What is wrong with using
>
> .if ${MACHINE_ARCH} != amd64
> ...
> .endif
>
> to enable/disable drm2?



The answer to the first question is that the consensus seem to be that
moving to a port is best for the _majority_.

Let me ask you, what’s wrong with this one-liner after base install
pkg install drm2
?


>
> --
> Steve
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

A. Wilcox
>>>>> I just ask.

>>>>> Or why not include drm-next to base svn repo and add some
>>>>> option to make.conf to swith drm2/dem-next ?
>>>>
>>>> Even if it's not being built on amd64 we're still responsible for
>>>> keeping it building on !amd64 so long as it's in base. This makes
>>>> changing APIs and universe runs more burdensome. The graphics
>>>> developers have given you notice that it will now be your collective
>>>> responsibility to keep it up to date.
>>>>
>>>
>>> Not quite.  One graphics developer has indicated a desire
>>> to remove working code, because it interferes with the
>>> graphics developers' port on a single architecture.  There
>>> is no indication by that graphics developer that drm2 will
>>> be available in ports.  You can go read the original post
>>> here:
>>>
>>> https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069401.html
>>>
>>> The last paragraph is
>>>
>>>    What does the community think?  Is there anyone still using
>>>    the drm2 driver on 12-CURRENT?  If so, what is preventing
>>>    you from switching to the port?
>>>
>>> The answer to the last two questions are "yes" and "the port
>>> does not work on i386".
>>>
>>> Yes, I recognize that you're clever enough to purposefully
>>> break the API so that you can thumb your nose at those of
>>> us who have older hardware.
>>>
>>> What is wrong with using
>>>
>>> .if ${MACHINE_ARCH} != amd64
>>> ...
>>> .endif
>>>
>>> to enable/disable drm2?


>
> With such long-time support offered by 11- branch, why hamper development
> of 12 by lugging around old, hard to maintain code that is relevant for
> only legacy hardware?
>


it makes me giggle that people still think non-amd64 is "legacy".

i386 is alive and well - new chips are being fabbed based on the 586
design with pci-e slots; not to mention things like the Talos and
AmigaOne for PowerPC.


--arw

--
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

K. Macy
>
>
> it makes me giggle that people still think non-amd64 is "legacy".
>
> i386 is alive and well - new chips are being fabbed based on the 586
> design with pci-e slots; not to mention things like the Talos and
> AmigaOne for PowerPC.


DRM2 doesn't support anything later than mid-Haswell. The chips in
question all pre-date 2007. Users of low-volume hardware on chips from
that period are welcome to continue to sustain themselves on the drm2
port just as the other 95+% of the user base will use what is now
referred to as drm-next. Even by powerpc maintainers' admission DRM2
also only barely works there. I've promised Justin that I'll make
drm-next work on Talos once POWER9 support is solid enough.

Cheers.

-M
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Rodney W. Grimes-4
> >
> >
> > it makes me giggle that people still think non-amd64 is "legacy".
> >
> > i386 is alive and well - new chips are being fabbed based on the 586
> > design with pci-e slots; not to mention things like the Talos and
> > AmigaOne for PowerPC.

Yes, some how we need to shake off the idea that all the world
is going to be 64 bit, and stop talking about EOL for 32 bit
x86,   IMHO that would be a serious mistake.  For one any VM
that does not need >4G of address space is a waste to run
in 64 bit mode.

> DRM2 doesn't support anything later than mid-Haswell. The chips in
> question all pre-date 2007. Users of low-volume hardware on chips from

Um, haswell announced in 2011, started shipping in mid 2013, and last
product started to ship in 2015, so if "mid-haswell" is the supported
chip arrena that would be pre date 2012?

Also as the Moore's law curve flattens expect the life of these
older, but not so old, machines to live quiet some time.  I
believe we are talking sandy bridge and earlier?  If that is
corret Sandy bridge is still a very viable system.

> that period are welcome to continue to sustain themselves on the drm2
> port just as the other 95+% of the user base will use what is now
> referred to as drm-next. Even by powerpc maintainers' admission DRM2
> also only barely works there. I've promised Justin that I'll make
> drm-next work on Talos once POWER9 support is solid enough.

I think the original RFC has been answer, yes there are people still
using DRM2, and they wish to continue to use it into the 12.x time
frame.

Lets find a technically agreeable solution to that, and move forward.

I am concerned about just disabling the compile on amd64,
that typically leads to bit rot of the i386 code.

I am concerned about just shoving it out to ports, as that makes
it rot even faster.

I am still very concerned that our in base i9xx code is like 4
years old and everyone is told to go to kmod-next from ports
as well.

No, I do not have a solution, but I have not tried hard to find
one.  I am sure if we try hard to find one it can be done.

Regards,
--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

K. Macy
> I am concerned about just shoving it out to ports, as that makes
> it rot even faster.
>
> I am still very concerned that our in base i9xx code is like 4
> years old and everyone is told to go to kmod-next from ports
> as well.
>
> No, I do not have a solution, but I have not tried hard to find
> one.  I am sure if we try hard to find one it can be done.

drm-next is a port and it's what most everyone will be using going
forward. You're asking us to make a special case for a small vocal
group of i386 users. If i386 is sufficiently important, its user base
can support it.

Cheers.
-M
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Rodney W. Grimes-4
> > I am concerned about just shoving it out to ports, as that makes
> > it rot even faster.
> >
> > I am still very concerned that our in base i9xx code is like 4
> > years old and everyone is told to go to kmod-next from ports
> > as well.
> >
> > No, I do not have a solution, but I have not tried hard to find
> > one.  I am sure if we try hard to find one it can be done.
>
> drm-next is a port and it's what most everyone will be using going
> forward. You're asking us to make a special case for a small vocal
> group of i386 users. If i386 is sufficiently important, its user base
> can support it.

Are you saying there is only one way forward?


--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

Steve Kargl
In reply to this post by K. Macy
On Tue, May 22, 2018 at 02:56:55PM -0700, K. Macy wrote:

> >
> >
> > it makes me giggle that people still think non-amd64 is "legacy".
> >
> > i386 is alive and well - new chips are being fabbed based on the 586
> > design with pci-e slots; not to mention things like the Talos and
> > AmigaOne for PowerPC.
>
>
> DRM2 doesn't support anything later than mid-Haswell. The chips in
> question all pre-date 2007. Users of low-volume hardware on chips from
> that period are welcome to continue to sustain themselves on the drm2
> port just as the other 95+% of the user base will use what is now
> referred to as drm-next. Even by powerpc maintainers' admission DRM2
> also only barely works there. I've promised Justin that I'll make
> drm-next work on Talos once POWER9 support is solid enough.

% dmesg | CPU
CPU: AMD FX(tm)-8350 Eight-Core Processor            (4018.34-MHz K8-class CPU)
% kldstat
troutmask:sgk[205] kldstat
Id Refs Address            Size     Name
 9    1 0xffffffff8141e000 db148    radeonkms.ko
10    1 0xffffffff814fa000 3f7d0    drm2.ko
11    2 0xffffffff8153a000 acf8     agp.ko
12    1 0xffffffff81545000 12f9     radeonkmsfw_CAICOS_pfp.ko
13    1 0xffffffff81547000 16f7     radeonkmsfw_CAICOS_me.ko
14    1 0xffffffff81549000 d73      radeonkmsfw_BTC_rlc.ko
15    1 0xffffffff8154a000 5f97     radeonkmsfw_CAICOS_mc.ko

Mid-Haswell?

--
Steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Deprecation and removal of the drm2 driver

K. Macy
Why are you running i386 on that?

On Tue, May 22, 2018 at 4:26 PM, Steve Kargl
<[hidden email]> wrote:

> On Tue, May 22, 2018 at 02:56:55PM -0700, K. Macy wrote:
>> >
>> >
>> > it makes me giggle that people still think non-amd64 is "legacy".
>> >
>> > i386 is alive and well - new chips are being fabbed based on the 586
>> > design with pci-e slots; not to mention things like the Talos and
>> > AmigaOne for PowerPC.
>>
>>
>> DRM2 doesn't support anything later than mid-Haswell. The chips in
>> question all pre-date 2007. Users of low-volume hardware on chips from
>> that period are welcome to continue to sustain themselves on the drm2
>> port just as the other 95+% of the user base will use what is now
>> referred to as drm-next. Even by powerpc maintainers' admission DRM2
>> also only barely works there. I've promised Justin that I'll make
>> drm-next work on Talos once POWER9 support is solid enough.
>
> % dmesg | CPU
> CPU: AMD FX(tm)-8350 Eight-Core Processor            (4018.34-MHz K8-class CPU)
> % kldstat
> troutmask:sgk[205] kldstat
> Id Refs Address            Size     Name
>  9    1 0xffffffff8141e000 db148    radeonkms.ko
> 10    1 0xffffffff814fa000 3f7d0    drm2.ko
> 11    2 0xffffffff8153a000 acf8     agp.ko
> 12    1 0xffffffff81545000 12f9     radeonkmsfw_CAICOS_pfp.ko
> 13    1 0xffffffff81547000 16f7     radeonkmsfw_CAICOS_me.ko
> 14    1 0xffffffff81549000 d73      radeonkmsfw_BTC_rlc.ko
> 15    1 0xffffffff8154a000 5f97     radeonkmsfw_CAICOS_mc.ko
>
> Mid-Haswell?
>
> --
> Steve
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
1234