[RFC] Deprecation and removal of the drm2 driver

Johannes Lundberg johalun0 at gmail.com
Tue May 22 12:07:13 UTC 2018


On Tue, May 22, 2018 at 1:03 PM, dpolyg <dpolyg at gmail.com> wrote:

> Hi Johannes,
>
> sorry, I forgot to mention in my previous e-mail that I tried drm-stable
> too with the same result:
>
> root at ShuttleD47:/usr/ports/graphics/drm-stable-kmod # make
> ===>  drm-stable-kmod-g20180505_5 not supported on 10.x or older, no kernel
> support.
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/graphics/drm-stable-kmod
>
> I have latest port tree
> (run '# portsnap fetch update' in advance).
>


Yes, sorry I wasn't clear. You'll need 11.2-PRERELEASE or wait for 11.2
release.


>
> Regards,
> Denis.
>
>
> On 22/05/2018 8:55 PM, Johannes Lundberg wrote:
>
>> On Tue, May 22, 2018 at 12:47 PM, dpolyg <dpolyg at gmail.com> wrote:
>>
>> I have one comment regarding usage of the drm2 on a "legacy" hardware.
>>> Excuse me in advance if I misunderstand something.
>>> For the last 2-3 years I'm playing with devices such as small form factor
>>> PCs from Shuttle:
>>> http://global.shuttle.com/products/productsList?categoryId=69
>>> or from Gigabyte:
>>> https://www.gigabyte.com/us/Mini-PcBarebone
>>> or Intel "NUC"s.
>>> To my experience drm-next doesn't work on lower price (Celeron/Atom)
>>> models. Do I missing something?
>>> Here is concrete example:
>>> I have a Shuttle DS47: http://global.shuttle.com/main
>>> /productsDetail?productId=1718
>>> running FreeBSD 11.1-RELEASE and drm2.ko loaded + Xorg + compton.
>>> Having that I made a box with a voice control and ability to make a SIP
>>> video call to it from a smartphone (WebRTC) (imagine "Amazon Show"
>>> powered
>>> by stock FeeBSD) but I never install any drm-next on it. Stock amd64
>>> kernel
>>> used. No ports compiled. Only "pkg install ..." + custom code as the most
>>> front end.
>>> After reading this thread I tried to compile drm-next on my DS47 box:
>>>
>>> root at ShuttleD47:/usr/ports/graphics/drm-next-kmod # uname -a
>>> FreeBSD ShuttleD47 11.1-RELEASE-p10 FreeBSD 11.1-RELEASE-p10 #0: Tue May
>>> 8 05:21:56 UTC 2018 root at amd64-builder.daemonology
>>> .net:/usr/obj/usr/src/sys/GENERIC  amd64
>>> root at ShuttleD47:/usr/ports/graphics/drm-next-kmod # make
>>> ===>  drm-next-kmod-4.11.g20180505_1 not supported on 10.x or older, no
>>> kernel
>>> support.
>>> *** Error code 1
>>>
>>> Stop.
>>> make: stopped in /usr/ports/graphics/drm-next-kmod
>>>
>>> Why drm-next thinks it lives on a 10.x kernel or older?
>>> Is such usage case already considered as legacy?
>>> Is this hardware supported by drm-next?
>>> https://www.amazon.com/Best-Sellers-Electronics-Mini-Compute
>>> rs/zgbs/electronics/13896591011
>>>
>>>
>>>
>> Hi Denis
>>
>> For FreeBSD 11, please use drm-stable-kmod (this is based on drm drivers
>> in
>> Linux 4.9 and has been backported to FreeBSD 11)
>>
>> For FreeBSD 12, drm-next-kmod is currently Linux 4.11 but will updated to
>> Linux 4.15 soon. (of course, drm-stable-kmod is also usable on 12-CURRENT.
>> you might wanna use that if drm-next-kmod is buggy)
>>
>> If you need the firmware, gpu-firmware-kmod port is used for both
>> drm-xxx-kmod ports.
>>
>>
>>
>>
>> Regards,
>>> Denis.
>>>
>>>
>>>
>>> On 22/05/2018 4:51 PM, Andreas Nilsson wrote:
>>>
>>> On Tue, May 22, 2018 at 8:50 AM, Johannes Lundberg <johalun0 at gmail.com>
>>>> wrote:
>>>>
>>>> On Mon, May 21, 2018 at 23:50 Steve Kargl <sgk at troutmask.apl.washington.
>>>>
>>>>> edu>
>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>> Hello,
>>>>
>>>> If you were running GNU/Linux, you would be using the equivalent of
>>>> drm-stable-kmod or drm-next-kmod. Why do you want to run older code on
>>>> FreeBSD?
>>>>
>>>> Hardware and software moves on. One does not expect to run the latest
>>>> hardware with old software, old hardware and new software might work, if
>>>> someone is willing to maintain old code.
>>>>
>>>> Since the proposal was to keep drm2 in 11, you're looking at support
>>>> until
>>>> 2021, will you still run that old hardware then?
>>>>
>>>> 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?
>>>>
>>>> Best regards
>>>> Andreas
>>>> _______________________________________________
>>>> freebsd-x11 at freebsd.org mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>>>> To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"
>>>>
>>>>
>>>>
>>


More information about the freebsd-x11 mailing list