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

Hi Johannes,

sorry, I forgot to mention in my previous e-mail that I tried drm-stable 
too with the same result:

root@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).

Regards,
Denis.

On 22/05/2018 8:55 PM, Johannes Lundberg wrote:
> On Tue, May 22, 2018 at 12:47 PM, dpolyg <[email protected]> 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@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 [email protected]
>> .net:/usr/obj/usr/src/sys/GENERIC  amd64
>> root@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 <[email protected]>
>>> wrote:
>>>
>>> On Mon, May 21, 2018 at 23:50 Steve Kargl <[email protected].
>>>> 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
>>> _______________________________________________
>>> [email protected] mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>>> To unsubscribe, send any mail to "[email protected]"
>>>
>>>
> 
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[email protected]"