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

[Adrian Chadd]

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

[Matthew Macy]

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

[Adrian Chadd]

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

[Matthew Macy]

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

[Adrian Chadd]

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: [RFC] Deprecation and removal of the drm2 driver

[Johannes Lundberg]

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 

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

[blubee blubeeme]

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: [RFC] Deprecation and removal of the drm2 driver

[Oliver Pinter]

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

[Pete Wright]

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

[Oliver Pinter]

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 

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

[Johannes Lundberg]

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

[Jeffrey Bouquet]

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 

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

[Niclas Zeising]

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

[Andriy Gapon]

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

[Ronald Klop]

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

[Joe Maloney]

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

[Daniel Eischen]

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

[Rodney W. Grimes]

> > > -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 

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

[Konstantin Belousov]

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
> > 

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

[Johannes Lundberg]

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 

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

[Hans Petter Selasky]

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)

[Ed Maste]

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)

[Philip Homburg]

>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

[O. Hartmann]

-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

Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)

[Glen Barber]

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)

[Rodney W. Grimes]

> 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)

[Ed Maste]

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

[Kevin Bowling]

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

[Thomas Mueller]

> 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

[Mateusz Piotrowski]

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

[Rodney W. Grimes]

[ 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

[Mateusz Piotrowski]

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

[Niclas Zeising]

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)

[Philip Homburg]

>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)

[Rodney W. Grimes]

> 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)

[Johannes Lundberg]

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

[Rodney W. Grimes]

-- 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

[Glen Barber]

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

[Rodney W. Grimes]

> 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)

[Ed Maste]

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

[Hans Petter Selasky]

On 05/24/18 08:16, M - 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

[M - Krasznai András]

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)

[Philip Homburg]

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

[Glen Barber]

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

[Ed Maste]

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)

[Johannes Lundberg]

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)

[Toomas Soome]

> 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

[Philip Homburg]

>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

[Andreas Nilsson]

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)

[sthaug]

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

[Philip Homburg]

>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

[Nathan Whitehorn]

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

[Steve Kargl]

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

[Steve Kargl]

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

[K. Macy]

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

[Steve Kargl]

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

[Rodney W. Grimes]

> > 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

[K. Macy]

> 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

[Rodney W. Grimes]

> >
> >
> > 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

[K. Macy]

>
>
> 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

[A. Wilcox]

> 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

[Niclas Zeising]

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

[Andreas Nilsson]

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

[Johannes Lundberg]

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

[Steve Kargl]

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

[K. Macy]

>
> 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

[Rozhuk Ivan]

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

[Steve Kargl]

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

[K. Macy]

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

[Oliver Pinter]

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

[Oliver Pinter]

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

[Steve Kargl]

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

[Chris H]

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

[Pete Wright]

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

[Steve Kargl]

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

[Rozhuk Ivan]

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

[Oliver Pinter]

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

[Steve Kargl]

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

[Rozhuk Ivan]

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

[Niclas Zeising]

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

[Steve Kargl]

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

[Johannes Lundberg]

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

[Cy Schubert]

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

[Cy Schubert]

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

[Rozhuk Ivan]

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

[Tijl Coosemans]

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

[Boris Samorodov]

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

[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.


>
>
> --
> 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

[Boris Samorodov]

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

[Andriy Gapon]

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

[Mark Linimon]

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

[Slawa Olhovchenkov]

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

[Jan Beich]

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

[Slawa Olhovchenkov]

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

[Slawa Olhovchenkov]

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"

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

[Hans Petter Selasky]

On 05/19/18 05:56, Daniel Eischen wrote:

Yes, with VESA, albeit aspect ratios are off.

I'm using drm2 with an AMD (née ATI) Radeon 4850 (RV770), AGP.  This is on an 
amd64 somewhat old -current system.  Is this supported by the drm-next-kmod 
port?


I've used drm2 in the past, but noticed the anti-flicker support 
features are not as good as in the drm-next-kmod. Also video support is 
much better, external displays and so on, not only getting video on the 
built-in display but also various kinds of VGA, HDMI and displayports.


--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

[Daniel Eischen]

> On May 18, 2018, at 6:27 PM, Cy Schubert  wrote:
> 
> In message , Daniel 
> Eischen wr
> ites:
>>> On Fri, 18 May 2018, Warner Losh wrote:
>>> 
>>> On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
>>> s...@troutmask.apl.washington.edu> 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?
>> 
>> I can easily imagine an embedded x86 kiosk type appliance.  Does
>> basic xorg stuff work without drm?
> 
> Yes, with VESA, albeit aspect ratios are off.

I'm using drm2 with an AMD (née ATI) Radeon 4850 (RV770), AGP.  This is on an 
amd64 somewhat old -current system.  Is this supported by the drm-next-kmod 
port?

--
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

[Don Lewis]

On 18 May, 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:
>> > >
>> > > The drm2 driver was the original port of a KMS driver to FreeBSD.  It
>> > > was done by Konstantin Belousov to support Intel graphics cards, and
>> > > later extended by Jean-Sébastien Pédron as well as Konstantin to match
>> > > what's in Linux 3.8.  This included unstable support from Haswell, but
>> > > nothing newer than that.
>> > >
>> > > For quite some time now we have had the graphics/drm-stable-kmod and
>> > > graphics/drm-next-kmods which provides support for modern AMD and Intel
>> > > graphics cards.  These ports, together with the linuxkpi, or lkpi, has
>> > > made it significantly easier to port and update our graphics drivers.
>> > > Further, these new drivers cover the same drivers as the old drm2
>> driver.
>> > >
>> > > What does the community think?  Is there anyone still using the drm2
>> > > driver on 12-CURRENT?  If so, what is preventing you from switching to
>> > > the port?
>> > >
>> > > Thank you
>> > > Regards
>> > > --
>> > > Niclas Zeising
>> > > FreeBSD x11/graphics team
>> > > ___
>> > > freebsd-current@freebsd.org mailing list
>> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
>> freebsd.org"
>> > >
>> >
>> > Sounds good ( deprecate resp remove ). It causes more confusion and
>> > problems and it solves nothing.
>> >
>>
>> Check the Makefiles
>>
>> % more /usr/ports/graphics/drm-next-kmod/Makefile
>>
>> ONLY_FOR_ARCHS= amd64
>> ONLY_FOR_ARCHS_REASON=  the new KMS components are only supported on amd64
>>
>> Not to ia32 friendly.
>>
> 
> So do people use i386 for desktop? And need the latest KMS stuff?

I use it on my Pentium-M laptop.  I don't need the latest KMS stuff, but
I do need X11 so that I can use a browser, vncviewer, and a few terminal
windows.  Falling back to VESA resolution would suck.  It's currently
running 11.0-STABLE. I'm planning on migrating everything over to 12.0
sometime after 12.0-RELEASE.

I have one other i386-class machine, but it only needs a text console.
Everything else here is amd64.


___
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

[Cy Schubert]

In message 
, Oliver Pinter writes:
> On Friday, May 18, 2018, Konstantin Belousov  wrote:
>
> > On Fri, May 18, 2018 at 09:33:40PM +0100, Johannes Lundberg wrote:
> > > On Fri, May 18, 2018 at 9:22 PM, Ben Widawsky  wrote:
> > >
> > > > On 18-05-18 14:15:03, Warner Losh wrote:
> > > > > On Fri, May 18, 2018 at 2:12 PM, Johannes Lundberg <
> > johal...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, May 18, 2018 at 9:03 PM, 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 <
> > zeis...@freebsd.org>
> > > > > >> wrote:
> > > > > >> > >
> > > > > >> > > > I propose that we remove the old drm2 driver (sys/dev/drm2)
> > from
> > > > > >> > > > FreeBSD.  I suggest the driver is marked as deprecated in
> > 11.x
> > > > and
> > > > > >> > > > removed from 12.0, as was done for other drivers recently.
> > Some
> > > > > >> > > > background and rationale:
> > > > > >> > > >
> > > > > >> > > > The drm2 driver was the original port of a KMS driver to
> > > > FreeBSD.
> > > > > >> It
> > > > > >> > > > was done by Konstantin Belousov to support Intel graphics
> > > > cards, and
> > > > > >> > > > later extended by Jean-S??bastien P??dron as well as
> > Konstantin to
> > > > > >> match
> > > > > >> > > > what's in Linux 3.8.  This included unstable support from
> > > > Haswell,
> > > > > >> but
> > > > > >> > > > nothing newer than that.
> > > > > >> > > >
> > > > > >> > > > For quite some time now we have had the
> > > > graphics/drm-stable-kmod and
> > > > > >> > > > graphics/drm-next-kmods which provides support for modern
> > AMD
> > > > and
> > > > > >> Intel
> > > > > >> > > > graphics cards.  These ports, together with the linuxkpi, or
> > > > lkpi,
> > > > > >> has
> > > > > >> > > > made it significantly easier to port and update our graphics
> > > > > >> drivers.
> > > > > >> > > > Further, these new drivers cover the same drivers as the old
> > > > drm2
> > > > > >> > driver.
> > > > > >> > > >
> > > > > >> > > > What does the community think?  Is there anyone still using
> > the
> > > > drm2
> > > > > >> > > > driver on 12-CURRENT?  If so, what is preventing you from
> > > > switching
> > > > > >> to
> > > > > >> > > > the port?
> > > > > >> > > >
> > > > > >> > > > Thank you
> > > > > >> > > > Regards
> > > > > >> > > > --
> > > > > >> > > > Niclas Zeising
> > > > > >> > > > FreeBSD x11/graphics team
> > > > > >> > > > ___
> > > > > >> > > > freebsd-current@freebsd.org mailing list
> > > > > >> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > > >> > > > To unsubscribe, send any mail to
> > "freebsd-current-unsubscribe@
> > > > > >> > freebsd.org"
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > > Sounds good ( deprecate resp remove ). It causes more
> > confusion
> > > > and
> > > > > >> > > problems and it solves nothing.
> > > > > >> > >
> > > > > >> >
> > > > > >> > Check the Makefiles
> > > > > >> >
> > > > > >> > % more /usr/ports/graphics/drm-next-kmod/Makefile
> > > > > >> >
> > > > > >> > ONLY_FOR_ARCHS= amd64
> > > > > >> > ONLY_FOR_ARCHS_REASON=  the new KMS components are only
> > supported on
> > > > > >> amd64
> > > > > >> >
> > > > > >> > Not to ia32 friendly.
> > > > > >> >
> > > > > >>
> > > > > >> So do people use i386 for desktop? And need the latest KMS stuff?
> > > > > >>
> > > > > >
> > > > > > Yeah I was wondering the same.. If you're running i386, do you
> > need drm
> > > > > > drivers? Will scfb work an i386? (probably has legacy bios and if I
> > > > > > remember correctly, scfb is UEFI only)
> > > > > > I do feel sorry for anyone who would have to revert back to VESA...
> > > > > >
> > > > > > Would it be too much trouble to move it to a port?
> > > > > >
> > > > >
> > > > > If there's someone who needs it for i386, and wants to do the work
> > and
> > > > > maintain it, we should allow it. But the drm2 maintainers have said
> > its
> > > > > likely totally broken anyway.
> > > > >
> > > > > Warner
> > > >
> > > > As a long time developer in drm/i915, and newly interested in FreeBSD
> > (ie.
> > > > no
> > > > history on the matter), is there some upside and/or desire to have
> > native
> > > > support, or is the drm-next-kmod solution good enough?
> > > >
> > >
> > > Given the fast evolution of graphics hardware and the amount of code in
> > > only the AMD and Intel drivers, keep several native implementations seems
> > > impossible, if not wasteful.
> > > If you are referring to drm2 in the kernel, that's not much more native
> > > than the drm kmods, it still uses a linux compatibility layer (but not 

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

[Cy Schubert]

In message , Daniel 
Eischen wr
ites:
> On Fri, 18 May 2018, Warner Losh wrote:
>
> > On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
> > s...@troutmask.apl.washington.edu> 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?
>
> I can easily imagine an embedded x86 kiosk type appliance.  Does
> basic xorg stuff work without drm?

Yes, with VESA, albeit aspect ratios are off.


-- 
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"