>>>>> 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/
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC