On Mon, 21 May 2018 10:29:54 -0700 "Pete Wright" <p...@nomadlogic.org> said
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 <oliver.pin...@hardenedbsd.org> 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?
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. Having things work on modern hardware by
default seems like a great way to get more people on the platform
testing and bugfixing things.
The suggestion seems like a pretty good middle ground, people with older
devices will still have workable code while also making it easier to
continue to follow the state of the art in terms of hardware support.
-pete
Along the lines of Devils advocate;
Why do *any* <YOUR_FAVORITE_BRAND_HERE> get "special" attention?
Why does Intel get all the love? None of my nVidia cards get this; granted
they're blobs. But I've been waiting ~1yr. for support for my AMD GPU to be
supported.
IOW why not make all of them a port? IMHO vt(4) , while a nice *initial* effort.
Still falls *far* short of sc(ons). It's no big deal to whip up a custom kernel
with support for your chosen video card/APU/GPU. Then there can be less
complaints about "favoritism" -- everyone is treated equally. Why must the
stock (GENERIC) kernel support "graphics mode" out-of-the-box?
It appears to me; at this stage; or the *proposed* stage; that Intel will be
the only _well supported_ hardware out-of-the-box.
tl;dr;
Make all video cards/APU/GPU support come from ports/kernel OPTIONS_KNOBS
Thanks for your indulgence.
--Chris
--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
