Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, 4 Jun 2018 at 22:36, Matthew Macy wrote: > > Implementing a callback in 140 different files for the sake of a handful of > out of tree drivers and people not reading updating is pretty prohibitive. 11 > may be more your cup of tea. This was the in tree wifi drivers.. :-) Dude, we're on the same side. I'll take a look at the multicast iterator stuff once I figure out why the athp receive performance in my driver is terrible-y. -adrian ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
Implementing a callback in 140 different files for the sake of a handful of out of tree drivers and people not reading updating is pretty prohibitive. 11 may be more your cup of tea. On Mon, Jun 4, 2018 at 22:27 Adrian Chadd wrote: > Hi, > > If there's an API that isn't being used then great, I'll go find it > and fix up pieces in my spare time to use it. But the last drive by > cut/paste didn't do that; it just changed the code in place. :-) > > > > -adrian > ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
Hi, If there's an API that isn't being used then great, I'll go find it and fix up pieces in my spare time to use it. But the last drive by cut/paste didn't do that; it just changed the code in place. :-) -adrian ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, Jun 4, 2018 at 12:03 PM, Adrian Chadd wrote: > Hi, > > As a driver/framework developer - no, don't do that. > > It's worked mostly great for the video side of things because your > touch points are "the VM system" and "linuxkpi". And they're all in > one big driver pull from Linux. > > For wifi as an example - it has a bunch of userland components, a > kernel framework component (net80211); it gets API churn from people > who keep making networking API changes without making them opaque (i > just got bitten by the STAILQ -> CK_STAILQ changes for multicast > iteration, instead of us growing a multicast iterator function thing.) We've had one for several years. You're just not using it. > Having it be multiple drivers/firmware means that anyone doing wifi > development here would have to install /all/ of the relevant packages > and the net80211 stuff and userland just to get any work done and hope > it stays in sync. This is the same old saw of people who can't be bothered to use ports. It is more of a headache with ABI drift but it's certainly not a fundamental impediment. -M ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
Hi, As a driver/framework developer - no, don't do that. It's worked mostly great for the video side of things because your touch points are "the VM system" and "linuxkpi". And they're all in one big driver pull from Linux. For wifi as an example - it has a bunch of userland components, a kernel framework component (net80211); it gets API churn from people who keep making networking API changes without making them opaque (i just got bitten by the STAILQ -> CK_STAILQ changes for multicast iteration, instead of us growing a multicast iterator function thing.) Having it be multiple drivers/firmware means that anyone doing wifi development here would have to install /all/ of the relevant packages and the net80211 stuff and userland just to get any work done and hope it stays in sync. It'd be nice if that was our stretch goal, but we ain't there yet. As for your intel NIC - I'm sorry that you've had issues getting that into the tree but you can just jump in #freebsd-wifi and whine at us until we commit it. That's what we're there for. -adrian ___ 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"
Re: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)
On Thu, May 31, 2018 at 09:04:25PM -0700, K. Macy wrote: > This is where culling older bug reports comes in. Well, even with doing that, the sheer number really doesn't help the S/N that much. It may make someone a bit neurotic like me feel a bit better, but that's all. > However, when I've tried wading through the bug system to find things > that I might be able to fix, I have not found it easy at all. To me, reasoning about 'search' is the riqht direction to go. (Apologies to folks for the long URLs, but I would rather not hide the search terms here.) We've been inconsistent about applying the 'patch-ready' tag to indicate something is ready to go, but here's the current list for the Base System: https://bugs.freebsd.org/bugzilla/buglist.cgi?keywords=patch-ready&keywords_type=allwords&list_id=232422&product=Base%20System&query_format=advanced&resolution=--- 8 bugs. Not that bad. The 'patch' tag by itself produces a much less satisfying result: https://bugs.freebsd.org/bugzilla/buglist.cgi?keywords=patch&keywords_type=allwords&limit=0&list_id=232422&order=bug_id%20DESC&product=Base%20System&query_format=advanced&resolution=--- 600 bugs. Moderately overwhelming. Narrowing it down to just the 'kern' component only helps a little: https://bugs.freebsd.org/bugzilla/buglist.cgi?component=kern&keywords=patch&keywords_type=allwords&list_id=232433&product=Base%20System&query_format=advanced&resolution=--- 300 bugs. Looking for tag 'regression' within that is more satisfying: https://bugs.freebsd.org/bugzilla/buglist.cgi?component=kern&keywords=regression&keywords_type=allwords&list_id=232433&product=Base%20System&query_format=advanced&resolution=--- 82 bugs. tl:dr; expecting any sane person to 'browse' thousands of entries of any kind from _any_ kind of list, is itself madness. OTOH myself, and koobs and others, are willing to work on the search metadata to at least make 'search' reasonable. [obv. disclaimer: I am only citing statistics for Bugzilla here, not Phabricator; I simply know it better.] mcl ___ 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"
Re: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)
On Thu, May 31, 2018 at 10:25:10PM -0500, Matthew D. Fuller wrote: > because the incentives are rigged. A bad outside contribution brought > into ports more often yields "hey, you should have noticed" to the > committer and more opprobrium back to the submitter. I believe you're missing two important points: - there is feedback to the ports committers that goes on behind the scenes (e.g. not on public mailing lists); - everyone who uses FreeBSD needs src to work. Not everyone who uses FreeBSD needs even a large fraction of ports to work. Let me reframe this debate. To me, the correct comparison is: "compare commits to src" vs. "compare commits to key ports pieces such as Mk/, perl, apache24, &c" Commits to the latter are thoroughly tested* in external staging areas and/or "exp-runs" done by portmgr, _before_ they hit the tree. For src committers that aren't aware: since adopting the exp-runs, there have been far, far, fewer large-scale regressions of the ports tree. Check the monthly portmgr reports to see how much work is going into this -- and that doesn't count projects like gnome and kde that do their own external precommit work. Also, IMHO talking about whether this process is, or should be, automated misses the point. The distinguishing feature is the buy-in by the people who are making changes to the tree to have done sufficient testing _first_. Without that buy-in, the tools are irrelvant. Next, let me assure you that anyone who breaks those key pieces of ports hears about it _immediately_. tl:dr; at least for the key pieces, FreeBSD ports has moved away from the "throw it at the wall to see if it will stick" paradigm. That's the part of the codebase that ought to be the comparison point. mcl * almost always. They are supposed to be, in any case. Humans are involved. ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Thu, May 31, 2018 at 11:34 PM Oliver Pinter < oliver.pin...@hardenedbsd.org> wrote: > > > On Thursday, May 31, 2018, Johannes Lundberg wrote: > >> On Thu, May 31, 2018 at 4:34 PM Joe Maloney >> wrote: >> >> > I personally wish that more drivers, and firmware were separated from >> > base. >> > >> > >> I'm not a committer > > >> >> > If you are not a committer, how and why want to remove drm2 from the base > system? > Nice way to shoot down people (who are working together with active committers) trying to make FreeBSD and it's derivatives a better OS for its users. As a way to help prevent breakage I suggested an upgrade to the outdated build infrastructure. Something that should be done anyway. But what do I know, I don't have a commit bit... > > From other side, how you want to maintain VM and other KPI changes in > unmaintained and abandoned port? ;) Or how you can guarantee to everyone > who breaks KPI to follow these breaks in an external abandoned port? > > >> >> but as I understand there's not pre-commit integration >> tests.. If one had that, plus that it would test build kmod ports against >> the pre-commit state of head as well, then maybe this would work. >> >> >> > For example wireless firmware: >> > >> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433 >> > >> > That was a ticket which I chimed in on about a firmware I needed to make >> > my wireless adapter work. I went through numerous efforts on IRC, and >> > elsewhere to try to bring attention that ticket in order to attempt to >> get >> > that firmware backported for several 10.x releases in a row without >> > success. The firmware worked perfectly fine in PC-BSD where it was >> cherry >> > picked for numerous 10.x releases. >> > >> > Technically since I was using PC-BSD, and was a committer for that >> project >> > I had no real dire need to reach out to FreeBSD about the issue. I was >> > simply trying to help anyone else who might be encountering the same >> issue >> > trying to use stock FreeBSD because it was a simple backport. If my >> effort >> > had turned out to be more fruitful I would have spent more time pursuing >> > tickets, diffs, or whatever to get more things back-ported when I found >> > them. I am not sure where the breakdown was which did not allow that to >> > happen. Anyways I don't want to bikeshed, or anything but I just >> wanted to >> > point out how I think having more drivers, and firmware in ports could >> be >> > helpful to enhance compatibility for end users. >> > >> > Having a separate port for legacy drm could definitely make things >> easier >> > to providing installation options for end users, and automating the post >> > install action chosen in TrueOS, GhostBSD, and future derivative >> projects >> > tailored for the desktop use case. For example for TrueOS we boot the >> > installer in failsafe mode with either VESA, or SCFB depending on >> whether >> > or not BIOS, or EFI is booted. Then we could simply make a checkbox for >> > legacy intel, or skylake + to install the correct package then the >> module >> > path for either driver can more or less remain the same. Eventually >> with >> > something like devmatch maybe that can even be fully automatic. >> > >> > Joe Maloney >> > >> > On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen >> > wrote: >> > >> >> On Thu, 31 May 2018, Konstantin Belousov wrote: >> >> >> >> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote: >> >>> >> >>> We're not replacing anything. We are moving the older drm1 and drm2 >> from >> kernel to ports to make it easier for the majority of the users to >> load >> the >> correct driver without conflicts. >> >> >>> >> >>> You do understand that you increase your maintainence load by this >> move. >> >>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in >> stable >> >>> branches, so you will need to chase these updates. >> >>> >> >> >> >> I agree. One argument previously made was that it's easier >> >> to maintain in ports. One data point from me - I rarely >> >> update my ports, I update my OS much more frequently. In >> >> fact, some times my ports get so out of date I just >> >> (take off and) nuke /usr/local (from orbit, it's the only >> >> way to be sure). >> >> >> >> Also, are we trying to solve a problem by moving drm[2] to >> >> ports that won't be a problem when base is pkg'ized? If >> >> drm[2] is a package unto itself, then you don't have this >> >> problem of ports conflicting with it, at least not so >> >> much. You can either not install the base drm[2] package >> >> or deinstall it to make way for a conflicting port. Once >> >> drm[2] is pkg rm'd, it's not going to be reinstalled >> >> again when you update the base OS. >> >> >> >> And don't we have the same problem with sendmail and a >> >> few other base services? >> >> >> >> -- >> >> DE >> >> >> >> ___ >> >> freebsd-current@freebsd.org mail
Re: [RFC] Deprecation and removal of the drm2 driver
On Fri, Jun 1, 2018, 07:42 Oliver Pinter wrote: > On Friday, June 1, 2018, Pete Wright wrote: > > > > > > > On 05/31/2018 15:34, Oliver Pinter wrote: > > > >> On Thursday, May 31, 2018, Johannes Lundberg > wrote: > >> > >> On Thu, May 31, 2018 at 4:34 PM Joe Maloney > >>> wrote: > >>> > >>> I personally wish that more drivers, and firmware were separated from > base. > > > I'm not a committer > >>> > >> > >> > >>> If you are not a committer, how and why want to remove drm2 from the > >> base > >> system? > >> > > Johannes did not start this threat. A committer, Niclas Zeising, did. > > Johannes has stepped up and done a ton of work (along with many others, > > some committers and some not) to get modern intel and amd GPU's working > > under freebsd. > > > > > True. Yes I agree that their work is hard and it's a very big step forward > for supporting modern hardwares. And it's required modern desktops, but > please don't break the existing ones. Agreed This is my only request, probably it > was expressed in a harsh way, sorry. > > > > > > > > > this was something that was a gaping hole in freebsd when this work > > started a bit over a year ago, and i'm not sure why more committers > weren't > > embarrassed by this gap nor motivated to chip in. > > > > regardless - not sure why you'd take his comment out of context :/ the > > full quote was: > > "I'm not a committer but as I understand there's not pre-commit > > integration tests.. If one had that, plus that it would test build kmod > > ports against the pre-commit state of head as well, then maybe this would > > work." > > > > not really sure what's controversial about that statement which would > > prompt your reply - but i guess people dedicating their spare time to > help > > create useful things for others shouldn't go unpunished. > > > > well i guess i broke my promise to ignore this bikeshed :( > > > > -p > > > > -- > > 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"
Re: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)
> > I wrote up a couple more paragraphs about why I think it happens and > what we'd need to do to import more of that sense over into src. But > it was way longer than it needs to be. We get a lot more man-hours in > ports/ acting as conduits for the "outside patches -> svn" pipeline > because the incentives are rigged. A bad outside contribution brought > into ports more often yields "hey, you should have noticed" to the > committer and more opprobrium back to the submitter. A bad outside > contribution brought into src falls all over the commiter. > > Not entirely unreasonable, since a lot of even small-ish breakages in > src are much bigger deals than even large-ish breakages in ports. But > it still makes it expensive to contemplate being a conduit... Whereas the incentives in ports are structured such as to encourage being a conduit and arguably it's a big part of being a responsible porter, in src there is an active disincentive. A committer invites substantial criticism by breaking src by importing a change but invites no criticism for ignoring review requests or patches. There are a few people who go through the pain of wading through patches and committing them but as a general rule one has to have some level of rapport with a proxy to get changes in without a bit. Whereas with TrueOS the Git PR system lets one submit a change, the CI system builds it to verify, and then it's thumbs up or thumbs down and it goes in, undergoes further review / refinement, or is rejected outright. There's something to be said for automation. Submitting enhancements is even harder. There's always someone who will be upset by a change in existing behavior, no matter how logical a change may seem to the rest of us. This obvious change is almost 10 years old and seems completely common sense: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139389 I've been keeping it in my bookmarks hoping that Eitan will commit it, but may at some point overcome my reservations and just go ahead and commit. My problem with the bug system is classification. If a bug report refers to something I touched recently, it's easy to assign it to me. However, when I've tried wading through the bug system to find things that I might be able to fix, I have not found it easy at all. This is where culling older bug reports comes in. With a poor signal to noise ratio from too many PRs, what really happens is _fewer_ things get fixed, not more. Cheers. -M ___ 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"
Re: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)
On Thu, May 31, 2018 at 03:49:46PM -0500 I heard the voice of Mark Linimon, and lo! it spake thus: > > We do slightly better turning over ports PRs -- due to the fact that > we attach a maintainer field to each port. This doesn't completely > solve the problem, but it goes some distance. >From my perspective as a maintainer of some and occasional contributor to others, I think "slightly" undersells it a bit; hardly without exception, but it generally works OK. I wrote up a couple more paragraphs about why I think it happens and what we'd need to do to import more of that sense over into src. But it was way longer than it needs to be. We get a lot more man-hours in ports/ acting as conduits for the "outside patches -> svn" pipeline because the incentives are rigged. A bad outside contribution brought into ports more often yields "hey, you should have noticed" to the committer and more opprobrium back to the submitter. A bad outside contribution brought into src falls all over the commiter. Not entirely unreasonable, since a lot of even small-ish breakages in src are much bigger deals than even large-ish breakages in ports. But it still makes it expensive to contemplate being a conduit... -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Friday, June 1, 2018, Pete Wright wrote: > > > On 05/31/2018 15:34, Oliver Pinter wrote: > >> On Thursday, May 31, 2018, Johannes Lundberg wrote: >> >> On Thu, May 31, 2018 at 4:34 PM Joe Maloney >>> wrote: >>> >>> I personally wish that more drivers, and firmware were separated from base. I'm not a committer >>> >> >> >>> If you are not a committer, how and why want to remove drm2 from the >> base >> system? >> > Johannes did not start this threat. A committer, Niclas Zeising, did. > Johannes has stepped up and done a ton of work (along with many others, > some committers and some not) to get modern intel and amd GPU's working > under freebsd. > True. Yes I agree that their work is hard and it's a very big step forward for supporting modern hardwares. And it's required modern desktops, but please don't break the existing ones. This is my only request, probably it was expressed in a harsh way, sorry. > > > this was something that was a gaping hole in freebsd when this work > started a bit over a year ago, and i'm not sure why more committers weren't > embarrassed by this gap nor motivated to chip in. > > regardless - not sure why you'd take his comment out of context :/ the > full quote was: > "I'm not a committer but as I understand there's not pre-commit > integration tests.. If one had that, plus that it would test build kmod > ports against the pre-commit state of head as well, then maybe this would > work." > > not really sure what's controversial about that statement which would > prompt your reply - but i guess people dedicating their spare time to help > create useful things for others shouldn't go unpunished. > > well i guess i broke my promise to ignore this bikeshed :( > > -p > > -- > 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On 05/31/2018 15:34, Oliver Pinter wrote: On Thursday, May 31, 2018, Johannes Lundberg wrote: On Thu, May 31, 2018 at 4:34 PM Joe Maloney wrote: I personally wish that more drivers, and firmware were separated from base. I'm not a committer If you are not a committer, how and why want to remove drm2 from the base system? Johannes did not start this threat. A committer, Niclas Zeising, did. Johannes has stepped up and done a ton of work (along with many others, some committers and some not) to get modern intel and amd GPU's working under freebsd. this was something that was a gaping hole in freebsd when this work started a bit over a year ago, and i'm not sure why more committers weren't embarrassed by this gap nor motivated to chip in. regardless - not sure why you'd take his comment out of context :/ the full quote was: "I'm not a committer but as I understand there's not pre-commit integration tests.. If one had that, plus that it would test build kmod ports against the pre-commit state of head as well, then maybe this would work." not really sure what's controversial about that statement which would prompt your reply - but i guess people dedicating their spare time to help create useful things for others shouldn't go unpunished. well i guess i broke my promise to ignore this bikeshed :( -p -- 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Thursday, May 31, 2018, Johannes Lundberg wrote: > On Thu, May 31, 2018 at 4:34 PM Joe Maloney > wrote: > > > I personally wish that more drivers, and firmware were separated from > > base. > > > > > I'm not a committer > > If you are not a committer, how and why want to remove drm2 from the base system? >From other side, how you want to maintain VM and other KPI changes in unmaintained and abandoned port? ;) Or how you can guarantee to everyone who breaks KPI to follow these breaks in an external abandoned port? > > but as I understand there's not pre-commit integration > tests.. If one had that, plus that it would test build kmod ports against > the pre-commit state of head as well, then maybe this would work. > > > > For example wireless firmware: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433 > > > > That was a ticket which I chimed in on about a firmware I needed to make > > my wireless adapter work. I went through numerous efforts on IRC, and > > elsewhere to try to bring attention that ticket in order to attempt to > get > > that firmware backported for several 10.x releases in a row without > > success. The firmware worked perfectly fine in PC-BSD where it was > cherry > > picked for numerous 10.x releases. > > > > Technically since I was using PC-BSD, and was a committer for that > project > > I had no real dire need to reach out to FreeBSD about the issue. I was > > simply trying to help anyone else who might be encountering the same > issue > > trying to use stock FreeBSD because it was a simple backport. If my > effort > > had turned out to be more fruitful I would have spent more time pursuing > > tickets, diffs, or whatever to get more things back-ported when I found > > them. I am not sure where the breakdown was which did not allow that to > > happen. Anyways I don't want to bikeshed, or anything but I just wanted > to > > point out how I think having more drivers, and firmware in ports could be > > helpful to enhance compatibility for end users. > > > > Having a separate port for legacy drm could definitely make things easier > > to providing installation options for end users, and automating the post > > install action chosen in TrueOS, GhostBSD, and future derivative projects > > tailored for the desktop use case. For example for TrueOS we boot the > > installer in failsafe mode with either VESA, or SCFB depending on whether > > or not BIOS, or EFI is booted. Then we could simply make a checkbox for > > legacy intel, or skylake + to install the correct package then the module > > path for either driver can more or less remain the same. Eventually with > > something like devmatch maybe that can even be fully automatic. > > > > Joe Maloney > > > > On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen > > wrote: > > > >> On Thu, 31 May 2018, Konstantin Belousov wrote: > >> > >> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote: > >>> > >>> We're not replacing anything. We are moving the older drm1 and drm2 > from > kernel to ports to make it easier for the majority of the users to > load > the > correct driver without conflicts. > > >>> > >>> You do understand that you increase your maintainence load by this > move. > >>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in > stable > >>> branches, so you will need to chase these updates. > >>> > >> > >> I agree. One argument previously made was that it's easier > >> to maintain in ports. One data point from me - I rarely > >> update my ports, I update my OS much more frequently. In > >> fact, some times my ports get so out of date I just > >> (take off and) nuke /usr/local (from orbit, it's the only > >> way to be sure). > >> > >> Also, are we trying to solve a problem by moving drm[2] to > >> ports that won't be a problem when base is pkg'ized? If > >> drm[2] is a package unto itself, then you don't have this > >> problem of ports conflicting with it, at least not so > >> much. You can either not install the base drm[2] package > >> or deinstall it to make way for a conflicting port. Once > >> drm[2] is pkg rm'd, it's not going to be reinstalled > >> again when you update the base OS. > >> > >> And don't we have the same problem with sendmail and a > >> few other base services? > >> > >> -- > >> DE > >> > >> ___ > >> 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" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscrib
Re: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)
Straying off-topic from the Subject line ... On Thu, May 31, 2018 at 11:34:18AM -0400, Joe Maloney wrote: > Technically since I was using PC-BSD, and was a committer for that > project I had no real dire need to reach out to FreeBSD about the > [wireless driver issue]. I was simply trying to help anyone else > who might be encountering the same issue trying to use stock FreeBSD > because it was a simple backport. If my effort had turned out to be > more fruitful I would have spent more time pursuing tickets, diffs, > or whatever to get more things back-ported when I found them. FreeBSD doesn't do well handling problem reports. We've known it for years but no one has come up with a magic solution yet. We have volunteers willing to triage, but not enough committers willing to suspend working on their own priorities to work through the backlog. (It's understandable, really.) And the backlog is astounding. (*) I hesitate to even look, but ... kern 3270 ports 2010 bin1607 The flow has decreased from where it was a few years ago -- this stat says that 727 total new ones have come in this month. We do slightly better turning over ports PRs -- due to the fact that we attach a maintainer field to each port. This doesn't completely solve the problem, but it goes some distance. Finally, the number of PRs with patches stands around 1021. That is particularly disappointing. Well, it's too bad we weren't able to corral you into keeping working on such things. fwiw. mcl *: there are other categories but these constitute the majority (9485 in total). ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Thu, May 31, 2018 at 4:34 PM Joe Maloney wrote: > I personally wish that more drivers, and firmware were separated from > base. > > I'm not a committer but as I understand there's not pre-commit integration tests.. If one had that, plus that it would test build kmod ports against the pre-commit state of head as well, then maybe this would work. > For example wireless firmware: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433 > > That was a ticket which I chimed in on about a firmware I needed to make > my wireless adapter work. I went through numerous efforts on IRC, and > elsewhere to try to bring attention that ticket in order to attempt to get > that firmware backported for several 10.x releases in a row without > success. The firmware worked perfectly fine in PC-BSD where it was cherry > picked for numerous 10.x releases. > > Technically since I was using PC-BSD, and was a committer for that project > I had no real dire need to reach out to FreeBSD about the issue. I was > simply trying to help anyone else who might be encountering the same issue > trying to use stock FreeBSD because it was a simple backport. If my effort > had turned out to be more fruitful I would have spent more time pursuing > tickets, diffs, or whatever to get more things back-ported when I found > them. I am not sure where the breakdown was which did not allow that to > happen. Anyways I don't want to bikeshed, or anything but I just wanted to > point out how I think having more drivers, and firmware in ports could be > helpful to enhance compatibility for end users. > > Having a separate port for legacy drm could definitely make things easier > to providing installation options for end users, and automating the post > install action chosen in TrueOS, GhostBSD, and future derivative projects > tailored for the desktop use case. For example for TrueOS we boot the > installer in failsafe mode with either VESA, or SCFB depending on whether > or not BIOS, or EFI is booted. Then we could simply make a checkbox for > legacy intel, or skylake + to install the correct package then the module > path for either driver can more or less remain the same. Eventually with > something like devmatch maybe that can even be fully automatic. > > Joe Maloney > > On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen > wrote: > >> On Thu, 31 May 2018, Konstantin Belousov wrote: >> >> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote: >>> >>> We're not replacing anything. We are moving the older drm1 and drm2 from kernel to ports to make it easier for the majority of the users to load the correct driver without conflicts. >>> >>> You do understand that you increase your maintainence load by this move. >>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable >>> branches, so you will need to chase these updates. >>> >> >> I agree. One argument previously made was that it's easier >> to maintain in ports. One data point from me - I rarely >> update my ports, I update my OS much more frequently. In >> fact, some times my ports get so out of date I just >> (take off and) nuke /usr/local (from orbit, it's the only >> way to be sure). >> >> Also, are we trying to solve a problem by moving drm[2] to >> ports that won't be a problem when base is pkg'ized? If >> drm[2] is a package unto itself, then you don't have this >> problem of ports conflicting with it, at least not so >> much. You can either not install the base drm[2] package >> or deinstall it to make way for a conflicting port. Once >> drm[2] is pkg rm'd, it's not going to be reinstalled >> again when you update the base OS. >> >> And don't we have the same problem with sendmail and a >> few other base services? >> >> -- >> DE >> >> ___ >> 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Thu, 31 May 2018 18:02:26 +0200, "Ronald Klop" wrote: > On Thu, 31 May 2018 17:34:18 +0200, Joe Maloney > wrote: > > > I personally wish that more drivers, and firmware were separated from > > base. > > > > For example wireless firmware: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433 > > > > That was a ticket which I chimed in on about a firmware I needed to make > > my > > wireless adapter work. I went through numerous efforts on IRC, and > > elsewhere to try to bring attention that ticket in order to attempt to > > get > > that firmware backported for several 10.x releases in a row without > > success. The firmware worked perfectly fine in PC-BSD where it was > > cherry > > picked for numerous 10.x releases. > > > I would support an idea that the FreeBSD project only delivers CURRENT > (and one periodic release with security fixes) and parties like PC-BSD > maintain stable branches and support for companies. > > I read about this somewhere a while ago and the idea sticks. Backporting > to code 2+ years old is not the best use of human volunteer resources IMHO. > > Regards, > Ronald. > > > > > > > Technically since I was using PC-BSD, and was a committer for that > > project > > I had no real dire need to reach out to FreeBSD about the issue. I was > > simply trying to help anyone else who might be encountering the same > > issue > > trying to use stock FreeBSD because it was a simple backport. If my > > effort > > had turned out to be more fruitful I would have spent more time pursuing > > tickets, diffs, or whatever to get more things back-ported when I found > > them. I am not sure where the breakdown was which did not allow that to > > happen. Anyways I don't want to bikeshed, or anything but I just wanted > > to > > point out how I think having more drivers, and firmware in ports could be > > helpful to enhance compatibility for end users. > > > > Having a separate port for legacy drm could definitely make things easier > > to providing installation options for end users, and automating the post > > install action chosen in TrueOS, GhostBSD, and future derivative projects > > tailored for the desktop use case. For example for TrueOS we boot the > > installer in failsafe mode with either VESA, or SCFB depending on whether > > or not BIOS, or EFI is booted. Then we could simply make a checkbox for > > legacy intel, or skylake + to install the correct package then the module > > path for either driver can more or less remain the same. Eventually with > > something like devmatch maybe that can even be fully automatic. > > > > Joe Maloney > > > > On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen > > wrote: > > > >> On Thu, 31 May 2018, Konstantin Belousov wrote: > >> > >> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote: > >>> > >>> We're not replacing anything. We are moving the older drm1 and drm2 > >>> from > kernel to ports to make it easier for the majority of the users to > load > the > correct driver without conflicts. > > >>> > >>> You do understand that you increase your maintainence load by this > >>> move. > >>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in > >>> stable > >>> branches, so you will need to chase these updates. > >>> > >> > >> I agree. One argument previously made was that it's easier > >> to maintain in ports. One data point from me - I rarely > >> update my ports, I update my OS much more frequently. In > >> fact, some times my ports get so out of date I just > >> (take off and) nuke /usr/local (from orbit, it's the only > >> way to be sure). > >> > >> Also, are we trying to solve a problem by moving drm[2] to > >> ports that won't be a problem when base is pkg'ized? If > >> drm[2] is a package unto itself, then you don't have this > >> problem of ports conflicting with it, at least not so > >> much. You can either not install the base drm[2] package > >> or deinstall it to make way for a conflicting port. Once > >> drm[2] is pkg rm'd, it's not going to be reinstalled > >> again when you update the base OS. > >> > >> And don't we have the same problem with sendmail and a > >> few other base services? > >> > >> -- > >> DE > >> > >> ___ > >> 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" > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.
Re: [RFC] Deprecation and removal of the drm2 driver
On 05/31/18 16:21, Rodney W. Grimes wrote: I do remeber for a long time this was a -current only modules, is that still true, or can I load it on 11.0, 11.1 and 11.2Beta3 now? drm-stable-kmod works on 11.2 (including the betas) and later. We can't backport the needed changes to the lkpi to the releases, for obvious reasons, but they were backported some time between 11.1 and now. Regards -- Niclas ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On 31/05/2018 18:34, Joe Maloney wrote: > I personally wish that more drivers, and firmware were separated from > base. I would agree with you IF FreeBSD had a defined and stable Device Driver Interface. Or Thirdparty Module Interface. Or whatever the name. -- Andriy Gapon ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Thu, 31 May 2018 17:34:18 +0200, Joe Maloney wrote: I personally wish that more drivers, and firmware were separated from base. For example wireless firmware: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433 That was a ticket which I chimed in on about a firmware I needed to make my wireless adapter work. I went through numerous efforts on IRC, and elsewhere to try to bring attention that ticket in order to attempt to get that firmware backported for several 10.x releases in a row without success. The firmware worked perfectly fine in PC-BSD where it was cherry picked for numerous 10.x releases. I would support an idea that the FreeBSD project only delivers CURRENT (and one periodic release with security fixes) and parties like PC-BSD maintain stable branches and support for companies. I read about this somewhere a while ago and the idea sticks. Backporting to code 2+ years old is not the best use of human volunteer resources IMHO. Regards, Ronald. Technically since I was using PC-BSD, and was a committer for that project I had no real dire need to reach out to FreeBSD about the issue. I was simply trying to help anyone else who might be encountering the same issue trying to use stock FreeBSD because it was a simple backport. If my effort had turned out to be more fruitful I would have spent more time pursuing tickets, diffs, or whatever to get more things back-ported when I found them. I am not sure where the breakdown was which did not allow that to happen. Anyways I don't want to bikeshed, or anything but I just wanted to point out how I think having more drivers, and firmware in ports could be helpful to enhance compatibility for end users. Having a separate port for legacy drm could definitely make things easier to providing installation options for end users, and automating the post install action chosen in TrueOS, GhostBSD, and future derivative projects tailored for the desktop use case. For example for TrueOS we boot the installer in failsafe mode with either VESA, or SCFB depending on whether or not BIOS, or EFI is booted. Then we could simply make a checkbox for legacy intel, or skylake + to install the correct package then the module path for either driver can more or less remain the same. Eventually with something like devmatch maybe that can even be fully automatic. Joe Maloney On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen wrote: On Thu, 31 May 2018, Konstantin Belousov wrote: On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote: We're not replacing anything. We are moving the older drm1 and drm2 from kernel to ports to make it easier for the majority of the users to load the correct driver without conflicts. You do understand that you increase your maintainence load by this move. dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable branches, so you will need to chase these updates. I agree. One argument previously made was that it's easier to maintain in ports. One data point from me - I rarely update my ports, I update my OS much more frequently. In fact, some times my ports get so out of date I just (take off and) nuke /usr/local (from orbit, it's the only way to be sure). Also, are we trying to solve a problem by moving drm[2] to ports that won't be a problem when base is pkg'ized? If drm[2] is a package unto itself, then you don't have this problem of ports conflicting with it, at least not so much. You can either not install the base drm[2] package or deinstall it to make way for a conflicting port. Once drm[2] is pkg rm'd, it's not going to be reinstalled again when you update the base OS. And don't we have the same problem with sendmail and a few other base services? -- DE ___ 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" ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
I personally wish that more drivers, and firmware were separated from base. For example wireless firmware: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433 That was a ticket which I chimed in on about a firmware I needed to make my wireless adapter work. I went through numerous efforts on IRC, and elsewhere to try to bring attention that ticket in order to attempt to get that firmware backported for several 10.x releases in a row without success. The firmware worked perfectly fine in PC-BSD where it was cherry picked for numerous 10.x releases. Technically since I was using PC-BSD, and was a committer for that project I had no real dire need to reach out to FreeBSD about the issue. I was simply trying to help anyone else who might be encountering the same issue trying to use stock FreeBSD because it was a simple backport. If my effort had turned out to be more fruitful I would have spent more time pursuing tickets, diffs, or whatever to get more things back-ported when I found them. I am not sure where the breakdown was which did not allow that to happen. Anyways I don't want to bikeshed, or anything but I just wanted to point out how I think having more drivers, and firmware in ports could be helpful to enhance compatibility for end users. Having a separate port for legacy drm could definitely make things easier to providing installation options for end users, and automating the post install action chosen in TrueOS, GhostBSD, and future derivative projects tailored for the desktop use case. For example for TrueOS we boot the installer in failsafe mode with either VESA, or SCFB depending on whether or not BIOS, or EFI is booted. Then we could simply make a checkbox for legacy intel, or skylake + to install the correct package then the module path for either driver can more or less remain the same. Eventually with something like devmatch maybe that can even be fully automatic. Joe Maloney On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen wrote: > On Thu, 31 May 2018, Konstantin Belousov wrote: > > On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote: >> >> We're not replacing anything. We are moving the older drm1 and drm2 from >>> kernel to ports to make it easier for the majority of the users to load >>> the >>> correct driver without conflicts. >>> >> >> You do understand that you increase your maintainence load by this move. >> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable >> branches, so you will need to chase these updates. >> > > I agree. One argument previously made was that it's easier > to maintain in ports. One data point from me - I rarely > update my ports, I update my OS much more frequently. In > fact, some times my ports get so out of date I just > (take off and) nuke /usr/local (from orbit, it's the only > way to be sure). > > Also, are we trying to solve a problem by moving drm[2] to > ports that won't be a problem when base is pkg'ized? If > drm[2] is a package unto itself, then you don't have this > problem of ports conflicting with it, at least not so > much. You can either not install the base drm[2] package > or deinstall it to make way for a conflicting port. Once > drm[2] is pkg rm'd, it's not going to be reinstalled > again when you update the base OS. > > And don't we have the same problem with sendmail and a > few other base services? > > -- > DE > > ___ > 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Thu, 31 May 2018, Konstantin Belousov wrote: On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote: We're not replacing anything. We are moving the older drm1 and drm2 from kernel to ports to make it easier for the majority of the users to load the correct driver without conflicts. You do understand that you increase your maintainence load by this move. dev/drm and dev/drm2 use KPIs which cannot be kept stable even in stable branches, so you will need to chase these updates. I agree. One argument previously made was that it's easier to maintain in ports. One data point from me - I rarely update my ports, I update my OS much more frequently. In fact, some times my ports get so out of date I just (take off and) nuke /usr/local (from orbit, it's the only way to be sure). Also, are we trying to solve a problem by moving drm[2] to ports that won't be a problem when base is pkg'ized? If drm[2] is a package unto itself, then you don't have this problem of ports conflicting with it, at least not so much. You can either not install the base drm[2] package or deinstall it to make way for a conflicting port. Once drm[2] is pkg rm'd, it's not going to be reinstalled again when you update the base OS. And don't we have the same problem with sendmail and a few other base services? -- DE ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
> > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA512 > > > > > > Am Thu, 24 May 2018 09:10:10 -0700 (PDT) > > > "Rodney W. Grimes" schrieb: > > > > > > > -- Start of PGP signed section. > > > > > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote: > > > > > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote: > > > > > > > > >Also as the Moore's law curve flattens expect the life of these > > > > > > > > >older, but not so old, machines to live quiet some time. I > > > > > > > > >believe we are talking sandy bridge and earlier? If that is > > > > > > > > >corret Sandy bridge is still a very viable system. > > > > > > > > > > > > > > > > I noticed this lack of love for older systems recently. > > > > > > > > > > > > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and > > > RCs. > > > > > > > > > > > > > > > > Turns out, you can't install FreeBSD using a USB stick image > > > because the > > > > > > > > BIOS only support MBR. No idea why MBR support was dropped for > > > the USB images. > > > > > > > > > > > > > > > > In the end I had to find a CD burner, and after a couple of > > > tries managed to > > > > > > > > install from CD. > > > > > > > > > > > > > > > > After that, my ansible playbooks started failing because > > > /boot/loader.conf > > > > > > > > is absent if you boot from zfs in combination with MBR. > > > > > > > > > > > > > > > > Pity. This older server hardware is great for trying out new > > > releases, play > > > > > > > > with zfs, etc. > > > > > > > > > > > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are > > > > > > > now > > > > > > > built as hybrid images, supporting both MBR and GPT, as well as > > > being > > > > > > > written to a flash drive (like memstick.img) as well as a CD. > > > > > > > > > > > > To clarify a minor point here, are the amd64 disc1.iso images or > > > > > > both the amd64 and i386 disk1.iso images being built as "hybrid"? > > > > > > > > > > > > > > > > Only amd64. i386 does not have UEFI-/GPT-related boot issues. > > > > > > > > Here is a data point: > > > > > > > > Test system is Dell R710, > > > > First attempt is with BIOS in Boot mode: Bios > > > > Second attempt is with BIOS in Boot mode: UEFI > > > > > > > > Attemtped to boot amd64 version: > > > > Screen goes white background, text appears (yes, way indented) > > > > BTX version is 1.02 > > > > Consoles: internal video/keyboard > > > > _ > > > > > > > > That last _ is a blinking cursor, system is hung, does repsond to > > > > C-A-del > > > > > > > > > > > > Second attempt: > > > > Works properly > > > > > > > > > > > > I am going after Ed Maste's posted build image in the other thread > > > > now... > > > > > > > > > > > > > > > > > > > As this is what I see on my system: > > > > > > root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-* > > > > > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 > > > : ID=0xee, > > > > > > start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695 > > > sectors > > > > > > FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data > > > > > > '11_2_BETA2_I386_CD' (bootable) > > > > > > > MBR support was initially removed from the memstick installer, as > > > it is > > > > > > > not compatible with some UEFI implementations. (Or, at least that > > > is my > > > > > > > understanding, based on my limited intimate knowledge of UEFI.) > > > > > > > > > > > > > > > > > Glen > > > > > > > > > -- End of PGP section, PGP failed! > > > > > > > > > > Today, I tried to eliminate FreeBSD's native KMS drm2 by installing > > > graphics/drm-stable-kmod (ports tree at revision 471172) on CURRENT > > > (FreeBSD 12.0-CURRENT > > > #46 r334401: Wed May 30 23:32:45 CEST 2018 amd64, CUSTOM kernel). > > > > > > The hardware is a presumably UEFI capable ASROCK Z77-Pro4M (latest > > > firmware available > > > from late 2013) equipted with a XEON IvyBridge: > > > > > > CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class CPU) > > > Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 > > > > > > Features=0xbfebfbff > > > > > > Features2=0x7fbae3ff > > > AMD Features=0x28100800 > > > AMD Features2=0x1 > > > Structured Extended Features=0x281 > > > XSAVE Features=0x1 > > > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > > > TSC: P-state invariant, performance statistics > > > real memory = 17179869184 (16384 MB) > > > avail memory = 16295137280 (15540 MB) > > > Event timer "LAPIC" quality 600 > > > ACPI APIC Table: > > > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > > > > > > > > > The box isn't capable of booting FreeBSD in UEFI (while Linux and Windows > > > seems to work). > > > So I'm stuck with BIOS. > > > > > > Loading i915kms.ko/drm2.ko on the system put the console in a > > > high-resolution mode > > > instead of this crap 80x25 ancient console immediately. > > > > > > Loading graphics/drm-stable-km
Re: [RFC] Deprecation and removal of the drm2 driver
On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote: > On Wed, May 30, 2018 at 10:57 PM O. Hartmann wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Am Thu, 24 May 2018 09:10:10 -0700 (PDT) > > "Rodney W. Grimes" schrieb: > > > > > -- Start of PGP signed section. > > > > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote: > > > > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote: > > > > > > > >Also as the Moore's law curve flattens expect the life of these > > > > > > > >older, but not so old, machines to live quiet some time. I > > > > > > > >believe we are talking sandy bridge and earlier? If that is > > > > > > > >corret Sandy bridge is still a very viable system. > > > > > > > > > > > > > > I noticed this lack of love for older systems recently. > > > > > > > > > > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and > > RCs. > > > > > > > > > > > > > > Turns out, you can't install FreeBSD using a USB stick image > > because the > > > > > > > BIOS only support MBR. No idea why MBR support was dropped for > > the USB images. > > > > > > > > > > > > > > In the end I had to find a CD burner, and after a couple of > > tries managed to > > > > > > > install from CD. > > > > > > > > > > > > > > After that, my ansible playbooks started failing because > > /boot/loader.conf > > > > > > > is absent if you boot from zfs in combination with MBR. > > > > > > > > > > > > > > Pity. This older server hardware is great for trying out new > > releases, play > > > > > > > with zfs, etc. > > > > > > > > > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now > > > > > > built as hybrid images, supporting both MBR and GPT, as well as > > being > > > > > > written to a flash drive (like memstick.img) as well as a CD. > > > > > > > > > > To clarify a minor point here, are the amd64 disc1.iso images or > > > > > both the amd64 and i386 disk1.iso images being built as "hybrid"? > > > > > > > > > > > > > Only amd64. i386 does not have UEFI-/GPT-related boot issues. > > > > > > Here is a data point: > > > > > > Test system is Dell R710, > > > First attempt is with BIOS in Boot mode: Bios > > > Second attempt is with BIOS in Boot mode: UEFI > > > > > > Attemtped to boot amd64 version: > > > Screen goes white background, text appears (yes, way indented) > > > BTX version is 1.02 > > > Consoles: internal video/keyboard > > > _ > > > > > > That last _ is a blinking cursor, system is hung, does repsond to C-A-del > > > > > > > > > Second attempt: > > > Works properly > > > > > > > > > I am going after Ed Maste's posted build image in the other thread now... > > > > > > > > > > > > > > > As this is what I see on my system: > > > > > root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-* > > > > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 > > : ID=0xee, > > > > > start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695 > > sectors > > > > > FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data > > > > > '11_2_BETA2_I386_CD' (bootable) > > > > > > MBR support was initially removed from the memstick installer, as > > it is > > > > > > not compatible with some UEFI implementations. (Or, at least that > > is my > > > > > > understanding, based on my limited intimate knowledge of UEFI.) > > > > > > > > > > > > > > Glen > > > > > > > -- End of PGP section, PGP failed! > > > > > > > Today, I tried to eliminate FreeBSD's native KMS drm2 by installing > > graphics/drm-stable-kmod (ports tree at revision 471172) on CURRENT > > (FreeBSD 12.0-CURRENT > > #46 r334401: Wed May 30 23:32:45 CEST 2018 amd64, CUSTOM kernel). > > > > The hardware is a presumably UEFI capable ASROCK Z77-Pro4M (latest > > firmware available > > from late 2013) equipted with a XEON IvyBridge: > > > > CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class CPU) > > Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 > > > > Features=0xbfebfbff > > > > Features2=0x7fbae3ff > > AMD Features=0x28100800 > > AMD Features2=0x1 > > Structured Extended Features=0x281 > > XSAVE Features=0x1 > > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > > TSC: P-state invariant, performance statistics > > real memory = 17179869184 (16384 MB) > > avail memory = 16295137280 (15540 MB) > > Event timer "LAPIC" quality 600 > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > > > > > > The box isn't capable of booting FreeBSD in UEFI (while Linux and Windows > > seems to work). > > So I'm stuck with BIOS. > > > > Loading i915kms.ko/drm2.ko on the system put the console in a > > high-resolution mode > > instead of this crap 80x25 ancient console immediately. > > > > Loading graphics/drm-stable-kmod as requested (via rc.conf.local) ends up > > in a trap > > 12/crash. Very nice for such an old hardware. graphics/drm-next-kmod does > > load without > > crash
Re: [RFC] Deprecation and removal of the drm2 driver
On Wed, May 30, 2018 at 10:57 PM O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Am Thu, 24 May 2018 09:10:10 -0700 (PDT) > "Rodney W. Grimes" schrieb: > > > -- Start of PGP signed section. > > > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote: > > > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote: > > > > > > >Also as the Moore's law curve flattens expect the life of these > > > > > > >older, but not so old, machines to live quiet some time. I > > > > > > >believe we are talking sandy bridge and earlier? If that is > > > > > > >corret Sandy bridge is still a very viable system. > > > > > > > > > > > > I noticed this lack of love for older systems recently. > > > > > > > > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and > RCs. > > > > > > > > > > > > Turns out, you can't install FreeBSD using a USB stick image > because the > > > > > > BIOS only support MBR. No idea why MBR support was dropped for > the USB images. > > > > > > > > > > > > In the end I had to find a CD burner, and after a couple of > tries managed to > > > > > > install from CD. > > > > > > > > > > > > After that, my ansible playbooks started failing because > /boot/loader.conf > > > > > > is absent if you boot from zfs in combination with MBR. > > > > > > > > > > > > Pity. This older server hardware is great for trying out new > releases, play > > > > > > with zfs, etc. > > > > > > > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now > > > > > built as hybrid images, supporting both MBR and GPT, as well as > being > > > > > written to a flash drive (like memstick.img) as well as a CD. > > > > > > > > To clarify a minor point here, are the amd64 disc1.iso images or > > > > both the amd64 and i386 disk1.iso images being built as "hybrid"? > > > > > > > > > > Only amd64. i386 does not have UEFI-/GPT-related boot issues. > > > > Here is a data point: > > > > Test system is Dell R710, > > First attempt is with BIOS in Boot mode: Bios > > Second attempt is with BIOS in Boot mode: UEFI > > > > Attemtped to boot amd64 version: > > Screen goes white background, text appears (yes, way indented) > > BTX version is 1.02 > > Consoles: internal video/keyboard > > _ > > > > That last _ is a blinking cursor, system is hung, does repsond to C-A-del > > > > > > Second attempt: > > Works properly > > > > > > I am going after Ed Maste's posted build image in the other thread now... > > > > > > > > > > > As this is what I see on my system: > > > > root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-* > > > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 > : ID=0xee, > > > > start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695 > sectors > > > > FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data > > > > '11_2_BETA2_I386_CD' (bootable) > > > > > MBR support was initially removed from the memstick installer, as > it is > > > > > not compatible with some UEFI implementations. (Or, at least that > is my > > > > > understanding, based on my limited intimate knowledge of UEFI.) > > > > > > > > > > > Glen > > > > > -- End of PGP section, PGP failed! > > > > Today, I tried to eliminate FreeBSD's native KMS drm2 by installing > graphics/drm-stable-kmod (ports tree at revision 471172) on CURRENT > (FreeBSD 12.0-CURRENT > #46 r334401: Wed May 30 23:32:45 CEST 2018 amd64, CUSTOM kernel). > > The hardware is a presumably UEFI capable ASROCK Z77-Pro4M (latest > firmware available > from late 2013) equipted with a XEON IvyBridge: > > CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 > > Features=0xbfebfbff > > Features2=0x7fbae3ff > AMD Features=0x28100800 > AMD Features2=0x1 > Structured Extended Features=0x281 > XSAVE Features=0x1 > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > TSC: P-state invariant, performance statistics > real memory = 17179869184 (16384 MB) > avail memory = 16295137280 (15540 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > > > The box isn't capable of booting FreeBSD in UEFI (while Linux and Windows > seems to work). > So I'm stuck with BIOS. > > Loading i915kms.ko/drm2.ko on the system put the console in a > high-resolution mode > instead of this crap 80x25 ancient console immediately. > > Loading graphics/drm-stable-kmod as requested (via rc.conf.local) ends up > in a trap > 12/crash. Very nice for such an old hardware. graphics/drm-next-kmod does > load without > crashing the system - but the console is stuck in the clumsy 80x25 mode. > > So why should I vote for non-working drivers to replace perfectly working > ones? > > oh > > We're not replacing anything. We are moving the older drm1 and drm2 from kernel to ports to make it easier for the majority of the users to load the correct driver with
Re: [RFC] Deprecation and removal of the drm2 driver
On 05/30/18 23:51, O. Hartmann wrote: Loading graphics/drm-stable-kmod as requested (via rc.conf.local) ends up in a trap 12/crash. Very nice for such an old hardware. graphics/drm-next-kmod does load without crashing the system - but the console is stuck in the clumsy 80x25 mode. So why should I vote for non-working drivers to replace perfectly working ones? Usually the crashes you get are low hanging fruit. Why not get the backtrace and resolve the crash? It should take less than 10 minutes. --HPS ___ 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"
Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
On 30 May 2018 at 18:08, Philip Homburg wrote: >>Strange. Can you try an updated test image of mine >>(https://people.freebsd.org/~emaste/mini-image-2018-05-28.xz) Oops - that should have been https://people.freebsd.org/~emaste/mini-image-2018-05-28-amd64.xz But the most recent snapshot images have been built the same way now: https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img ___ 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"
Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
>Strange. Can you try an updated test image of mine >(https://people.freebsd.org/~emaste/mini-image-2018-05-28.xz) That gives a 404. I have the strong suspision that your previous image doesn't get recognized as bootable because the C/H/S values are not filled in. ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Thu, 24 May 2018 09:10:10 -0700 (PDT) "Rodney W. Grimes" schrieb: > -- Start of PGP signed section. > > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote: > > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote: > > > > > >Also as the Moore's law curve flattens expect the life of these > > > > > >older, but not so old, machines to live quiet some time. I > > > > > >believe we are talking sandy bridge and earlier? If that is > > > > > >corret Sandy bridge is still a very viable system. > > > > > > > > > > I noticed this lack of love for older systems recently. > > > > > > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and RCs. > > > > > > > > > > Turns out, you can't install FreeBSD using a USB stick image because > > > > > the > > > > > BIOS only support MBR. No idea why MBR support was dropped for the > > > > > USB images. > > > > > > > > > > In the end I had to find a CD burner, and after a couple of tries > > > > > managed to > > > > > install from CD. > > > > > > > > > > After that, my ansible playbooks started failing because > > > > > /boot/loader.conf > > > > > is absent if you boot from zfs in combination with MBR. > > > > > > > > > > Pity. This older server hardware is great for trying out new > > > > > releases, play > > > > > with zfs, etc. > > > > > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now > > > > built as hybrid images, supporting both MBR and GPT, as well as being > > > > written to a flash drive (like memstick.img) as well as a CD. > > > > > > To clarify a minor point here, are the amd64 disc1.iso images or > > > both the amd64 and i386 disk1.iso images being built as "hybrid"? > > > > > > > Only amd64. i386 does not have UEFI-/GPT-related boot issues. > > Here is a data point: > > Test system is Dell R710, > First attempt is with BIOS in Boot mode: Bios > Second attempt is with BIOS in Boot mode: UEFI > > Attemtped to boot amd64 version: > Screen goes white background, text appears (yes, way indented) > BTX version is 1.02 > Consoles: internal video/keyboard > _ > > That last _ is a blinking cursor, system is hung, does repsond to C-A-del > > > Second attempt: > Works properly > > > I am going after Ed Maste's posted build image in the other thread now... > > > > > > > As this is what I see on my system: > > > root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-* > > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 : > > > ID=0xee, > > > start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695 > > > sectors > > > FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data > > > '11_2_BETA2_I386_CD' (bootable) > > > > MBR support was initially removed from the memstick installer, as it is > > > > not compatible with some UEFI implementations. (Or, at least that is my > > > > understanding, based on my limited intimate knowledge of UEFI.) > > > > > > > > Glen > > > -- End of PGP section, PGP failed! > Today, I tried to eliminate FreeBSD's native KMS drm2 by installing graphics/drm-stable-kmod (ports tree at revision 471172) on CURRENT (FreeBSD 12.0-CURRENT #46 r334401: Wed May 30 23:32:45 CEST 2018 amd64, CUSTOM kernel). The hardware is a presumably UEFI capable ASROCK Z77-Pro4M (latest firmware available from late 2013) equipted with a XEON IvyBridge: CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 Features=0xbfebfbff Features2=0x7fbae3ff AMD Features=0x28100800 AMD Features2=0x1 Structured Extended Features=0x281 XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16295137280 (15540 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs The box isn't capable of booting FreeBSD in UEFI (while Linux and Windows seems to work). So I'm stuck with BIOS. Loading i915kms.ko/drm2.ko on the system put the console in a high-resolution mode instead of this crap 80x25 ancient console immediately. Loading graphics/drm-stable-kmod as requested (via rc.conf.local) ends up in a trap 12/crash. Very nice for such an old hardware. graphics/drm-next-kmod does load without crashing the system - but the console is stuck in the clumsy 80x25 mode. So why should I vote for non-working drivers to replace perfectly working ones? oh - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWw8c/AAKCRDS528fyFhY lBl7Af0R7ymOzkWp7GcqymhUiOgfy3qvTSmHYgbTzYxsD54GEIfoAMvH1pHFp4yL b0NYx9HR+BU3d6GAf0Xq0sq78kMFAf9
Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
On Wed, May 30, 2018 at 08:29:57AM -0700, Rodney W. Grimes wrote: > > On 25 May 2018 at 04:51, Philip Homburg wrote: > > > > > > I have bad news and some good news. > > > > > > The bad news is that with this image the USB stick doesn't get recognized > > > as > > > a boot device. Same as with the 11.2-BETA2 images. > > > > At least it's not a regression. > > > > > The good news is that if I completely recreate the MBR, keeping the > > > layout of > > > the partitions the same, then the USB stick is recognized. > > > > Strange. Can you try an updated test image of mine > > (https://people.freebsd.org/~emaste/mini-image-2018-05-28.xz) or this > > week's -CURRENT snapshot? > > What version(s) of the snapshots sould be tested? > disc1.iso? dvd1.iso? memstick? > The *memstick.img for amd64, from this week. (20180529 r334337) https://lists.freebsd.org/pipermail/freebsd-snapshots/2018-May/000411.html Glen signature.asc Description: PGP signature
Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
> On 25 May 2018 at 04:51, Philip Homburg wrote: > > > > I have bad news and some good news. > > > > The bad news is that with this image the USB stick doesn't get recognized as > > a boot device. Same as with the 11.2-BETA2 images. > > At least it's not a regression. > > > The good news is that if I completely recreate the MBR, keeping the layout > > of > > the partitions the same, then the USB stick is recognized. > > Strange. Can you try an updated test image of mine > (https://people.freebsd.org/~emaste/mini-image-2018-05-28.xz) or this > week's -CURRENT snapshot? What version(s) of the snapshots sould be tested? disc1.iso? dvd1.iso? memstick? -- Rod Grimes rgri...@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"
Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
On 25 May 2018 at 04:51, Philip Homburg wrote: > > I have bad news and some good news. > > The bad news is that with this image the USB stick doesn't get recognized as > a boot device. Same as with the 11.2-BETA2 images. At least it's not a regression. > The good news is that if I completely recreate the MBR, keeping the layout of > the partitions the same, then the USB stick is recognized. Strange. Can you try an updated test image of mine (https://people.freebsd.org/~emaste/mini-image-2018-05-28.xz) or this week's -CURRENT snapshot? ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
32b compat is quite different than i386 arch. It makes sense to maintain 32b compat for quite a while. On Wed, May 30, 2018 at 3:33 AM, Thomas Mueller wrote: >> Wow, this blew up quite a lot bigger than I anticipated. I'll try to >> summarize the discussion a bit below and then suggest a way forward. > >> The primary reasons we want to do this is because there are conflicts between >> the new drm drivers in ports, and the drm drivers in base, since they control >> the same hardware. It is hard to make conflicting drivers to auto load in a >> consistent way. In order to improve the desktop experience I'd like to see >> that graphics drivers are loaded on system boot. There is also a push from >> upstream to have the xf86-video* drivers stop loading driver kernel modules. >> It is also easier to keep a port updated than keeping the base system >> updated, >> and updates can propagate to multiple FreeBSD versions at once. This will >> also ensure that all ports use the same firmware blobs. > >> So, to the summary. A lot of people are using i386, and as such still need >> the old drm drivers. There were also some reports about issues with the >> drm-next/stable drivers, which needs investigating. Power is another >> architecture that also is not supported by drm-next/stable, although we hope >> to extend support to powerpc in the future. There was a lot of discussion >> regarding making it into a port, or only excluding the driver on amd64, and >> similar suggestions. > >> To move forward, we'll do the following: Note that this is for current only. >> We take the drm and drm2 drivers and make a port for it, maintained by the >> graphics team (x11@). After a transition period, then the drivers are >> removed >> from base. At the same time, pkg-messages are added to relevant places to >> point people to the various available drm drivers. > >> Regards > >> Niclas Zeising >> FreeBSD graphics/x11 team > > One reason I can think of to maintain i386 compatibility is to be able to run > wine and possibly other software that requires i386 compatibility. > > That said, I currently have no active FreeBSD i386 installation, and probably > won't get around to it anytime soon. > > I believe Linux can run wine on an amd64 multilib installation, but FreeBSD > is not up to that yet. > > For the above purpose, keeping drm and drm2 as a port might be good enough, > as opposed to being part of base. > > i386 is not dead. While some Linux distros (such as Arch) and DragonFlyBSD > have quit i386 support, Haiku maintains 32-bit support to be able to run old > BeOS software as well as newer things. > > Tom > > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-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"
Re: [RFC] Deprecation and removal of the drm2 driver
> Wow, this blew up quite a lot bigger than I anticipated. I'll try to > summarize the discussion a bit below and then suggest a way forward. > The primary reasons we want to do this is because there are conflicts between > the new drm drivers in ports, and the drm drivers in base, since they control > the same hardware. It is hard to make conflicting drivers to auto load in a > consistent way. In order to improve the desktop experience I'd like to see > that graphics drivers are loaded on system boot. There is also a push from > upstream to have the xf86-video* drivers stop loading driver kernel modules. > It is also easier to keep a port updated than keeping the base system updated, > and updates can propagate to multiple FreeBSD versions at once. This will > also ensure that all ports use the same firmware blobs. > So, to the summary. A lot of people are using i386, and as such still need > the old drm drivers. There were also some reports about issues with the > drm-next/stable drivers, which needs investigating. Power is another > architecture that also is not supported by drm-next/stable, although we hope > to extend support to powerpc in the future. There was a lot of discussion > regarding making it into a port, or only excluding the driver on amd64, and > similar suggestions. > To move forward, we'll do the following: Note that this is for current only. > We take the drm and drm2 drivers and make a port for it, maintained by the > graphics team (x11@). After a transition period, then the drivers are removed > from base. At the same time, pkg-messages are added to relevant places to > point people to the various available drm drivers. > Regards > Niclas Zeising > FreeBSD graphics/x11 team One reason I can think of to maintain i386 compatibility is to be able to run wine and possibly other software that requires i386 compatibility. That said, I currently have no active FreeBSD i386 installation, and probably won't get around to it anytime soon. I believe Linux can run wine on an amd64 multilib installation, but FreeBSD is not up to that yet. For the above purpose, keeping drm and drm2 as a port might be good enough, as opposed to being part of base. i386 is not dead. While some Linux distros (such as Arch) and DragonFlyBSD have quit i386 support, Haiku maintains 32-bit support to be able to run old BeOS software as well as newer things. Tom ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Tue, 29 May 2018 17:39:57 -0700 (PDT) "Rodney W. Grimes" wrote: >> Let's also remember about our handbooks and those two wiki page: >> * https://wiki.freebsd.org/Graphics >> * https://wiki.freebsd.org/Graphics/FAQ >This one has a bit rot on this claim: > "The i915kms kernel-side driver is already built into the >generic FreeBSD kernel. No need to install anything. ' > >That is slightly miss leading, it is not "built into the generic", >it is avaliable as a module, at least on 11 and 12, not sure on >10 as I dont have 10 running any place anymore. Good catch! Thanks. ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
[ Charset UTF-8 unsupported, converting... ] > On Tue, 29 May 2018 21:28:49 +0200 > Niclas Zeising wrote: > > >On 05/18/18 19:58, Niclas Zeising wrote: > >> [ Cross posted to freebsd-current@ and freebsd-x11@.? Please respect > >> reply-to and send all replies to freebsd-x11@.? Thanks! ] > >> > >> [...] > >> > >> 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? > >> > > > > > >Wow, this blew up quite a lot bigger than I anticipated. I'll try to > >summarize the discussion a bit below and then suggest a way forward. > > > > [...] > > > >To move forward, we'll do the following: Note that this is for current > >only. > >We take the drm and drm2 drivers and make a port for it, maintained by > >the graphics team (x11@). After a transition period, then the drivers > >are removed from base. At the same time, pkg-messages are added to > >relevant places to point people to the various available drm drivers. > > Let's also remember about our handbooks and those two wiki page: > * https://wiki.freebsd.org/Graphics > * https://wiki.freebsd.org/Graphics/FAQ This one has a bit rot on this claim: "The i915kms kernel-side driver is already built into the generic FreeBSD kernel. No need to install anything. ' That is slightly miss leading, it is not "built into the generic", it is avaliable as a module, at least on 11 and 12, not sure on 10 as I dont have 10 running any place anymore. -- Rod Grimes rgri...@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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Tue, 29 May 2018 21:28:49 +0200 Niclas Zeising wrote: >On 05/18/18 19:58, Niclas Zeising wrote: >> [ Cross posted to freebsd-current@ and freebsd-x11@. Please respect >> reply-to and send all replies to freebsd-x11@. Thanks! ] >> >> [...] >> >> 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? >> > > >Wow, this blew up quite a lot bigger than I anticipated. I'll try to >summarize the discussion a bit below and then suggest a way forward. > > [...] > >To move forward, we'll do the following: Note that this is for current >only. >We take the drm and drm2 drivers and make a port for it, maintained by >the graphics team (x11@). After a transition period, then the drivers >are removed from base. At the same time, pkg-messages are added to >relevant places to point people to the various available drm drivers. Let's also remember about our handbooks and those two wiki page: * https://wiki.freebsd.org/Graphics * https://wiki.freebsd.org/Graphics/FAQ ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On 05/18/18 19:58, Niclas Zeising wrote: [ Cross posted to freebsd-current@ and freebsd-x11@. Please respect reply-to and send all replies to freebsd-x11@. Thanks! ] Hi! 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? Wow, this blew up quite a lot bigger than I anticipated. I'll try to summarize the discussion a bit below and then suggest a way forward. The primary reasons we want to do this is because there are conflicts between the new drm drivers in ports, and the drm drivers in base, since they control the same hardware. It is hard to make conflicting drivers to auto load in a consistent way. In order to improve the desktop experience I'd like to see that graphics drivers are loaded on system boot. There is also a push from upstream to have the xf86-video* drivers stop loading driver kernel modules. It is also easier to keep a port updated than keeping the base system updated, and updates can propagate to multiple FreeBSD versions at once. This will also ensure that all ports use the same firmware blobs. So, to the summary. A lot of people are using i386, and as such still need the old drm drivers. There were also some reports about issues with the drm-next/stable drivers, which needs investigating. Power is another architecture that also is not supported by drm-next/stable, although we hope to extend support to powerpc in the future. There was a lot of discussion regarding making it into a port, or only excluding the driver on amd64, and similar suggestions. To move forward, we'll do the following: Note that this is for current only. We take the drm and drm2 drivers and make a port for it, maintained by the graphics team (x11@). After a transition period, then the drivers are removed from base. At the same time, pkg-messages are added to relevant places to point people to the various available drm drivers. Regards -- Niclas Zeising FreeBSD graphics/x11 team ___ 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"
Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
>Can you download the image from >https://people.freebsd.org/~emaste/mini-image.amd64.xz, uncompress and >write it to a USB stick and try on this system? This is a >MBR-partitioned dual-mode test image. It's not an installer - it >should just boot to a login prompt - but can be used to test this >scheme. I have bad news and some good news. The bad news is that with this image the USB stick doesn't get recognized as a boot device. Same as with the 11.2-BETA2 images. The good news is that if I completely recreate the MBR, keeping the layout of the partitions the same, then the USB stick is recognized. The weird news is that it then proceeds to boot from harddisk. But that may be an issue with the boot code I put on. So the issue is limited to the MBR. I'll try to figure out what exactly makes the difference. ___ 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"
Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
> On 23 May 2018 at 17:51, Philip Homburg wrote: > > I tried both FreeBSD-11.2-BETA2-amd64-bootonly.iso.xz and > > FreeBSD-11.2-BETA2-amd64-mini-memstick.img.xz on a Dell PowerEdge 2950 > > BIOS version 2.7.0. With both images, the USB stick is not recognized. > > Can you download the image from > https://people.freebsd.org/~emaste/mini-image.amd64.xz, uncompress and > write it to a USB stick and try on this system? This is a > MBR-partitioned dual-mode test image. It's not an installer - it > should just boot to a login prompt - but can be used to test this > scheme. Ed, I tested this here on my R710 that was failing to boot in Bios mode with the amd64-11.2-Beta2 disc1.iso, your mini-image boots fine in either Bios or UEFI mode on my Dell R710, so what ever you did fixed at least my one data point. -- Rod Grimes rgri...@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"
Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
On Thu, May 24, 2018 at 2:11 PM Ed Maste wrote: > On 23 May 2018 at 17:51, Philip Homburg wrote: > > I tried both FreeBSD-11.2-BETA2-amd64-bootonly.iso.xz and > > FreeBSD-11.2-BETA2-amd64-mini-memstick.img.xz on a Dell PowerEdge 2950 > > BIOS version 2.7.0. With both images, the USB stick is not recognized. > > Can you download the image from > https://people.freebsd.org/~emaste/mini-image.amd64.xz, uncompress and > write it to a USB stick and try on this system? This is a > MBR-partitioned dual-mode test image. It's not an installer - it > should just boot to a login prompt - but can be used to test this > scheme. > Tested successfully on Dell Latitude E7450 for both legacy BIOS and UEFI boot mode. ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
-- Start of PGP signed section. > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote: > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote: > > > > >Also as the Moore's law curve flattens expect the life of these > > > > >older, but not so old, machines to live quiet some time. I > > > > >believe we are talking sandy bridge and earlier? If that is > > > > >corret Sandy bridge is still a very viable system. > > > > > > > > I noticed this lack of love for older systems recently. > > > > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and RCs. > > > > > > > > Turns out, you can't install FreeBSD using a USB stick image because the > > > > BIOS only support MBR. No idea why MBR support was dropped for the USB > > > > images. > > > > > > > > In the end I had to find a CD burner, and after a couple of tries > > > > managed to > > > > install from CD. > > > > > > > > After that, my ansible playbooks started failing because > > > > /boot/loader.conf > > > > is absent if you boot from zfs in combination with MBR. > > > > > > > > Pity. This older server hardware is great for trying out new releases, > > > > play > > > > with zfs, etc. > > > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now > > > built as hybrid images, supporting both MBR and GPT, as well as being > > > written to a flash drive (like memstick.img) as well as a CD. > > > > To clarify a minor point here, are the amd64 disc1.iso images or > > both the amd64 and i386 disk1.iso images being built as "hybrid"? > > > > Only amd64. i386 does not have UEFI-/GPT-related boot issues. Here is a data point: Test system is Dell R710, First attempt is with BIOS in Boot mode: Bios Second attempt is with BIOS in Boot mode: UEFI Attemtped to boot amd64 version: Screen goes white background, text appears (yes, way indented) BTX version is 1.02 Consoles: internal video/keyboard _ That last _ is a blinking cursor, system is hung, does repsond to C-A-del Second attempt: Works properly I am going after Ed Maste's posted build image in the other thread now... > > > As this is what I see on my system: > > root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-* > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 : > > ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, > > 1472695 sectors > > FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data > > '11_2_BETA2_I386_CD' (bootable) > > > > > MBR support was initially removed from the memstick installer, as it is > > > not compatible with some UEFI implementations. (Or, at least that is my > > > understanding, based on my limited intimate knowledge of UEFI.) > > > > > Glen > -- End of PGP section, PGP failed! -- Rod Grimes rgri...@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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote: > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote: > > > >Also as the Moore's law curve flattens expect the life of these > > > >older, but not so old, machines to live quiet some time. I > > > >believe we are talking sandy bridge and earlier? If that is > > > >corret Sandy bridge is still a very viable system. > > > > > > I noticed this lack of love for older systems recently. > > > > > > I wanted to use an older Dell server to test the 11.2 BETAs and RCs. > > > > > > Turns out, you can't install FreeBSD using a USB stick image because the > > > BIOS only support MBR. No idea why MBR support was dropped for the USB > > > images. > > > > > > In the end I had to find a CD burner, and after a couple of tries managed > > > to > > > install from CD. > > > > > > After that, my ansible playbooks started failing because > > > /boot/loader.conf > > > is absent if you boot from zfs in combination with MBR. > > > > > > Pity. This older server hardware is great for trying out new releases, > > > play > > > with zfs, etc. > > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now > > built as hybrid images, supporting both MBR and GPT, as well as being > > written to a flash drive (like memstick.img) as well as a CD. > > To clarify a minor point here, are the amd64 disc1.iso images or > both the amd64 and i386 disk1.iso images being built as "hybrid"? > Only amd64. i386 does not have UEFI-/GPT-related boot issues. > As this is what I see on my system: > root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-* > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 : > ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695 > sectors > FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data > '11_2_BETA2_I386_CD' (bootable) > > > MBR support was initially removed from the memstick installer, as it is > > not compatible with some UEFI implementations. (Or, at least that is my > > understanding, based on my limited intimate knowledge of UEFI.) > > Glen signature.asc Description: PGP signature
Re: [RFC] Deprecation and removal of the drm2 driver
> On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote: > > >Also as the Moore's law curve flattens expect the life of these > > >older, but not so old, machines to live quiet some time. I > > >believe we are talking sandy bridge and earlier? If that is > > >corret Sandy bridge is still a very viable system. > > > > I noticed this lack of love for older systems recently. > > > > I wanted to use an older Dell server to test the 11.2 BETAs and RCs. > > > > Turns out, you can't install FreeBSD using a USB stick image because the > > BIOS only support MBR. No idea why MBR support was dropped for the USB > > images. > > > > In the end I had to find a CD burner, and after a couple of tries managed to > > install from CD. > > > > After that, my ansible playbooks started failing because /boot/loader.conf > > is absent if you boot from zfs in combination with MBR. > > > > Pity. This older server hardware is great for trying out new releases, play > > with zfs, etc. > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now > built as hybrid images, supporting both MBR and GPT, as well as being > written to a flash drive (like memstick.img) as well as a CD. To clarify a minor point here, are the amd64 disc1.iso images or both the amd64 and i386 disk1.iso images being built as "hybrid"? As this is what I see on my system: root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-* FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695 sectors FreeBSD-11.2-BETA2-i386-disc1.iso: ISO 9660 CD-ROM filesystem data '11_2_BETA2_I386_CD' (bootable) > MBR support was initially removed from the memstick installer, as it is > not compatible with some UEFI implementations. (Or, at least that is my > understanding, based on my limited intimate knowledge of UEFI.) > > Glen > -- Rod Grimes rgri...@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"
Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
On 23 May 2018 at 17:51, Philip Homburg wrote: > I tried both FreeBSD-11.2-BETA2-amd64-bootonly.iso.xz and > FreeBSD-11.2-BETA2-amd64-mini-memstick.img.xz on a Dell PowerEdge 2950 > BIOS version 2.7.0. With both images, the USB stick is not recognized. Can you download the image from https://people.freebsd.org/~emaste/mini-image.amd64.xz, uncompress and write it to a USB stick and try on this system? This is a MBR-partitioned dual-mode test image. It's not an installer - it should just boot to a login prompt - but can be used to test this scheme. ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On 05/24/18 08:16, M&S - Krasznai András wrote: I tried to set it to drm-stable-kmod as well as to drm-next-kmod, none was working, I got a fatal trap, kernel panic during boot. Did you build from source? Can you show the panic? drm-next-kmod should be loaded by /etc/rc.conf like this, can you try again? kld_list="/boot/modules/i915kms.ko" --HPS ___ 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"
RE: [RFC] Deprecation and removal of the drm2 driver
hi I am using a Lenovo T510 laptop with FreeBSD-CURRENT. It contains Intel I5 processor and integrated Intel graphics adapter. I tried to set it to drm-stable-kmod as well as to drm-next-kmod, none was working, I got a fatal trap, kernel panic during boot. Compiling the packages on my system did not help. The graphics adapter can be old for drm--kmod packages. Drm2 from the base works correctly on my laptop. rgds Andras Krasznai -Eredeti üzenet- Feladó: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Philip Homburg Küldve: 2018. május 23. 11:49 Címzett: Rodney W. Grimes Másolatot kap: K. Macy; A. Wilcox; FreeBSD Current Tárgy: Re: [RFC] Deprecation and removal of the drm2 driver >Also as the Moore's law curve flattens expect the life of these >older, but not so old, machines to live quiet some time. I >believe we are talking sandy bridge and earlier? If that is >corret Sandy bridge is still a very viable system. I noticed this lack of love for older systems recently. I wanted to use an older Dell server to test the 11.2 BETAs and RCs. Turns out, you can't install FreeBSD using a USB stick image because the BIOS only support MBR. No idea why MBR support was dropped for the USB images. In the end I had to find a CD burner, and after a couple of tries managed to install from CD. After that, my ansible playbooks started failing because /boot/loader.conf is absent if you boot from zfs in combination with MBR. Pity. This older server hardware is great for trying out new releases, play with zfs, etc. ___ 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"
Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
I tried both FreeBSD-11.2-BETA2-amd64-bootonly.iso.xz and FreeBSD-11.2-BETA2-amd64-mini-memstick.img.xz on a Dell PowerEdge 2950 BIOS version 2.7.0. With both images, the USB stick is not recognized. For reference I tried an image for a random other OS and in that case the USB stick is recognized. I'll try to experiment a bit to see if I can find what causes the issue. ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote: > >Also as the Moore's law curve flattens expect the life of these > >older, but not so old, machines to live quiet some time. I > >believe we are talking sandy bridge and earlier? If that is > >corret Sandy bridge is still a very viable system. > > I noticed this lack of love for older systems recently. > > I wanted to use an older Dell server to test the 11.2 BETAs and RCs. > > Turns out, you can't install FreeBSD using a USB stick image because the > BIOS only support MBR. No idea why MBR support was dropped for the USB images. > > In the end I had to find a CD burner, and after a couple of tries managed to > install from CD. > > After that, my ansible playbooks started failing because /boot/loader.conf > is absent if you boot from zfs in combination with MBR. > > Pity. This older server hardware is great for trying out new releases, play > with zfs, etc. The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now built as hybrid images, supporting both MBR and GPT, as well as being written to a flash drive (like memstick.img) as well as a CD. MBR support was initially removed from the memstick installer, as it is not compatible with some UEFI implementations. (Or, at least that is my understanding, based on my limited intimate knowledge of UEFI.) Glen signature.asc Description: PGP signature
Re: [RFC] Deprecation and removal of the drm2 driver
On 23 May 2018 at 05:48, Philip Homburg wrote: > > Turns out, you can't install FreeBSD using a USB stick image because the > BIOS only support MBR. No idea why MBR support was dropped for the USB images. We haven't "dropped" MBR support, and our amd64 memstick images are a combined hybrid format and do in general boot on legacy systems. That said, there are a number of firmware implementations that refuse to boot from the hybrid format - this has been a problem with Lenovo firmware in particular. Those of you with a system unable to boot from our MBR images, can you reply to the "Boot USB memstick with MBR" fork of this thread with details about the system and firmware version? ___ 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"
Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)
On Wed, May 23, 2018 at 12:41 PM, Philip Homburg wrote: > >It's not that hard create a mbr based usb-stick. Far easier than to find a > >CD burner. > > 'Not hard' means > - undocumented. Or at least, if you start with release notes and install > instructions you won't find it. > - Probably only works if you already have a FreeBSD system. > > And if it is indeed 'not hard', why not just generate such an image as > part > of the release build? > As someone who burn memsticks weekly and don't own a cd r/w, I agree. It seems there's no way to download an .iso or .img image that will boot from usb on legacy bios. This is bad and should be fixed. We shouldn't expect people that want to experiment with FreeBSD on non-UEFI hardware to already have a FreeBSD installation where they can prepare boot media... They shouldn't have to. File a bug report in bugzilla and try to poke the right people (I don't know who is working in this area). I guess the options are, either we make a hybrid .img that'll boot off both (maybe not that easy if it requires changes to boot assembly code) or just add a -legacy-bios.img to the image generation scripts. This is important since it's about lowering the threshold of bringing people to FreeBSD and giving a good (i.e. working) first impression. > > >I believe boot/loader.conf is something you have to create, it is not > there > >by default. > > That's not the problem. The problem is that it lives on a separate zpool > that > is lost at every reboot. > > > ___ > 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"
Re: UEFI equivalent of boot.config? (Was: Re: [RFC] Deprecation and removal of the drm2 driver)
> On 23 May 2018, at 13:29, sth...@nethelp.no wrote: > > Hijacking a thread here, > >> Turns out, you can't install FreeBSD using a USB stick image because the >> BIOS only support MBR. No idea why MBR support was dropped for the USB >> images. >> >> In the end I had to find a CD burner, and after a couple of tries managed to >> install from CD. > > On a somewhat related note - I recently installed 11.1-STABLE on a box > with support for both UEFI and "good old fashioned BIOS". I initially > used UEFI and GPT, but ended up switching to BIOS and MBR because I > needed boot.config to enable booting from an alternate partition. > > Despite lots of Googling I couldn't find a simple way to do this using > config stored on the disk itself (e.g. having "0:ad(0,f)/boot/loader" > in /boot.config) with UEFI. > > Does anybody know if this can be done using UEFI? > > Steinar Haug, Nethelp consulting, sth...@nethelp.no it can but it a bit different situation there. you can not start bios boot loader from UEFI loader or vice versa, you only can use the same platform binaries. for UEFI case, the boot1.efi does not process boot.config, so you have total 3 options - you switch boot disk in UEFI boot manager, or you use chain command to load either bootx64.efi from target disk ESP partition or you use chain command to load /boot/loader.efi from target disk freebsd root file system. You also can set currdev to point to new root, but usually you want a bit more (read in the configuration etc) so the chainload may be a bit easier. Once you have figured out the proper file name to use with chain command, you can set chain_disk to have it as value and you will have chain menu entry… like chain_disk=zfs:zroot/ROOT/default:/boot/loader.efi rgds, toomas ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
>It's not that hard create a mbr based usb-stick. Far easier than to find a >CD burner. 'Not hard' means - undocumented. Or at least, if you start with release notes and install instructions you won't find it. - Probably only works if you already have a FreeBSD system. And if it is indeed 'not hard', why not just generate such an image as part of the release build? >I believe boot/loader.conf is something you have to create, it is not there >by default. That's not the problem. The problem is that it lives on a separate zpool that is lost at every reboot. ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Wed, May 23, 2018 at 11:48 AM, Philip Homburg wrote: > >Also as the Moore's law curve flattens expect the life of these > >older, but not so old, machines to live quiet some time. I > >believe we are talking sandy bridge and earlier? If that is > >corret Sandy bridge is still a very viable system. > > I noticed this lack of love for older systems recently. > > I wanted to use an older Dell server to test the 11.2 BETAs and RCs. > > Turns out, you can't install FreeBSD using a USB stick image because the > BIOS only support MBR. No idea why MBR support was dropped for the USB > images. > It's not that hard create a mbr based usb-stick. Far easier than to find a CD burner. > > In the end I had to find a CD burner, and after a couple of tries managed > to > install from CD. > > After that, my ansible playbooks started failing because /boot/loader.conf > is absent if you boot from zfs in combination with MBR. > I believe boot/loader.conf is something you have to create, it is not there by default. > > Pity. This older server hardware is great for trying out new releases, > play > with zfs, etc. > ___ > 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"
UEFI equivalent of boot.config? (Was: Re: [RFC] Deprecation and removal of the drm2 driver)
Hijacking a thread here, > Turns out, you can't install FreeBSD using a USB stick image because the > BIOS only support MBR. No idea why MBR support was dropped for the USB images. > > In the end I had to find a CD burner, and after a couple of tries managed to > install from CD. On a somewhat related note - I recently installed 11.1-STABLE on a box with support for both UEFI and "good old fashioned BIOS". I initially used UEFI and GPT, but ended up switching to BIOS and MBR because I needed boot.config to enable booting from an alternate partition. Despite lots of Googling I couldn't find a simple way to do this using config stored on the disk itself (e.g. having "0:ad(0,f)/boot/loader" in /boot.config) with UEFI. Does anybody know if this can be done using UEFI? Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
>Also as the Moore's law curve flattens expect the life of these >older, but not so old, machines to live quiet some time. I >believe we are talking sandy bridge and earlier? If that is >corret Sandy bridge is still a very viable system. I noticed this lack of love for older systems recently. I wanted to use an older Dell server to test the 11.2 BETAs and RCs. Turns out, you can't install FreeBSD using a USB stick image because the BIOS only support MBR. No idea why MBR support was dropped for the USB images. In the end I had to find a CD burner, and after a couple of tries managed to install from CD. After that, my ansible playbooks started failing because /boot/loader.conf is absent if you boot from zfs in combination with MBR. Pity. This older server hardware is great for trying out new releases, play with zfs, etc. ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On 05/22/18 18:12, Rodney W. Grimes wrote: 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. Yes, some how we need to shake off the idea that all the world is going to be 64 bit, and stop talking about EOL for 32 bit x86, IMHO that would be a serious mistake. For one any VM that does not need >4G of address space is a waste to run in 64 bit mode. DRM2 doesn't support anything later than mid-Haswell. The chips in question all pre-date 2007. Users of low-volume hardware on chips from Um, haswell announced in 2011, started shipping in mid 2013, and last product started to ship in 2015, so if "mid-haswell" is the supported chip arrena that would be pre date 2012? Also as the Moore's law curve flattens expect the life of these older, but not so old, machines to live quiet some time. I believe we are talking sandy bridge and earlier? If that is corret Sandy bridge is still a very viable system. that period are welcome to continue to sustain themselves on the drm2 port just as the other 95+% of the user base will use what is now referred to as drm-next. Even by powerpc maintainers' admission DRM2 also only barely works there. I've promised Justin that I'll make drm-next work on Talos once POWER9 support is solid enough. I think the original RFC has been answer, yes there are people still using DRM2, and they wish to continue to use it into the 12.x time frame. Lets find a technically agreeable solution to that, and move forward. I am concerned about just disabling the compile on amd64, that typically leads to bit rot of the i386 code. I am concerned about just shoving it out to ports, as that makes it rot even faster. I am still very concerned that our in base i9xx code is like 4 years old and everyone is told to go to kmod-next from ports as well. No, I do not have a solution, but I have not tried hard to find one. I am sure if we try hard to find one it can be done. Regards, The real question in this thread is, I think: Do we want to co-version the drm kernel modules with kernel/OS releases or with the graphics drivers that use them (which are in ports)? I use the base modules (on 2014-era amd64 hardware), but would be perfectly happy with modules in ports and it seems like there is a compelling argument for co-versioning the things in x11-drivers with the kernel modules. I would like to make a proposal here: - Rename drm-next to drm-kmod - Move sys/dev/drm2 to a new port drm-kmod-legacy - Have one of the two, by default drm-kmod (amd64) or drm-kmod-legacy (i386), pulled in as a dependency by the relevant X11 drivers - Garbage-collect dev/drm, which supports 3DFX and Rage 128 and such archaic things I think this keeps the user experience intact and lets the graphics developers update in the way that works best for them. -Nathan ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Tue, May 22, 2018 at 04:32:39PM -0700, K. Macy wrote: > Why are you running i386 on that? > I'm not. Just pointing out that drm2 runs on amd64 as well as i386. Also need to correct the dis-information that drm2 only applies to mid-Haswell and older. In the end, src committers will do what they want, so this is my last post. -- Steve ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Tue, May 22, 2018 at 07:50:39AM +0100, Johannes Lundberg wrote: > On Mon, May 21, 2018 at 23:50 Steve Kargl > 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". > > > > 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_. Best for amd64. For the majority, if one starts X, it automatically loads drm2 if one allows X to configure itself and drm2 applies. It's automatically loaded on both by i386 laptop and amd64 desktop. > Let me ask you, what’s wrong with this one-liner after base install > pkg install drm2 > ? 1) The original email did not indicate the code would be moved to a port. It simply said removed. 2) Nothing wrong if you know where to go looking for drm2. FreeBSD goes from having drm2 automatically loaded for a user to hoping that a user knows about a port. 3) I've already posted a 2-line patch for amd64 (twice actually). How many lines are needed to make the port? -- Steve ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
Why are you running i386 on that? On Tue, May 22, 2018 at 4:26 PM, Steve Kargl wrote: > On Tue, May 22, 2018 at 02:56:55PM -0700, K. Macy wrote: >> > >> > >> > 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. >> >> >> DRM2 doesn't support anything later than mid-Haswell. The chips in >> question all pre-date 2007. Users of low-volume hardware on chips from >> that period are welcome to continue to sustain themselves on the drm2 >> port just as the other 95+% of the user base will use what is now >> referred to as drm-next. Even by powerpc maintainers' admission DRM2 >> also only barely works there. I've promised Justin that I'll make >> drm-next work on Talos once POWER9 support is solid enough. > > % dmesg | CPU > CPU: AMD FX(tm)-8350 Eight-Core Processor(4018.34-MHz K8-class > CPU) > % kldstat > troutmask:sgk[205] kldstat > Id Refs AddressSize Name > 91 0x8141e000 db148radeonkms.ko > 101 0x814fa000 3f7d0drm2.ko > 112 0x8153a000 acf8 agp.ko > 121 0x81545000 12f9 radeonkmsfw_CAICOS_pfp.ko > 131 0x81547000 16f7 radeonkmsfw_CAICOS_me.ko > 141 0x81549000 d73 radeonkmsfw_BTC_rlc.ko > 151 0x8154a000 5f97 radeonkmsfw_CAICOS_mc.ko > > Mid-Haswell? > > -- > Steve ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Tue, May 22, 2018 at 02:56:55PM -0700, K. Macy wrote: > > > > > > 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. > > > DRM2 doesn't support anything later than mid-Haswell. The chips in > question all pre-date 2007. Users of low-volume hardware on chips from > that period are welcome to continue to sustain themselves on the drm2 > port just as the other 95+% of the user base will use what is now > referred to as drm-next. Even by powerpc maintainers' admission DRM2 > also only barely works there. I've promised Justin that I'll make > drm-next work on Talos once POWER9 support is solid enough. % dmesg | CPU CPU: AMD FX(tm)-8350 Eight-Core Processor(4018.34-MHz K8-class CPU) % kldstat troutmask:sgk[205] kldstat Id Refs AddressSize Name 91 0x8141e000 db148radeonkms.ko 101 0x814fa000 3f7d0drm2.ko 112 0x8153a000 acf8 agp.ko 121 0x81545000 12f9 radeonkmsfw_CAICOS_pfp.ko 131 0x81547000 16f7 radeonkmsfw_CAICOS_me.ko 141 0x81549000 d73 radeonkmsfw_BTC_rlc.ko 151 0x8154a000 5f97 radeonkmsfw_CAICOS_mc.ko Mid-Haswell? -- Steve ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
> > I am concerned about just shoving it out to ports, as that makes > > it rot even faster. > > > > I am still very concerned that our in base i9xx code is like 4 > > years old and everyone is told to go to kmod-next from ports > > as well. > > > > No, I do not have a solution, but I have not tried hard to find > > one. I am sure if we try hard to find one it can be done. > > drm-next is a port and it's what most everyone will be using going > forward. You're asking us to make a special case for a small vocal > group of i386 users. If i386 is sufficiently important, its user base > can support it. Are you saying there is only one way forward? -- Rod Grimes rgri...@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"
Re: [RFC] Deprecation and removal of the drm2 driver
> I am concerned about just shoving it out to ports, as that makes > it rot even faster. > > I am still very concerned that our in base i9xx code is like 4 > years old and everyone is told to go to kmod-next from ports > as well. > > No, I do not have a solution, but I have not tried hard to find > one. I am sure if we try hard to find one it can be done. drm-next is a port and it's what most everyone will be using going forward. You're asking us to make a special case for a small vocal group of i386 users. If i386 is sufficiently important, its user base can support it. Cheers. -M ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
> > > > > > 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. Yes, some how we need to shake off the idea that all the world is going to be 64 bit, and stop talking about EOL for 32 bit x86, IMHO that would be a serious mistake. For one any VM that does not need >4G of address space is a waste to run in 64 bit mode. > DRM2 doesn't support anything later than mid-Haswell. The chips in > question all pre-date 2007. Users of low-volume hardware on chips from Um, haswell announced in 2011, started shipping in mid 2013, and last product started to ship in 2015, so if "mid-haswell" is the supported chip arrena that would be pre date 2012? Also as the Moore's law curve flattens expect the life of these older, but not so old, machines to live quiet some time. I believe we are talking sandy bridge and earlier? If that is corret Sandy bridge is still a very viable system. > that period are welcome to continue to sustain themselves on the drm2 > port just as the other 95+% of the user base will use what is now > referred to as drm-next. Even by powerpc maintainers' admission DRM2 > also only barely works there. I've promised Justin that I'll make > drm-next work on Talos once POWER9 support is solid enough. I think the original RFC has been answer, yes there are people still using DRM2, and they wish to continue to use it into the 12.x time frame. Lets find a technically agreeable solution to that, and move forward. I am concerned about just disabling the compile on amd64, that typically leads to bit rot of the i386 code. I am concerned about just shoving it out to ports, as that makes it rot even faster. I am still very concerned that our in base i9xx code is like 4 years old and everyone is told to go to kmod-next from ports as well. No, I do not have a solution, but I have not tried hard to find one. I am sure if we try hard to find one it can be done. Regards, -- Rod Grimes rgri...@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"
Re: [RFC] Deprecation and removal of the drm2 driver
> > > 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. DRM2 doesn't support anything later than mid-Haswell. The chips in question all pre-date 2007. Users of low-volume hardware on chips from that period are welcome to continue to sustain themselves on the drm2 port just as the other 95+% of the user base will use what is now referred to as drm-next. Even by powerpc maintainers' admission DRM2 also only barely works there. I've promised Justin that I'll make drm-next work on Talos once POWER9 support is solid enough. Cheers. -M ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
> 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/ signature.asc Description: OpenPGP digital signature
Re: [RFC] Deprecation and removal of the drm2 driver
On 05/22/18 13:47, dpolyg 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 r...@amd64-builder.daemonology.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-Computers/zgbs/electronics/13896591011 That is most likely a typo, or at least not as good as it should be. drm-stable-kmod and drm-next-kmod are supported on CURRENT and will be supported on FreeBSD 11.2 (it's supported in stable right now). Older releases will, however, not be supported. But they still have drm2, I will not remove any drivers from releases or from STABLE. Regards -- Niclas ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Tue, May 22, 2018 at 8:50 AM, Johannes Lundberg wrote: > On Mon, May 21, 2018 at 23:50 Steve Kargl 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-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, May 21, 2018 at 23:50 Steve Kargl 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 > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-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"
Re: [RFC] Deprecation and removal of the drm2 driver
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? -- Steve ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
> > 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. Cheers. -M ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, 21 May 2018 10:07:28 -0700 Steve Kargl wrote: > 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. > 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 ? ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, May 21, 2018 at 01:16:12PM -0700, K. Macy wrote: > On Mon, May 21, 2018 at 10:07 AM, 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 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. >> > Wasn't a strawman. Is it that difficult to use the Makefile infrastructure to exclude old drm2 on amd64? -- Steve ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, May 21, 2018 at 10:07 AM, 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 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. > Having it as a port puts the burden squarely on those using it and not on the majority who are running hardware from this decade. -M ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On 5/21/18, Oliver Pinter wrote: > On 5/21/18, Steve Kargl wrote: >> On Mon, May 21, 2018 at 10:29:54AM -0700, Pete Wright wrote: >>> >>> 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 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? >> >> Poor advocacy. I stated old drm2 can be excluded by the >> Makefile infrastructure and I've already provided a barebones >> patch. >> >> Index: sys/modules/Makefile >> === >> --- sys/modules/Makefile(revision 333609) >> +++ sys/modules/Makefile(working copy) >> @@ -112,7 +112,9 @@ >> ${_dpms} \ >> ${_dpt} \ >> ${_drm} \ >> +.if ${MACHINE_ARCH} != amd64 >> ${_drm2} \ >> +.endif >> dummynet \ >> ${_ed} \ >> ${_efirt} \ > > I prefer something like this: > > op@opn src# git diff > diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC > index 195b66daab51..034e2f8126fd 100644 > --- a/sys/amd64/conf/GENERIC > +++ b/sys/amd64/conf/GENERIC > @@ -23,6 +23,7 @@ ident GENERIC > > makeoptionsDEBUG=-g# Build kernel with gdb(1) debug > symbols > makeoptionsWITH_CTF=1 # Run ctfconvert(1) for DTrace > support > +makeoptionsWITHOUT_MODULES="drm drm2" # by default disable the > building of DRM* for GENERIC > > optionsSCHED_ULE # ULE scheduler > optionsPREEMPTION # Enable kernel thread preemption > Or make the function in this file smarter: "./hw/xfree86/os-support/bsd/bsd_kmod.c" #ifdef HAVE_XORG_CONFIG_H #include #endif #include #include #include #include #include #include "xf86_OSproc.h" /* * Load a FreeBSD kernel module. * This is used by the DRI/DRM to load a DRM kernel module when * the X server starts. It could be used for other purposes in the future. * Input: *modName - name of the kernel module (Ex: "tdfx") * Return: *0 for failure, 1 for success */ int xf86LoadKernelModule(const char *modName) { if (kldload(modName) != -1) return 1; else return 0; } > >> >> Those interested in killing old drm2 on amd64 can add the >> requisite .if ... .endif to remove obsolscent *.ko. >> >>> 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. >> >> You're talking to 1 of the 3 contributors that has tried over >> the last 2 decades to improve libm (both its quality and >> conformance to standards). The development and testing is >> done on my old i386 laptop (which happily uses drm2), my >> amd64 systems, and at one time sparc64 (flame.freebsd.org). >> So, yeah, i386 and sparc64 allowed me to dog-food my code. >> >> BTW, there are uncountable many integers. How about avoiding >> the conflict by using, say, '3' as in drm3. >> >> -- >> Steve >> > ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On 5/21/18, Steve Kargl wrote: > On Mon, May 21, 2018 at 10:29:54AM -0700, Pete Wright wrote: >> >> 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 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? > > Poor advocacy. I stated old drm2 can be excluded by the > Makefile infrastructure and I've already provided a barebones > patch. > > Index: sys/modules/Makefile > === > --- sys/modules/Makefile(revision 333609) > +++ sys/modules/Makefile(working copy) > @@ -112,7 +112,9 @@ > ${_dpms} \ > ${_dpt} \ > ${_drm} \ > +.if ${MACHINE_ARCH} != amd64 > ${_drm2} \ > +.endif > dummynet \ > ${_ed} \ > ${_efirt} \ I prefer something like this: op@opn src# git diff diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC index 195b66daab51..034e2f8126fd 100644 --- a/sys/amd64/conf/GENERIC +++ b/sys/amd64/conf/GENERIC @@ -23,6 +23,7 @@ ident GENERIC makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols makeoptionsWITH_CTF=1 # Run ctfconvert(1) for DTrace support +makeoptionsWITHOUT_MODULES="drm drm2" # by default disable the building of DRM* for GENERIC optionsSCHED_ULE # ULE scheduler optionsPREEMPTION # Enable kernel thread preemption > > Those interested in killing old drm2 on amd64 can add the > requisite .if ... .endif to remove obsolscent *.ko. > >> 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. > > You're talking to 1 of the 3 contributors that has tried over > the last 2 decades to improve libm (both its quality and > conformance to standards). The development and testing is > done on my old i386 laptop (which happily uses drm2), my > amd64 systems, and at one time sparc64 (flame.freebsd.org). > So, yeah, i386 and sparc64 allowed me to dog-food my code. > > BTW, there are uncountable many integers. How about avoiding > the conflict by using, say, '3' as in drm3. > > -- > Steve > ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, May 21, 2018 at 10:29:54AM -0700, Pete Wright wrote: > > 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 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? Poor advocacy. I stated old drm2 can be excluded by the Makefile infrastructure and I've already provided a barebones patch. Index: sys/modules/Makefile === --- sys/modules/Makefile(revision 333609) +++ sys/modules/Makefile(working copy) @@ -112,7 +112,9 @@ ${_dpms} \ ${_dpt} \ ${_drm} \ +.if ${MACHINE_ARCH} != amd64 ${_drm2} \ +.endif dummynet \ ${_ed} \ ${_efirt} \ Those interested in killing old drm2 on amd64 can add the requisite .if ... .endif to remove obsolscent *.ko. > 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. You're talking to 1 of the 3 contributors that has tried over the last 2 decades to improve libm (both its quality and conformance to standards). The development and testing is done on my old i386 laptop (which happily uses drm2), my amd64 systems, and at one time sparc64 (flame.freebsd.org). So, yeah, i386 and sparc64 allowed me to dog-food my code. BTW, there are uncountable many integers. How about avoiding the conflict by using, say, '3' as in drm3. -- Steve ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, 21 May 2018 10:29:54 -0700 "Pete Wright" 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 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* 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"
Re: [RFC] Deprecation and removal of the drm2 driver
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 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 -- 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote: > On Sun, 20 May 2018 21:10:28 +0200 > Oliver Pinter 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. -- Steve ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Sun, 20 May 2018 21:10:28 +0200 Oliver Pinter 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? ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Sunday, May 20, 2018, Niclas Zeising wrote: > On 05/20/18 18:40, Steve Kargl wrote: > >> On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh wrote: >> >>> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl < >>> s...@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 > 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: >> >> > 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? >>> >>> >> Just a data point. I had to replace the dead disk in my laptop, >> and after 2 days of doing a re-install and update of -current >> on a shiny new SSD. >> >> Before loading Xorg. >> >> % kldstat >> Id Refs AddressSize Name >> 17 0x80 1ac31d4 kernel >> 21 0x1e9ae000 5000 ums.ko >> 31 0x1e9b9000 4000 uhid.ko >> >> After starting Xorg without an xorg.conf in /etc/X11. >> >> Id Refs AddressSize Name >> 1 27 0x80 1ac31d4 kernel >> 21 0x1e9ae000 5000 ums.ko >> 31 0x1e9b9000 4000 uhid.ko >> 41 0x1eaa9000 96000i915kms.ko >> 51 0x1eb4 4a000drm2.ko >> 64 0x1eb8b000 5000 iicbus.ko >> 71 0x1ebc9000 3000 iic.ko >> 81 0x1ebcf000 4000 iicbb.ko >> >> So, drm2.ko and i915kms.ko are loaded automatically. It is >> unclear why functionality that works should be removed. >> >> xwininfo shows >> >>Width: 1400 >>Height: 1050 >>Depth: 24 >>Visual: 0x21 >> >> > 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? > -- > Niclas > ___ > 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Sun, May 20, 2018 at 06:47:07PM +0200, Niclas Zeising wrote: > On 05/20/18 18:40, Steve Kargl wrote: > > On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh wrote: > >> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl < > >>> > >>> % 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? > >> > > > > Just a data point. I had to replace the dead disk in my laptop, > > and after 2 days of doing a re-install and update of -current > > on a shiny new SSD. > > > > Before loading Xorg. > > > > % kldstat > > Id Refs AddressSize Name > > 17 0x80 1ac31d4 kernel > > 21 0x1e9ae000 5000 ums.ko > > 31 0x1e9b9000 4000 uhid.ko > > > > After starting Xorg without an xorg.conf in /etc/X11. > > > > Id Refs AddressSize Name > > 1 27 0x80 1ac31d4 kernel > > 21 0x1e9ae000 5000 ums.ko > > 31 0x1e9b9000 4000 uhid.ko > > 41 0x1eaa9000 96000i915kms.ko > > 51 0x1eb4 4a000drm2.ko > > 64 0x1eb8b000 5000 iicbus.ko > > 71 0x1ebc9000 3000 iic.ko > > 81 0x1ebcf000 4000 iicbb.ko > > > > So, drm2.ko and i915kms.ko are loaded automatically. It is > > unclear why functionality that works should be removed. > > 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 They do not collide on non-AMD64 architectures. Is is possible to do svn diff sys/modules/Makefile Index: sys/modules/Makefile === --- sys/modules/Makefile(revision 333815) +++ sys/modules/Makefile(working copy) @@ -113,7 +113,9 @@ ${_dpms} \ ${_dpt} \ ${_drm} \ +.if ${MACHINE_ARCH} != AMD64 ${_drm2} \ +.endif dummynet \ ${_ed} \ ${_efirt} \ -- Steve ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Sun, 20 May 2018 16:32:50 +0100 Johannes Lundberg wrote: > Not in the current port. > I think it should be usable in 4.15 but need some more tweaking and > updated firmware modules before we can update the port. > Active development going on here > https://github.com/FreeBSDDesktop/kms-drm/issues Thanks! What futures will avaible in 4.15 - 4.16? Video decoding acceleration? 3d acceleration? ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On 05/20/18 18:40, Steve Kargl wrote: On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh wrote: On Fri, May 18, 2018 at 1:30 PM, Steve Kargl < s...@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 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: 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? Just a data point. I had to replace the dead disk in my laptop, and after 2 days of doing a re-install and update of -current on a shiny new SSD. Before loading Xorg. % kldstat Id Refs AddressSize Name 17 0x80 1ac31d4 kernel 21 0x1e9ae000 5000 ums.ko 31 0x1e9b9000 4000 uhid.ko After starting Xorg without an xorg.conf in /etc/X11. Id Refs AddressSize Name 1 27 0x80 1ac31d4 kernel 21 0x1e9ae000 5000 ums.ko 31 0x1e9b9000 4000 uhid.ko 41 0x1eaa9000 96000i915kms.ko 51 0x1eb4 4a000drm2.ko 64 0x1eb8b000 5000 iicbus.ko 71 0x1ebc9000 3000 iic.ko 81 0x1ebcf000 4000 iicbb.ko So, drm2.ko and i915kms.ko are loaded automatically. It is unclear why functionality that works should be removed. xwininfo shows Width: 1400 Height: 1050 Depth: 24 Visual: 0x21 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 -- Niclas ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh wrote: > On Fri, May 18, 2018 at 1:30 PM, Steve Kargl < > s...@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 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: > > > > > > > > > > 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? > Just a data point. I had to replace the dead disk in my laptop, and after 2 days of doing a re-install and update of -current on a shiny new SSD. Before loading Xorg. % kldstat Id Refs AddressSize Name 17 0x80 1ac31d4 kernel 21 0x1e9ae000 5000 ums.ko 31 0x1e9b9000 4000 uhid.ko After starting Xorg without an xorg.conf in /etc/X11. Id Refs AddressSize Name 1 27 0x80 1ac31d4 kernel 21 0x1e9ae000 5000 ums.ko 31 0x1e9b9000 4000 uhid.ko 41 0x1eaa9000 96000i915kms.ko 51 0x1eb4 4a000drm2.ko 64 0x1eb8b000 5000 iicbus.ko 71 0x1ebc9000 3000 iic.ko 81 0x1ebcf000 4000 iicbb.ko So, drm2.ko and i915kms.ko are loaded automatically. It is unclear why functionality that works should be removed. xwininfo shows Width: 1400 Height: 1050 Depth: 24 Visual: 0x21 -- Steve ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Sun, May 20, 2018 at 3:22 PM, Rozhuk Ivan wrote: > On Fri, 18 May 2018 21:12:26 +0100 > Johannes Lundberg wrote: > > Is Ryzen 2200G integrated graphic supported? > > Not in the current port. I think it should be usable in 4.15 but need some more tweaking and updated firmware modules before we can update the port. Active development going on here https://github.com/FreeBSDDesktop/kms-drm/issues ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
In message <20180520155229.73447...@kalimero.tijl.coosemans.org>, Tijl Cooseman s writes: > On Fri, 18 May 2018 14:03:32 -0600 Warner Losh wrote: > > So do people use i386 for desktop? And need the latest KMS stuff? > > I use radeonkms on i386. But what about other architectures like powerpc? > > If it's getting in the way, can't it be turned into a port instead of > removing it? (All parts of FreeBSD should be available as ports imho.) Yes, I think this is the way out. First create a port while implementing a knob in base to disable drm2 build, with deprecation notice for those who choose to. After a month or two remove drm2. That should give enough time for those on -CURRENT who choose, to make the switch. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
In message , Jan Beich writes: > Slawa Olhovchenkov writes: > > > On Fri, May 18, 2018 at 07:58:10PM +0200, Niclas Zeising wrote: > > > >> [ Cross posted to freebsd-current@ and freebsd-x11@. Please respect > >> reply-to and send all replies to freebsd-x11@. Thanks! ] > >> > >> > >> Hi! > >> 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 > > > > What about old graphics card? I am have notebook w/ i945 chipset, is > > this supported by graphics/drm-*? > > > > And what about nvidia? > > (sorry, I am not developer this drivers, I am just user, I am don't > > know what need for nvidia work etc) > > NVIDIA dropped 32bit driver since 396.* series. None of x11/nvidia-driver* > currently depend on either drm.ko or drm2.ko. However, Linux driver > appears to depend on DRM/KMS since 364.12. I think that if we want to still keep i386 viable, maybe some effort needs to be put into 915resolution to help VESA look somewhat reasonable. IIRC, as it's been a long time since I've looked at this, a person will need a custom xorg.conf. However IIRC that model breaks if person switches between a laptop monitor and an external monitor. The problem is fixable however I didn't have a open evening to look at it when I did. The 915resolution option isn't exactly available to those unwilling or unable to tinker a little. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Fri, 18 May 2018 21:12:26 +0100 Johannes Lundberg wrote: Is Ryzen 2200G integrated graphic supported? ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Fri, 18 May 2018 14:03:32 -0600 Warner Losh wrote: > So do people use i386 for desktop? And need the latest KMS stuff? I use radeonkms on i386. But what about other architectures like powerpc? If it's getting in the way, can't it be turned into a port instead of removing it? (All parts of FreeBSD should be available as ports imho.) ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
20.05.2018 16:03, Johannes Lundberg пишет: > On Sun, May 20, 2018 at 1:36 PM, Boris Samorodov wrote: > >> 18.05.2018 20:58, Niclas Zeising пишет: >> >>> Is there anyone still using the drm2 driver on 12-CURRENT? If so, what >>> is preventing you from switching to the port? >> >> I use base packages and can not use port: >> https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069329.html > > If we remove drm.ko from base (which is suggested) you would be able to > install the drm-stable/next-kmod packages without conflict. Great, thanks. -- WBR, bsam ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Sun, May 20, 2018 at 1:36 PM, Boris Samorodov wrote: > 18.05.2018 20:58, Niclas Zeising пишет: > > > Is there anyone still using the drm2 driver on 12-CURRENT? If so, what > > is preventing you from switching to the port? > > I use base packages and can not use port: > https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069329.html If we remove drm.ko from base (which is suggested) you would be able to install the drm-stable/next-kmod packages without conflict. > > > -- > WBR, bsam > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-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"
Re: [RFC] Deprecation and removal of the drm2 driver
18.05.2018 20:58, Niclas Zeising пишет: > Is there anyone still using the drm2 driver on 12-CURRENT? If so, what > is preventing you from switching to the port? I use base packages and can not use port: https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069329.html -- WBR, bsam ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On 18/05/2018 20:58, Niclas Zeising wrote: > [ Cross posted to freebsd-current@ and freebsd-x11@. Please respect reply-to > and send all replies to freebsd-x11@. Thanks! ] > > > Hi! > 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? Please count me as one. > If so, what is preventing you from switching to the port? Suspend / resume does not work with my hardware: ~~ panic: implment me!! cpuid = 0 time = 1526764859 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe004d1c2280 vpanic() at vpanic+0x1a3/frame 0xfe004d1c22e0 panic() at panic+0x43/frame 0xfe004d1c2340 linux_pci_save_state() at linux_pci_save_state+0x12/frame 0xfe004d1c2350 radeon_suspend_kms() at radeon_suspend_kms+0x524/frame 0xfe004d1c23a0 linux_pci_suspend() at linux_pci_suspend+0x6e/frame 0xfe004d1c23d0 ... ~~ The hardware is old, supported by radeonkms as opposed to amdgpu, but still.. Also, last time I checked audio over HDMI did not work, but I haven't tested the latest version yet. Finally, a counter-question, does keeping the code in its current state (unsupported, but without explicitly stating so) obstruct the work on the new code? -- Andriy Gapon ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Fri, May 18, 2018 at 04:19:21PM -0400, Daniel Eischen wrote: > I can easily imagine an embedded x86 kiosk type appliance. We need to evaluate the tradeoff of "what we can imagine someone will do with FreeBSD" vs. "what are people using with FreeBSD right now." mcl ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Sat, May 19, 2018 at 08:38:20PM +0200, Jan Beich wrote: > Slawa Olhovchenkov writes: > > > On Fri, May 18, 2018 at 07:58:10PM +0200, Niclas Zeising wrote: > > > >> [ Cross posted to freebsd-current@ and freebsd-x11@. Please respect > >> reply-to and send all replies to freebsd-x11@. Thanks! ] > >> > >> > >> Hi! > >> 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 > > > > What about old graphics card? I am have notebook w/ i945 chipset, is > > this supported by graphics/drm-*? > > > > And what about nvidia? > > (sorry, I am not developer this drivers, I am just user, I am don't > > know what need for nvidia work etc) > > NVIDIA dropped 32bit driver since 396.* series. None of x11/nvidia-driver* > currently depend on either drm.ko or drm2.ko. However, Linux driver > appears to depend on DRM/KMS since 364.12. Some of my hardware supported only by nvidia 340.106. ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
Slawa Olhovchenkov writes: > On Fri, May 18, 2018 at 07:58:10PM +0200, Niclas Zeising wrote: > >> [ Cross posted to freebsd-current@ and freebsd-x11@. Please respect >> reply-to and send all replies to freebsd-x11@. Thanks! ] >> >> >> Hi! >> 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 > > What about old graphics card? I am have notebook w/ i945 chipset, is > this supported by graphics/drm-*? > > And what about nvidia? > (sorry, I am not developer this drivers, I am just user, I am don't > know what need for nvidia work etc) NVIDIA dropped 32bit driver since 396.* series. None of x11/nvidia-driver* currently depend on either drm.ko or drm2.ko. However, Linux driver appears to depend on DRM/KMS since 364.12. ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Fri, May 18, 2018 at 07:58:10PM +0200, Niclas Zeising wrote: > [ Cross posted to freebsd-current@ and freebsd-x11@. Please respect > reply-to and send all replies to freebsd-x11@. Thanks! ] > > > Hi! > 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 What about old graphics card? I am have notebook w/ i945 chipset, is this supported by graphics/drm-*? And what about nvidia? (sorry, I am not developer this drivers, I am just user, I am don't know what need for nvidia work etc) > 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? ___ 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"
Re: [RFC] Deprecation and removal of the drm2 driver
On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh wrote: > > 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? Removing drm2 remove all _graphics_ stuff. I am have i386 notebook, I am don't need lates KMS, I am need just X11/mplayer/firefox/skype. ___ 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"