In message <CANCZdfosFaPJ_C7+-_9z0enyuK8ff=-iVLUVzV19oafedF-Mtg_at_mail.gma il.com> , Warner Losh writes: > On Fri, May 18, 2018 at 2:12 PM, Johannes Lundberg <johalun0_at_gmail.com> > wrote: > > > > > > > On Fri, May 18, 2018 at 9:03 PM, Warner Losh <imp_at_bsdimp.com> wrote: > > > >> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl < > >> sgk_at_troutmask.apl.washington.edu> wrote: > >> > >> > On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote: > >> > > On Fri, May 18, 2018, 20:00 Niclas Zeising <zeising_at_freebsd.org> > >> 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 > >> > > > _______________________________________________ > >> > > > freebsd-current_at_freebsd.org mailing list > >> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_ > >> > 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 <Cy.Schubert_at_cschubert.com> FreeBSD UNIX: <cy_at_FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.Received on Fri May 18 2018 - 18:30:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC