Re: Intel help with i915 drm-next-kmod (was: drm / drm2 removal in 12)

[Ali Abdallah]

On Wed, Sep 12, 2018 at 4:19 AM, Graham Perrin 
wrote:

> On 25/08/2018 09:32, Ali Abdallah wrote:
> > Isn't Intel supposed to be working on a native drm driver for FreeBSD?
> >
> > https://bwidawsk.net/blog/index.php/2018/06/i965-
> compiler-architecture-from-2015/
> …
>
> Not that I can see.
>
> A more recent blog post  index.php/2018/06/freebsd-work-week-2/> mentions "Help i915 drm-next-kmod
> work".
>

I saw that post already, It also mentions "Create native Intel graphics
driver."


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

Intel help with i915 drm-next-kmod (was: drm / drm2 removal in 12)

[Graham Perrin]

On 25/08/2018 09:32, Ali Abdallah wrote:
> Isn't Intel supposed to be working on a native drm driver for FreeBSD?
>
> https://bwidawsk.net/blog/index.php/2018/06/i965-compiler-architecture-from-2015/
…

Not that I can see. 

A more recent blog post 
 mentions 
"Help i915 drm-next-kmod work".

HTH

___
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: drm / drm2 removal in 12

[Dag-Erling Smørgrav]

blubee blubeeme  writes:
> You seem to miss the point where the you avoid breaking the system for
> any users not on the bleeding edge.

You seem to miss the point where nobody is interested in anything you
have to say any more.

DES
-- 
Dag-Erling Smørgrav - d...@des.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: drm / drm2 removal in 12

[Joe Maloney]

Thanks for the drm-next efforts.  I could not, and would not be using
FreeBSD without it.

Joe Maloney

On Mon, Aug 27, 2018 at 5:58 AM Thomas Mueller  wrote:

> Excerpt from Oliver Pinter:
>
> > Let's do some more step backwards, and see how the graphics driver
> > developments works from the corporation side.
> > They not bother about any of the BSDs, they focus only to Windows and
> > Linux. If you want to use a recent (haha recent, something after  2014)
> you
> > are forced to use new drivers from linux.
> > The fore/advantage on the Linux side are the zillions of corporately paid
> > kernel developers.
> > They can just focus on a new hw supports, on freebsd side, there are no
> > corporately paid drm driver developer. Sadly.
> > In linux word their internal KPI (try a Google for a "stable API
> nonsense"
> > words) moves so fastly, that porting of these drivers gets non trivial
> > without a dedicated paid team.
>
> > If you want to change on this situation, try to learn for you could help
> or
> > send directed donations to freebsd foundation. ;)
>
> Linux and FreeBSD are not the only open-source OSes.
>
> There is also (Net, Open, DragonFly)BSD, Haiku, OpenIndiana and others.
>
> Maybe better would be for the hardware manufacturers to release more
> general specifications that could be adapted to any OS, by the NetBSD
> developers, Haiku developers, etc.  Certainly not to ignore Linux.
>
> Tom
>
> ___
> freebsd-sta...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-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: drm / drm2 removal in 12

[Michelle Sullivan]

blubee blubeeme wrote:

On Sat, Aug 25, 2018 at 10:04 AM Mark Linimon  wrote:


On Sat, Aug 25, 2018 at 07:07:24AM +0800, blubee blubeeme wrote:

Are these guys insane and please avoid the nonsense about you're doing

this

in your spare time.

Let us know how whatever OS you wind up using instead works for you.
I suggest you look for one that will put up with your constant harangues.

There are very few people on the mailing lists as nasty and rude as
yourself.  It is tiresome, demotivating, and childish.  Please go
elsewhere.

mcl


Your opinion has been noted but this issue isn't about me.

It's about the Graphics devs coding themselves into a corner and looking
for an easy button so they can continue to feel good about their toy.

There's a reason the changes they tried to force down the FreeBSD source
tree was reverted; It does not meet any standards of quality.

I have no inside knowledge other than my ability to think clearly and it's
obvious that The FreeBSD team wanted to hint at them that their code
doesn't pass the sniff test.

Instead of being whiny brats improve your code and have it work without
breaking compatibility with what has been working for quite a long time.

Here's the play by play;
You guys push this mess contaminating the FreeBSD source tree, some long
standing user tries to update their machines and it blows up;
1) Most will just leave
2) Some will complain
2a) You guys will say; Read UPDATING. bleh bleh blen
They'll get aggravated, thereby aggravating people who came to this
platform for Stability.

Users who actually use FreeBSD to get things done do not time to trawl
these mailing lists, they have real world problems to solve with real world
constraints.

There are OS with kqueue and all those things it's called Linux; You can go
there and play w/ that stuff to your hearts content.

If you want your code to get merged, make sure it follows the guidelines
and not break the systems for people who are already using the platform.

Now, I understand hearing harsh criticism about your work might hurt your
feelings and all but here's the antidote;
work harder,
improve your code,
try again when your code quality improves.

You guys cannot expect people to accept these kludges in their systems that
they run everyday.

It's an open source project, you can't get mad because your code isn't
accepted, it's your jobs and engineers to do better not expect users to
jump through hoops to accommodate your subpar attempts at coding.

This isn't about me, it's about the quality of code that you guys are
trying to submit.

Not much to disagree with what you say here.. because that's why I no 
longer work on using FreeBSD instead having created my own fork which is 
something I can call stable, that can be patched for security issues and 
something that is usable across my environment.


The one thing who you should be aware of and what I do disagree with you 
over is who you are speaking to ML is a long standing 'old hat' of 
FreeBSD and someone I respect and I know would not be putting 'kludges' 
and substandard code into the trees...  Direct your anger elsewhere, 
whilst still making valid points.


Regards,

Michelle

--
Michelle Sullivan
http://www.mhix.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: drm / drm2 removal in 12

[Thomas Mueller]

Excerpt from Oliver Pinter:

> Let's do some more step backwards, and see how the graphics driver
> developments works from the corporation side.
> They not bother about any of the BSDs, they focus only to Windows and
> Linux. If you want to use a recent (haha recent, something after  2014) you
> are forced to use new drivers from linux.
> The fore/advantage on the Linux side are the zillions of corporately paid
> kernel developers.
> They can just focus on a new hw supports, on freebsd side, there are no
> corporately paid drm driver developer. Sadly.
> In linux word their internal KPI (try a Google for a "stable API nonsense"
> words) moves so fastly, that porting of these drivers gets non trivial
> without a dedicated paid team.
 
> If you want to change on this situation, try to learn for you could help or
> send directed donations to freebsd foundation. ;)

Linux and FreeBSD are not the only open-source OSes.

There is also (Net, Open, DragonFly)BSD, Haiku, OpenIndiana and others.

Maybe better would be for the hardware manufacturers to release more general 
specifications that could be adapted to any OS, by the NetBSD developers, Haiku 
developers, etc.  Certainly not to ignore Linux.

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: drm / drm2 removal in 12

[Matthew Macy]

Please just stop responding to this person or we're going to have to
migrate to moderated lists. You're legitimizing the voice of one
person who project members have spend hours of their time (some even
in person) trying to explain the time tradeoffs of supporting
graphics. For some reason he isn't capable of understanding the
technical issues and he isn't capable of constructively engaging the
project.

Thank you for your understanding.
-M



On Sun, Aug 26, 2018 at 3:33 PM Larry Rosenman  wrote:
>
> On Mon, Aug 27, 2018 at 06:21:57AM +0800, blubee blubeeme wrote:
> >
> > You seem to miss the point where the you avoid breaking the system for any
> > users not on the bleeding edge.
> >
> > You technically adept guys can keep on hacking away, jumping through hoops
> > and building your stuff as you see fit.
> > Nobody will come take your steal your code away in the night. Feel free to
> > keep on working on it, until implementing it
> > doesn't break "old users" do the engineering work and improve your
> > implementation.
> >
> > There are so many seemingly dead code projects around this linuxkpi stuff
> > that you guys just pump out code and abandon
> > inconsistent lack of documentation, lack of testing, it's just a huge mess.
> >
> > Work on cleaning all that stuff up and bring something sensible to the
> > table, you cannot put onus on the core team to maintain
> > that mess going forward because you're not capable of doing it yourselves.
>
> If you don't like breakage, don't run HEAD/-CURRENT.  If it's not out in
> HEAD/-CURRENT, we (the project, speaking as a ports committer) can't
> move forward.
>
>
> --
> Larry Rosenman https://people.FreeBSD.org/~ler/
> Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
> US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106
___
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: drm / drm2 removal in 12

[Larry Rosenman]

On Mon, Aug 27, 2018 at 06:21:57AM +0800, blubee blubeeme wrote:
> 
> You seem to miss the point where the you avoid breaking the system for any
> users not on the bleeding edge.
> 
> You technically adept guys can keep on hacking away, jumping through hoops
> and building your stuff as you see fit.
> Nobody will come take your steal your code away in the night. Feel free to
> keep on working on it, until implementing it
> doesn't break "old users" do the engineering work and improve your
> implementation.
> 
> There are so many seemingly dead code projects around this linuxkpi stuff
> that you guys just pump out code and abandon
> inconsistent lack of documentation, lack of testing, it's just a huge mess.
> 
> Work on cleaning all that stuff up and bring something sensible to the
> table, you cannot put onus on the core team to maintain
> that mess going forward because you're not capable of doing it yourselves.

If you don't like breakage, don't run HEAD/-CURRENT.  If it's not out in
HEAD/-CURRENT, we (the project, speaking as a ports committer) can't
move forward.  


-- 
Larry Rosenman https://people.FreeBSD.org/~ler/
Phone: +1 214-642-9640 E-Mail: l...@freebsd.org
US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106


signature.asc
Description: PGP signature

Re: drm / drm2 removal in 12

[blubee blubeeme]

On Mon, Aug 27, 2018 at 2:39 AM Dag-Erling Smørgrav  wrote:

> blubee blubeeme  writes:
> > Hans Petter Selasky  writes:
> > > Are you here to try to stir a conflict?  If so that is not
> > > appreciated.
> > Hans, you of all people should know that's not true.
>
> And yet here we are.
>
> You have made it perfectly clear that you are not interested in an
> honest discussion.  Your entire strategy is to wear people down until
> they either leave or agree with you just to shut you up.  Like Hans
> Petter says, it is not appreciated.
>
> You clearly believe that you know better than anyone else how this
> should be handled, so instead of telling us, I suggest you just go do
> it.  It only takes seconds to fork the FreeBSD mirror on Github, and a
> few minutes to clone it onto your machine.  We look forward to hearing
> from you again when you have everything working perfectly and seamlessly
> out of the box for everybody on any equipment.  I'm sure that Johannes,
> Niclas, Warner and others with a century of combined experience will be
> thrilled to see you succeed where they, by your account, have failed.
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no


You seem to miss the point where the you avoid breaking the system for any
users not on the bleeding edge.

You technically adept guys can keep on hacking away, jumping through hoops
and building your stuff as you see fit.
Nobody will come take your steal your code away in the night. Feel free to
keep on working on it, until implementing it
doesn't break "old users" do the engineering work and improve your
implementation.

There are so many seemingly dead code projects around this linuxkpi stuff
that you guys just pump out code and abandon
inconsistent lack of documentation, lack of testing, it's just a huge mess.

Work on cleaning all that stuff up and bring something sensible to the
table, you cannot put onus on the core team to maintain
that mess going forward because you're not capable of doing it yourselves.
___
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: drm / drm2 removal in 12

[Dag-Erling Smørgrav]

blubee blubeeme  writes:
> Hans Petter Selasky  writes:
> > Are you here to try to stir a conflict?  If so that is not
> > appreciated.
> Hans, you of all people should know that's not true.

And yet here we are.

You have made it perfectly clear that you are not interested in an
honest discussion.  Your entire strategy is to wear people down until
they either leave or agree with you just to shut you up.  Like Hans
Petter says, it is not appreciated.

You clearly believe that you know better than anyone else how this
should be handled, so instead of telling us, I suggest you just go do
it.  It only takes seconds to fork the FreeBSD mirror on Github, and a
few minutes to clone it onto your machine.  We look forward to hearing
from you again when you have everything working perfectly and seamlessly
out of the box for everybody on any equipment.  I'm sure that Johannes,
Niclas, Warner and others with a century of combined experience will be
thrilled to see you succeed where they, by your account, have failed.

DES
-- 
Dag-Erling Smørgrav - d...@des.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: drm / drm2 removal in 12

[Warner Losh]

For those wondering at what's going on with this, I've shared the following
with the developers@ mailing list. I thought I'd share it here to fight the
misinformation that's swirling about. We don't have all the answers yet,
and I'm working on it with others in the community to get the best outcome
possible. We have to look at all the options and consider all the angles
because this is a complicated and nuanced problems and 'simple' solutions
are apt to create more problems than they solve.


> https://reviews.freebsd.org/D16894 is the next step. I plan on committing
> it later today or tomorrow barring big issues with it (it's already been
> approved by members of the graphics working community and a member of
> release engineering).
>
> It puts a big ugly deprecation notice and makes the drm modules dependent
> on a build option.
>
> But it's not the last step.
>
> The only real issue we have is that we have two modules name the same:
> i915kms.ko and radeonkmw.ko. There's also drm.ko, but versioning seems to
> save us from that being an issue with the latest kernel and maybe loader (I
> need to test that last detail, and fix what I think might be an issue
> there).
>
> There's multiple ways you can fix this. One would be to turn off the build
> on amd64 of these modules. This breaks old users, but not in a horrible way
> (they can just turn it on and rebuild, or possibly install the port).
> Second would be to fix the boot loader to have per-module paths (or rather
> put the kernel path last) as well as doing similar hacks to the kernel
> loader. This is fragile, but seems to have some promise. We can't just
> change the module path for all modules at this late date, however. So this
> solution, if it were working perfectly, could remove all POLA, but we risk
> breaking other things. Third, there's been suggestion of having different
> module dependencies such that you'd get the right driver no matter whether
> or not you have the port installed, though I've not had a chance to see if
> the kernel module version code might be able to load the right module
> always, but we'd also need to change the boot loader since I don't think
> the right logic is there.
>
> Finding the right solution is a bit tricky because there's so many
> different scenarios to consider and test. The immediate next step is being
> investigated to find the best path forward in a thoughtful, methodical way.
> If you'd like to help, please contact me privately. I'm not sure a
> discussion on developers would be fruitful: I'm providing detail here in
> the interests of transparency, not because I'm looking for help, per se.
> Before I do a next step, I'll circulate my preliminary conclusion along
> with a write up for each of these possible solutions outlining the pros and
> cons of each so we have it well documented for future reference.
>
> Longer term, after the freeze, the plan is to remove all the drm drivers,
> the drm code and the drm module. We'll also remove the drm2 module builds,
> intel and radeon drivers and firmware. We'll likely move what's left of
> sys/dev/drm2 to sys/arm/dev/drm2 and hack the *files* files for it to build
> in the new place (I have a review in phab to do this, the effort is almost
> trivial). Arm is hard to share linux graphics drivers with, as documented
> in https://gist.github.com/strejda/c98e513c2ec1d2e23005bb66a7bc6399, so
> for the moment we need to stay with drm2 base for its graphics drivers.
> That will develop independently of the other platforms, which can share
> either drm-stable-kmod, drm-devel-kmod or drm-legacy-kmod ports at the path
> forward. These details are in draft form, but are not likely to change a
> huge amount. All the people / groups involved that I've spoken with are
> on-board for this long-term plan.
>
> Also longer term, there's many social issues we need to solve. But I don't
> want to derail getting the technical things done with them at the moment
> playing the blame game. Suffice to say, after looking at things in detail,
> I believe everybody from core on down to individual developers deserves
> some blame for how we got here, and hyperbolic narratives that paint one
> person or faction as evil are not only wrong, they are also part of the
> problem. I promise I'll write up something with more specific detail once
> we're through the technical phase of the drm work.
>

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

drm / drm2 removal in 12

[Oliver Pinter]

On Sunday, August 26, 2018, blubee blubeeme  wrote:

> On Sun, Aug 26, 2018 at 4:32 PM Hans Petter Selasky 
> wrote:
>
> > On 8/26/18 3:20 AM, blubee blubeeme wrote:
> > > Have you or anyone working on this drm-legacy-kmod stuff done any
> > testings
> > > of how this will affect current users?
> >
> > Hi Blubee,
> >
> > Are you here to try to stir a conflict?
> > If so that is not appreciated.
> >
> > --HPS
> >
> Hans, you of all people should know that's not true.
>
> I would think that trying to sneak in code during a code freeze that would
> break the release. Forcing the core devs to revert those changes and having
> to dust off old policies to try to keep you guys in check is what's
> stirring up conflicts, but hey; what do I know?


Please use git pull or svn up. They are already reverted and you get back
your old drivers.

https://github.com/freebsd/freebsd/commit/ae526637c4a79045579abc632ffbfd
b368c66ea8#diff-6ee1ee279be0fe8a84e853198b2b4c43

Please try to learn how to use development tools.

https://github.com/freebsd/freebsd/commits/master/sys/dev/drm2

I think the latest binary snapshot from 12.0-ALPHA3 contains the old state
of code if not, next should be.


> It's really sad state when capable engineers are so obsessed with something
> that they cannot see the forest for the trees. Try to step away from the
> canvas and look at the big picture.


Let's do some more step backwards, and see how the graphics driver
developments works from the corporation side.
They not bother about any of the BSDs, they focus only to Windows and
Linux. If you want to use a recent (haha recent, something after  2014) you
are forced to use new drivers from linux.
The fore/advantage on the Linux side are the zillions of corporately paid
kernel developers.
They can just focus on a new hw supports, on freebsd side, there are no
corporately paid drm driver developer. Sadly.
In linux word their internal KPI (try a Google for a "stable API nonsense"
words) moves so fastly, that porting of these drivers gets non trivial
without a dedicated paid team.

If you want to change on this situation, try to learn for you could help or
send directed donations to freebsd foundation. ;)


>
> If you don't mind me asking, Hans care to answer these questions below?
> 1) Take a [test] system with the current graphics stack installed and
> working.
> 2) Apply your patches to remove the drm from base to create a port
> 3) update the working [test] system after applying your changes
>
>
With the latest 12, nothing special. Only a deprecation notice gets
printed, once the driver is loaded.


> How does your changes affect a [test] system that is already up and
> running?
>
> Have any of you guys tried that? Do you have any documentation on how it'll
> affect users.
>
> You guys want to remove things from the current system but you come with;
> it works for us hobbyists.
> Where do users go to get steps to do all of this stuff?
>
> You've repeatedly said what you want to do sure, but have you tested it?
> ___
> 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: drm / drm2 removal in 12

[Erik Cederstrand]

> Cheerleading does not solve engineering problems, it's just noise.
> 
> I'll post this again to keep the focus on the issue at hand.
> 
> If The Graphics team has already done these tests, show us.
> If The Graphics team has not, then maybe they should take some time to do
> the work required get the code submitted upstream.

Over the 15 odd years following this list, I've had to killfile only three 
people. But your hostility and complete lack of understanding that nobody owes 
you anything is unbearable. I'll make it four now. Goodbye.

Erik


signature.asc
Description: Message signed with OpenPGP

Re: drm / drm2 removal in 12

[blubee blubeeme]

On Sun, Aug 26, 2018 at 4:32 PM Hans Petter Selasky  wrote:

> On 8/26/18 3:20 AM, blubee blubeeme wrote:
> > Have you or anyone working on this drm-legacy-kmod stuff done any
> testings
> > of how this will affect current users?
>
> Hi Blubee,
>
> Are you here to try to stir a conflict?
> If so that is not appreciated.
>
> --HPS
>
Hans, you of all people should know that's not true.

I would think that trying to sneak in code during a code freeze that would
break the release. Forcing the core devs to revert those changes and having
to dust off old policies to try to keep you guys in check is what's
stirring up conflicts, but hey; what do I know?

It's really sad state when capable engineers are so obsessed with something
that they cannot see the forest for the trees. Try to step away from the
canvas and look at the big picture.

If you don't mind me asking, Hans care to answer these questions below?
1) Take a [test] system with the current graphics stack installed and
working.
2) Apply your patches to remove the drm from base to create a port
3) update the working [test] system after applying your changes

How does your changes affect a [test] system that is already up and running?

Have any of you guys tried that? Do you have any documentation on how it'll
affect users.

You guys want to remove things from the current system but you come with;
it works for us hobbyists.
Where do users go to get steps to do all of this stuff?

You've repeatedly said what you want to do sure, but have you tested it?
___
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: drm / drm2 removal in 12

[Hans Petter Selasky]

On 8/26/18 3:20 AM, blubee blubeeme wrote:

Have you or anyone working on this drm-legacy-kmod stuff done any testings
of how this will affect current users?


Hi Blubee,

Are you here to try to stir a conflict?
If so that is not appreciated.

--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: drm / drm2 removal in 12

[blubee blubeeme]

On Sun, Aug 26, 2018 at 10:51 AM cpghost  wrote:

> On 8/25/18 5:34 PM, Dave Cottlehuber wrote:
> >> On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen <
> sh+freebsd-curr...@codevoid.de>
>  On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote:
> > I've been personally using the new DRM bits since almost day one. I
> > haven't found it to be unstable in the slightest. Compared to not
> > having it and being forced to run 5+ year old hardware, it's been a
> > huge blessing for those of us who care about running FreeBSD as a
> > modern desktop / laptop.
> >
> > Ditto. I'd like to express my heartfelt thanks for all the people who
> have been
> > working on the drm-next code for over 2 years now. It's fantastic and an
> > incredible piece of effort to pull it all together.
>
> Same here. A big THANK YOU to the Graphics Team for drm-next.
> I've been running it on STABLE with amdgpu driver on an RX 580
> at 4K res, and had ZERO issues with it so far... except for broken
> opencl on drm-stable-kmod, but I can live with that until its fixed.
>
> > A+++
> > Dave
>
> -cpghost.
>
>
>
> There's a whole lot of cheerleading and that's wonderful keep it up. Enjoy
building and applying your patches no one will take that away from you guys.

Although the way you guys continually dodge, deflect and run away from 3
simple questions is astonishing, see below.

You guys can keep on cheerleading but that still doesn't answer the
questions that I have asked numerous time.

Cheerleading does not solve engineering problems, it's just noise.

I'll post this again to keep the focus on the issue at hand.

If The Graphics team has already done these tests, show us.
If The Graphics team has not, then maybe they should take some time to do
the work required get the code submitted upstream.


===
1) Take a [test] system with the current graphics stack installed and
working.
2) Apply your patches to remove the drm from base to create a port
3) update the working [test] system after applying your changes

How does your changes affect a [test] system that is already up and running?

Have any of you guys tried that? Do you have any documentation on how it'll
affect users.

You guys want to remove things from the current system but you come with;
it works for us hobbyists.
Where do users go to get steps to do all of this stuff?

You've repeatedly said what you want to do sure, but have you tested it?
___
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: drm / drm2 removal in 12

[cpghost]

On 8/25/18 5:34 PM, Dave Cottlehuber wrote:
>> On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen 
 On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote:
> I've been personally using the new DRM bits since almost day one. I
> haven't found it to be unstable in the slightest. Compared to not
> having it and being forced to run 5+ year old hardware, it's been a
> huge blessing for those of us who care about running FreeBSD as a
> modern desktop / laptop.
> 
> Ditto. I'd like to express my heartfelt thanks for all the people who have 
> been
> working on the drm-next code for over 2 years now. It's fantastic and an
> incredible piece of effort to pull it all together.

Same here. A big THANK YOU to the Graphics Team for drm-next.
I've been running it on STABLE with amdgpu driver on an RX 580
at 4K res, and had ZERO issues with it so far... except for broken
opencl on drm-stable-kmod, but I can live with that until its fixed.

> A+++
> Dave

-cpghost.





smime.p7s
Description: S/MIME Cryptographic Signature

Re: drm / drm2 removal in 12

[Mark Linimon]

On Sat, Aug 25, 2018 at 07:22:06PM -0700, Randy Bush wrote:
> plonk

Indeed.  I encourage everyone else to do the same.

I'm far too old for proof-by-repetition.

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: drm / drm2 removal in 12

[blubee blubeeme]

On Sun, Aug 26, 2018 at 10:05 AM Allan Jude  wrote:

> On 2018-08-25 21:20, blubee blubeeme wrote:
> > On Sun, Aug 26, 2018 at 9:08 AM Paul McNary  wrote:
> >
> >> I think you can pay XinuOS to support FreeBSD in a LTS situation.
> >> It is just like linux where you have to pay Red Hat, Suse, etc.
> >> They break things even with point releases. Suse majorly
> >> screwed with video drivers back in the 9.x series. Totally
> >> broke major release. Their answer then was pay us or
> >> re-install bare metal and figure it out on your own.
> >> Other wise linux has always been, you get what you get for free.
> >> BSD is the same. If you are lucky some one like red hat, suse, XinuOS
> >> will be supporting and make their notes public, otherwise the
> >> OSS model doesn't include anything more than community support
> >> for what ever that is worth.
> >> I just upgraded a system from FreeBSD 9.x to 12.x, it took 2 weeks and
> >> several incremental upgrades sometimes to multiple point releases
> >> with in a major release. There is nothing really for free.
> >>
> >>
> >> On 8/25/2018 7:47 PM, blubee blubeeme wrote:
> >>> On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg 
> >>> wrote:
> >>>
> 
>  On Sun, Aug 26, 2018 at 00:25 blubee blubeeme 
> >> wrote:
> 
> > On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav 
> >> wrote:
> >
> >> blubee blubeeme  writes:
> >>> True on both points my tone is just a reflection of attitudes of
> the
> >>> individuals that I am currently addressing.
> >> Well, congratulations on alienating absolutely everybody you have
> >> interacted with on this topic.
> >>
> >>> Some people enjoy making contributions w/o waving a banner
> constantly
> >>> wanting acknowledgement, a pat on the head and good job from
> >> everyone.
> >> The only person I see constantly craving attention and validation
> from
> >> others here is you.
> >>
> >>> How far will core FreeBSD bend over backwards to accommodate these
> >>> devs.
> >> The core team does not decide what goes into the tree or not.  The
> >> developers do.
> >>
> >>> This is the beauty of an open source project, we bring the best to
> >> the
> >>> table, [...]
> >> Who exactly is “we” here?  You are not a member of the project, you
> do
> >> not speak for the project, and after seeing how you treat our fellow
> >> developers, our friends, most of us want nothing to do with you.  If
> >> can't live with that, I'm sure you can figure out how to install
> >> Linux.
> >>
> >> DES
> >> --
> >> Dag-Erling Smørgrav - d...@des.no
> >
> > Some on here want to attack my personality because they think that I
> am
> > abrasive, fine but that's not the issue.
> >
> > Some claim that they run the code and it works wonderful for them
> with
> >> no
> > issues, again that's lovely keep on running the code.
> >
> >   Nevertheless let me restate the point that you guys are all seeming
> >> to
> > miss; If you can go out and build custom kernels with custom options
> >> and
> > out of mainline tree that's fine, keep doing that until you have
> >> something
> > that's production ready and as easy to install as the rest of FreeBSD
> > system.
> >
> > The graphics stack on FreeBSD is pretty bad as it stands but all the
> > documentation currently out there is about using it as it stands now.
> >
> > Why do you need to rip out the current graphics drivers which will
> >> break
> > systems for the vast majority of silent users who will not complain
> and
> > just leave?
> >
> >  A little background 
> > Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never
> update
> > their phones to the latest android version?
> >
> > It's because the Linux kernel is such a mess they know it's a waste
> of
> > resources to try. You should not have to ask how or why I know this
> >> but if
> > it's unclear I was in the field.
> > ---
> >
> > Now you guys who claim to only be hobbyist doing this in their free
> >> time
> > expect to maintain this when those companies with all their resources
> > cannot?
> >
> > Those 30,000 ports many of them bring bugs with them because of this
> > Linuxkpi stuff. Just recently there was a user who said google earth
> > doesn't work the answer was it doesn't work and that's that.
> >
> > They get ported and then get dropped so while the ports tree is
> large,
> >> if
> > you actually try to use some of those programs they are broken,
> > maintenance
> > hell for the developers and confusion for the users.
> >
> > Johannes Lundberg I know that you are one of the main working on this
> > linuxkpi stuff but anyone else is free to answer as well.
> >
> > Let's have an open discussion why do you 

Re: drm / drm2 removal in 12

[Randy Bush]

> I'll just post this again to try and keep the focus on the issue at hand.

plonk
___
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: drm / drm2 removal in 12

[Paul McNary]

I think you can pay XinuOS to support FreeBSD in a LTS situation.
It is just like linux where you have to pay Red Hat, Suse, etc.
They break things even with point releases. Suse majorly
screwed with video drivers back in the 9.x series. Totally
broke major release. Their answer then was pay us or
re-install bare metal and figure it out on your own.
Other wise linux has always been, you get what you get for free.
BSD is the same. If you are lucky some one like red hat, suse, XinuOS
will be supporting and make their notes public, otherwise the
OSS model doesn't include anything more than community support
for what ever that is worth.
I just upgraded a system from FreeBSD 9.x to 12.x, it took 2 weeks and
several incremental upgrades sometimes to multiple point releases
with in a major release. There is nothing really for free.


On 8/25/2018 7:47 PM, blubee blubeeme wrote:

On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg 
wrote:



On Sun, Aug 26, 2018 at 00:25 blubee blubeeme  wrote:


On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav  wrote:


blubee blubeeme  writes:

True on both points my tone is just a reflection of attitudes of the
individuals that I am currently addressing.

Well, congratulations on alienating absolutely everybody you have
interacted with on this topic.


Some people enjoy making contributions w/o waving a banner constantly
wanting acknowledgement, a pat on the head and good job from everyone.

The only person I see constantly craving attention and validation from
others here is you.


How far will core FreeBSD bend over backwards to accommodate these
devs.

The core team does not decide what goes into the tree or not.  The
developers do.


This is the beauty of an open source project, we bring the best to the
table, [...]

Who exactly is “we” here?  You are not a member of the project, you do
not speak for the project, and after seeing how you treat our fellow
developers, our friends, most of us want nothing to do with you.  If
can't live with that, I'm sure you can figure out how to install Linux.

DES
--
Dag-Erling Smørgrav - d...@des.no


Some on here want to attack my personality because they think that I am
abrasive, fine but that's not the issue.

Some claim that they run the code and it works wonderful for them with no
issues, again that's lovely keep on running the code.

  Nevertheless let me restate the point that you guys are all seeming to
miss; If you can go out and build custom kernels with custom options and
out of mainline tree that's fine, keep doing that until you have something
that's production ready and as easy to install as the rest of FreeBSD
system.

The graphics stack on FreeBSD is pretty bad as it stands but all the
documentation currently out there is about using it as it stands now.

Why do you need to rip out the current graphics drivers which will break
systems for the vast majority of silent users who will not complain and
just leave?

 A little background 
Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update
their phones to the latest android version?

It's because the Linux kernel is such a mess they know it's a waste of
resources to try. You should not have to ask how or why I know this but if
it's unclear I was in the field.
---

Now you guys who claim to only be hobbyist doing this in their free time
expect to maintain this when those companies with all their resources
cannot?

Those 30,000 ports many of them bring bugs with them because of this
Linuxkpi stuff. Just recently there was a user who said google earth
doesn't work the answer was it doesn't work and that's that.

They get ported and then get dropped so while the ports tree is large, if
you actually try to use some of those programs they are broken,
maintenance
hell for the developers and confusion for the users.

Johannes Lundberg I know that you are one of the main working on this
linuxkpi stuff but anyone else is free to answer as well.

Let's have an open discussion why do you need to remove the current
graphics stack to continue with your work?


This has been discussed over and over on the mailing list and I don’t
think anyone wants to do it over again so please feel free to search the
archives.

You’re misinformed. We are not removing anything for anyone. We are moving
it to ports.
“pkg install drm-legacy-kmod” will install those drivers for you that were
earlier in base. I thought we have been clear about this but maybe we
haven’t been clear enough.




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


Have you or anyone working on this drm-legacy-kmod stuff done any testings

of how this will affect current users?

1) Take a [test] system with the current graphics stack installed and
working.
2) Apply your patches to remove the drm from base 

Re: drm / drm2 removal in 12

[Allan Jude]

On 2018-08-25 21:20, blubee blubeeme wrote:
> On Sun, Aug 26, 2018 at 9:08 AM Paul McNary  wrote:
> 
>> I think you can pay XinuOS to support FreeBSD in a LTS situation.
>> It is just like linux where you have to pay Red Hat, Suse, etc.
>> They break things even with point releases. Suse majorly
>> screwed with video drivers back in the 9.x series. Totally
>> broke major release. Their answer then was pay us or
>> re-install bare metal and figure it out on your own.
>> Other wise linux has always been, you get what you get for free.
>> BSD is the same. If you are lucky some one like red hat, suse, XinuOS
>> will be supporting and make their notes public, otherwise the
>> OSS model doesn't include anything more than community support
>> for what ever that is worth.
>> I just upgraded a system from FreeBSD 9.x to 12.x, it took 2 weeks and
>> several incremental upgrades sometimes to multiple point releases
>> with in a major release. There is nothing really for free.
>>
>>
>> On 8/25/2018 7:47 PM, blubee blubeeme wrote:
>>> On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg 
>>> wrote:
>>>

 On Sun, Aug 26, 2018 at 00:25 blubee blubeeme 
>> wrote:

> On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav 
>> wrote:
>
>> blubee blubeeme  writes:
>>> True on both points my tone is just a reflection of attitudes of the
>>> individuals that I am currently addressing.
>> Well, congratulations on alienating absolutely everybody you have
>> interacted with on this topic.
>>
>>> Some people enjoy making contributions w/o waving a banner constantly
>>> wanting acknowledgement, a pat on the head and good job from
>> everyone.
>> The only person I see constantly craving attention and validation from
>> others here is you.
>>
>>> How far will core FreeBSD bend over backwards to accommodate these
>>> devs.
>> The core team does not decide what goes into the tree or not.  The
>> developers do.
>>
>>> This is the beauty of an open source project, we bring the best to
>> the
>>> table, [...]
>> Who exactly is “we” here?  You are not a member of the project, you do
>> not speak for the project, and after seeing how you treat our fellow
>> developers, our friends, most of us want nothing to do with you.  If
>> can't live with that, I'm sure you can figure out how to install
>> Linux.
>>
>> DES
>> --
>> Dag-Erling Smørgrav - d...@des.no
>
> Some on here want to attack my personality because they think that I am
> abrasive, fine but that's not the issue.
>
> Some claim that they run the code and it works wonderful for them with
>> no
> issues, again that's lovely keep on running the code.
>
>   Nevertheless let me restate the point that you guys are all seeming
>> to
> miss; If you can go out and build custom kernels with custom options
>> and
> out of mainline tree that's fine, keep doing that until you have
>> something
> that's production ready and as easy to install as the rest of FreeBSD
> system.
>
> The graphics stack on FreeBSD is pretty bad as it stands but all the
> documentation currently out there is about using it as it stands now.
>
> Why do you need to rip out the current graphics drivers which will
>> break
> systems for the vast majority of silent users who will not complain and
> just leave?
>
>  A little background 
> Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update
> their phones to the latest android version?
>
> It's because the Linux kernel is such a mess they know it's a waste of
> resources to try. You should not have to ask how or why I know this
>> but if
> it's unclear I was in the field.
> ---
>
> Now you guys who claim to only be hobbyist doing this in their free
>> time
> expect to maintain this when those companies with all their resources
> cannot?
>
> Those 30,000 ports many of them bring bugs with them because of this
> Linuxkpi stuff. Just recently there was a user who said google earth
> doesn't work the answer was it doesn't work and that's that.
>
> They get ported and then get dropped so while the ports tree is large,
>> if
> you actually try to use some of those programs they are broken,
> maintenance
> hell for the developers and confusion for the users.
>
> Johannes Lundberg I know that you are one of the main working on this
> linuxkpi stuff but anyone else is free to answer as well.
>
> Let's have an open discussion why do you need to remove the current
> graphics stack to continue with your work?

 This has been discussed over and over on the mailing list and I don’t
 think anyone wants to do it over again so please feel free to search the
 archives.

 You’re misinformed. We are not removing 

Re: drm / drm2 removal in 12

[blubee blubeeme]

On Sun, Aug 26, 2018 at 9:08 AM Paul McNary  wrote:

> I think you can pay XinuOS to support FreeBSD in a LTS situation.
> It is just like linux where you have to pay Red Hat, Suse, etc.
> They break things even with point releases. Suse majorly
> screwed with video drivers back in the 9.x series. Totally
> broke major release. Their answer then was pay us or
> re-install bare metal and figure it out on your own.
> Other wise linux has always been, you get what you get for free.
> BSD is the same. If you are lucky some one like red hat, suse, XinuOS
> will be supporting and make their notes public, otherwise the
> OSS model doesn't include anything more than community support
> for what ever that is worth.
> I just upgraded a system from FreeBSD 9.x to 12.x, it took 2 weeks and
> several incremental upgrades sometimes to multiple point releases
> with in a major release. There is nothing really for free.
>
>
> On 8/25/2018 7:47 PM, blubee blubeeme wrote:
> > On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg 
> > wrote:
> >
> >>
> >> On Sun, Aug 26, 2018 at 00:25 blubee blubeeme 
> wrote:
> >>
> >>> On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav 
> wrote:
> >>>
>  blubee blubeeme  writes:
> > True on both points my tone is just a reflection of attitudes of the
> > individuals that I am currently addressing.
>  Well, congratulations on alienating absolutely everybody you have
>  interacted with on this topic.
> 
> > Some people enjoy making contributions w/o waving a banner constantly
> > wanting acknowledgement, a pat on the head and good job from
> everyone.
>  The only person I see constantly craving attention and validation from
>  others here is you.
> 
> > How far will core FreeBSD bend over backwards to accommodate these
> > devs.
>  The core team does not decide what goes into the tree or not.  The
>  developers do.
> 
> > This is the beauty of an open source project, we bring the best to
> the
> > table, [...]
>  Who exactly is “we” here?  You are not a member of the project, you do
>  not speak for the project, and after seeing how you treat our fellow
>  developers, our friends, most of us want nothing to do with you.  If
>  can't live with that, I'm sure you can figure out how to install
> Linux.
> 
>  DES
>  --
>  Dag-Erling Smørgrav - d...@des.no
> >>>
> >>> Some on here want to attack my personality because they think that I am
> >>> abrasive, fine but that's not the issue.
> >>>
> >>> Some claim that they run the code and it works wonderful for them with
> no
> >>> issues, again that's lovely keep on running the code.
> >>>
> >>>   Nevertheless let me restate the point that you guys are all seeming
> to
> >>> miss; If you can go out and build custom kernels with custom options
> and
> >>> out of mainline tree that's fine, keep doing that until you have
> something
> >>> that's production ready and as easy to install as the rest of FreeBSD
> >>> system.
> >>>
> >>> The graphics stack on FreeBSD is pretty bad as it stands but all the
> >>> documentation currently out there is about using it as it stands now.
> >>>
> >>> Why do you need to rip out the current graphics drivers which will
> break
> >>> systems for the vast majority of silent users who will not complain and
> >>> just leave?
> >>>
> >>>  A little background 
> >>> Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update
> >>> their phones to the latest android version?
> >>>
> >>> It's because the Linux kernel is such a mess they know it's a waste of
> >>> resources to try. You should not have to ask how or why I know this
> but if
> >>> it's unclear I was in the field.
> >>> ---
> >>>
> >>> Now you guys who claim to only be hobbyist doing this in their free
> time
> >>> expect to maintain this when those companies with all their resources
> >>> cannot?
> >>>
> >>> Those 30,000 ports many of them bring bugs with them because of this
> >>> Linuxkpi stuff. Just recently there was a user who said google earth
> >>> doesn't work the answer was it doesn't work and that's that.
> >>>
> >>> They get ported and then get dropped so while the ports tree is large,
> if
> >>> you actually try to use some of those programs they are broken,
> >>> maintenance
> >>> hell for the developers and confusion for the users.
> >>>
> >>> Johannes Lundberg I know that you are one of the main working on this
> >>> linuxkpi stuff but anyone else is free to answer as well.
> >>>
> >>> Let's have an open discussion why do you need to remove the current
> >>> graphics stack to continue with your work?
> >>
> >> This has been discussed over and over on the mailing list and I don’t
> >> think anyone wants to do it over again so please feel free to search the
> >> archives.
> >>
> >> You’re misinformed. We are not removing anything for anyone. We are
> moving
> >> it to ports.
> >> “pkg install 

Re: drm / drm2 removal in 12

[blubee blubeeme]

On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg 
wrote:

>
>
> On Sun, Aug 26, 2018 at 00:25 blubee blubeeme  wrote:
>
>> On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav  wrote:
>>
>> > blubee blubeeme  writes:
>> > > True on both points my tone is just a reflection of attitudes of the
>> > > individuals that I am currently addressing.
>> >
>> > Well, congratulations on alienating absolutely everybody you have
>> > interacted with on this topic.
>> >
>> > > Some people enjoy making contributions w/o waving a banner constantly
>> > > wanting acknowledgement, a pat on the head and good job from everyone.
>> >
>> > The only person I see constantly craving attention and validation from
>> > others here is you.
>> >
>> > > How far will core FreeBSD bend over backwards to accommodate these
>> > > devs.
>> >
>> > The core team does not decide what goes into the tree or not.  The
>> > developers do.
>> >
>> > > This is the beauty of an open source project, we bring the best to the
>> > > table, [...]
>> >
>> > Who exactly is “we” here?  You are not a member of the project, you do
>> > not speak for the project, and after seeing how you treat our fellow
>> > developers, our friends, most of us want nothing to do with you.  If
>> > can't live with that, I'm sure you can figure out how to install Linux.
>> >
>> > DES
>> > --
>> > Dag-Erling Smørgrav - d...@des.no
>>
>>
>> Some on here want to attack my personality because they think that I am
>> abrasive, fine but that's not the issue.
>>
>> Some claim that they run the code and it works wonderful for them with no
>> issues, again that's lovely keep on running the code.
>>
>>  Nevertheless let me restate the point that you guys are all seeming to
>> miss; If you can go out and build custom kernels with custom options and
>> out of mainline tree that's fine, keep doing that until you have something
>> that's production ready and as easy to install as the rest of FreeBSD
>> system.
>>
>> The graphics stack on FreeBSD is pretty bad as it stands but all the
>> documentation currently out there is about using it as it stands now.
>>
>> Why do you need to rip out the current graphics drivers which will break
>> systems for the vast majority of silent users who will not complain and
>> just leave?
>>
>>  A little background 
>> Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update
>> their phones to the latest android version?
>>
>> It's because the Linux kernel is such a mess they know it's a waste of
>> resources to try. You should not have to ask how or why I know this but if
>> it's unclear I was in the field.
>> ---
>>
>> Now you guys who claim to only be hobbyist doing this in their free time
>> expect to maintain this when those companies with all their resources
>> cannot?
>>
>> Those 30,000 ports many of them bring bugs with them because of this
>> Linuxkpi stuff. Just recently there was a user who said google earth
>> doesn't work the answer was it doesn't work and that's that.
>>
>> They get ported and then get dropped so while the ports tree is large, if
>> you actually try to use some of those programs they are broken,
>> maintenance
>> hell for the developers and confusion for the users.
>>
>> Johannes Lundberg I know that you are one of the main working on this
>> linuxkpi stuff but anyone else is free to answer as well.
>>
>> Let's have an open discussion why do you need to remove the current
>> graphics stack to continue with your work?
>
>
> This has been discussed over and over on the mailing list and I don’t
> think anyone wants to do it over again so please feel free to search the
> archives.
>
> You’re misinformed. We are not removing anything for anyone. We are moving
> it to ports.
> “pkg install drm-legacy-kmod” will install those drivers for you that were
> earlier in base. I thought we have been clear about this but maybe we
> haven’t been clear enough.
>
>
>
>> ___
>> 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
>> "
>>
> Have you or anyone working on this drm-legacy-kmod stuff done any testings
of how this will affect current users?

1) Take a [test] system with the current graphics stack installed and
working.
2) Apply your patches to remove the drm from base to create a port
3) update the working [test] system after applying your changes

How does your changes affect a [test] system that is already up and running?

Have any of you guys tried that? Do you have any documentation on how it'll
affect users.

You guys want to remove things from the current system but you come with;
it works for us hobbyists.
Where do users go to get steps to do all of this stuff?

You've repeatedly said what you want to do sure, but have you tested it?
___

Re: drm / drm2 removal in 12

[Johannes Lundberg]

On Sun, Aug 26, 2018 at 00:25 blubee blubeeme  wrote:

> On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav  wrote:
>
> > blubee blubeeme  writes:
> > > True on both points my tone is just a reflection of attitudes of the
> > > individuals that I am currently addressing.
> >
> > Well, congratulations on alienating absolutely everybody you have
> > interacted with on this topic.
> >
> > > Some people enjoy making contributions w/o waving a banner constantly
> > > wanting acknowledgement, a pat on the head and good job from everyone.
> >
> > The only person I see constantly craving attention and validation from
> > others here is you.
> >
> > > How far will core FreeBSD bend over backwards to accommodate these
> > > devs.
> >
> > The core team does not decide what goes into the tree or not.  The
> > developers do.
> >
> > > This is the beauty of an open source project, we bring the best to the
> > > table, [...]
> >
> > Who exactly is “we” here?  You are not a member of the project, you do
> > not speak for the project, and after seeing how you treat our fellow
> > developers, our friends, most of us want nothing to do with you.  If
> > can't live with that, I'm sure you can figure out how to install Linux.
> >
> > DES
> > --
> > Dag-Erling Smørgrav - d...@des.no
>
>
> Some on here want to attack my personality because they think that I am
> abrasive, fine but that's not the issue.
>
> Some claim that they run the code and it works wonderful for them with no
> issues, again that's lovely keep on running the code.
>
>  Nevertheless let me restate the point that you guys are all seeming to
> miss; If you can go out and build custom kernels with custom options and
> out of mainline tree that's fine, keep doing that until you have something
> that's production ready and as easy to install as the rest of FreeBSD
> system.
>
> The graphics stack on FreeBSD is pretty bad as it stands but all the
> documentation currently out there is about using it as it stands now.
>
> Why do you need to rip out the current graphics drivers which will break
> systems for the vast majority of silent users who will not complain and
> just leave?
>
>  A little background 
> Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update
> their phones to the latest android version?
>
> It's because the Linux kernel is such a mess they know it's a waste of
> resources to try. You should not have to ask how or why I know this but if
> it's unclear I was in the field.
> ---
>
> Now you guys who claim to only be hobbyist doing this in their free time
> expect to maintain this when those companies with all their resources
> cannot?
>
> Those 30,000 ports many of them bring bugs with them because of this
> Linuxkpi stuff. Just recently there was a user who said google earth
> doesn't work the answer was it doesn't work and that's that.
>
> They get ported and then get dropped so while the ports tree is large, if
> you actually try to use some of those programs they are broken, maintenance
> hell for the developers and confusion for the users.
>
> Johannes Lundberg I know that you are one of the main working on this
> linuxkpi stuff but anyone else is free to answer as well.
>
> Let's have an open discussion why do you need to remove the current
> graphics stack to continue with your work?


This has been discussed over and over on the mailing list and I don’t think
anyone wants to do it over again so please feel free to search the
archives.

You’re misinformed. We are not removing anything for anyone. We are moving
it to ports.
“pkg install drm-legacy-kmod” will install those drivers for you that were
earlier in base. I thought we have been clear about this but maybe we
haven’t been clear enough.



> ___
> 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: drm / drm2 removal in 12

[blubee blubeeme]

On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav  wrote:

> blubee blubeeme  writes:
> > True on both points my tone is just a reflection of attitudes of the
> > individuals that I am currently addressing.
>
> Well, congratulations on alienating absolutely everybody you have
> interacted with on this topic.
>
> > Some people enjoy making contributions w/o waving a banner constantly
> > wanting acknowledgement, a pat on the head and good job from everyone.
>
> The only person I see constantly craving attention and validation from
> others here is you.
>
> > How far will core FreeBSD bend over backwards to accommodate these
> > devs.
>
> The core team does not decide what goes into the tree or not.  The
> developers do.
>
> > This is the beauty of an open source project, we bring the best to the
> > table, [...]
>
> Who exactly is “we” here?  You are not a member of the project, you do
> not speak for the project, and after seeing how you treat our fellow
> developers, our friends, most of us want nothing to do with you.  If
> can't live with that, I'm sure you can figure out how to install Linux.
>
> DES
> --
> Dag-Erling Smørgrav - d...@des.no


Some on here want to attack my personality because they think that I am
abrasive, fine but that's not the issue.

Some claim that they run the code and it works wonderful for them with no
issues, again that's lovely keep on running the code.

 Nevertheless let me restate the point that you guys are all seeming to
miss; If you can go out and build custom kernels with custom options and
out of mainline tree that's fine, keep doing that until you have something
that's production ready and as easy to install as the rest of FreeBSD
system.

The graphics stack on FreeBSD is pretty bad as it stands but all the
documentation currently out there is about using it as it stands now.

Why do you need to rip out the current graphics drivers which will break
systems for the vast majority of silent users who will not complain and
just leave?

 A little background 
Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update
their phones to the latest android version?

It's because the Linux kernel is such a mess they know it's a waste of
resources to try. You should not have to ask how or why I know this but if
it's unclear I was in the field.
---

Now you guys who claim to only be hobbyist doing this in their free time
expect to maintain this when those companies with all their resources
cannot?

Those 30,000 ports many of them bring bugs with them because of this
Linuxkpi stuff. Just recently there was a user who said google earth
doesn't work the answer was it doesn't work and that's that.

They get ported and then get dropped so while the ports tree is large, if
you actually try to use some of those programs they are broken, maintenance
hell for the developers and confusion for the users.

Johannes Lundberg I know that you are one of the main working on this
linuxkpi stuff but anyone else is free to answer as well.

Let's have an open discussion why do you need to remove the current
graphics stack to continue with your work?
___
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: drm / drm2 removal in 12

[Dag-Erling Smørgrav]

blubee blubeeme  writes:
> True on both points my tone is just a reflection of attitudes of the
> individuals that I am currently addressing.

Well, congratulations on alienating absolutely everybody you have
interacted with on this topic.

> Some people enjoy making contributions w/o waving a banner constantly
> wanting acknowledgement, a pat on the head and good job from everyone.

The only person I see constantly craving attention and validation from
others here is you.

> How far will core FreeBSD bend over backwards to accommodate these
> devs.

The core team does not decide what goes into the tree or not.  The
developers do.

> This is the beauty of an open source project, we bring the best to the
> table, [...]

Who exactly is “we” here?  You are not a member of the project, you do
not speak for the project, and after seeing how you treat our fellow
developers, our friends, most of us want nothing to do with you.  If
can't live with that, I'm sure you can figure out how to install Linux.

DES
-- 
Dag-Erling Smørgrav - d...@des.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: drm / drm2 removal in 12

[Johannes Lundberg]

Hi Owen

I'm truly sorry you feel this way about our work.

At first I was thinking "I'm not going to feed the troll" but after giving
what you're writing some more thought it seems maybe you have misunderstood
some things that I want to clarify to make sure there's no misunderstanding
by you or any one else reading this.

There are almost 30,000 ports now in the ports tree. Many are ported from
various operating systems. Many are from Linux, GPL'd and in most cases we
depend on them for running the graphical desktop of our choice on FreeBSD.

However, these ports are all optional. You don't have to install any of
them if you don't want to, this includes the new generation GPU drivers and
LinuxKPI.  Linux is not "moving in to" the FreeBSD kernel.

For those of you who want a "pure" BSD experience, running without X is
just fine, or finding a pure BSD solution if one exists. For those who
don't want Linux derived graphics drivers (which by the way the ones in
sys/dev/drm2/ also are), nothing is forcing you to use them. Vesa of scfb
works beautifully for a software rendered graphical user interface. Nvidia
provides a native driver for FreeBSD if you have their hardware.

CURRENT breaks sometimes, not only because of graphics. This is the nature
of bleeding edge but we work hard to keep breakage to a minimal. For those
of you who wish to run a more stable system, use a stable release.

The graphics team at FreeBSD has new members and we're still trying to find
our way regarding release schedule, support and other things. It's still a
WIP and the road has been bumpy. There is still a lot to do for us to catch
up and be able to provide a consistent experience for everyone.

Again, we're doing the best we can with the resources we have. There's no
way the few developers we have could develop and maintain native GPU
drivers, spanning 20 years on three different hardware platforms.
Especially considering how fast moving target the graphics hardware is.

I know nothing I say matters to you, Owen, but your comments are quite
extreme and contain false doomsday propaganda.. This mail is more to
provide some information from the graphics team for anyone reading this so
they don't fall for false propaganda.


On Sat, Aug 25, 2018 at 12:45 PM blubee blubeeme 
wrote:

> On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen <
> sh+freebsd-curr...@codevoid.de>
> wrote:
>
> > blubee blubeeme wrote:
> > > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote:
> > >> I've been personally using the new DRM bits since almost day one. I
> > >> haven't found it to be unstable in the slightest. Compared to not
> > >> having it and being forced to run 5+ year old hardware, it's been a
> > >> huge blessing for those of us who care about running FreeBSD as a
> > >> modern desktop / laptop.
> > >>
> > >> FreeBSD being an open source project, you are welcome to contribute
> > >> back your work anytime. But since I don't imagine we'll see that
> > >> patch coming anytime soon, I'll stick with this new LinuxKPI-powered,
> > >> Plasma-desktop running awesomeness.
> > >>
> > >> (Written from my brand new Lenovo P71 which worked flawlessly out of
> > >> box)
> > >
> > > Please tell me more about you're modern hardware, Kris Vice President
> > > of Engineering at iXsystems.
> > >
> > > Try asking a person who doesn't run server infrastructure software and
> > > hardware to get that stuff up and running, would you?
> >
> > Do you want to ask me? I'm mostly a private individual and linux/debian
> > user that got fed up with the Linux fragmentation and direction of
> > development (from a user perspective). I found my new home in FreeBSD.
> > I migrated my (hobby) root server and have a few jails up and running
> > and doing random stuff on them for myself and friends.
> >
> > Key to this was that I was able to get FreeBSD up and running on my
> > Laptop - with the drm-next kmod - and use it daily to get used to it and
> > learn about it. Actually it was a pain in the ass because back then I
> > had to learn how to make -current run and even worse, I had to use the
> > drm-next graphics branch from a github repository which wasn't even
> > on the main FreeBSD account. I was forced to update the kernel every
> > once in a while because the pkg update would complain otherwise. It
> > frequently broke and I had to deal with it and learn how to recover it.
> >
> > The alternative would have been to go back to Linux, which has a whole
> > lot more to complain about. So I stayed. And I'm happy with it.
> >
> > I accepted all this trouble to have decent graphics support. In all
> > the time I had to fight -current issues a lot more than anything
> > drm/graphics related. This stuff was always stable for me.
> >
> > I saw a few people trying out FreeBSD. And the first thing after the
> > Installation is always: Graphics and Wifi. That's what people need.
> >
> > These are "desktop needs", where supporting new hardware fast is more
> > important than being rock 

Re: drm / drm2 removal in 12

[Dave Cottlehuber]

> On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen 
> > > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote:
> > >> I've been personally using the new DRM bits since almost day one. I
> > >> haven't found it to be unstable in the slightest. Compared to not
> > >> having it and being forced to run 5+ year old hardware, it's been a
> > >> huge blessing for those of us who care about running FreeBSD as a
> > >> modern desktop / laptop.

Ditto. I'd like to express my heartfelt thanks for all the people who have been
working on the drm-next code for over 2 years now. It's fantastic and an
incredible piece of effort to pull it all together.

I bought a new laptop 2 years ago, started running the drm-next branch
before it even landed in the main FreeBSD tree, and its been solid as a rock.
It was my first foray into running current and I've not looked back since.

Power mgmt is great, I have working suspend/resume, backlight, HDMI 
hot-plug output with video & sound as well. That's amazing.

A+++
Dave
___
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: drm / drm2 removal in 12

[blubee blubeeme]

On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen 
wrote:

> blubee blubeeme wrote:
> > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote:
> >> I've been personally using the new DRM bits since almost day one. I
> >> haven't found it to be unstable in the slightest. Compared to not
> >> having it and being forced to run 5+ year old hardware, it's been a
> >> huge blessing for those of us who care about running FreeBSD as a
> >> modern desktop / laptop.
> >>
> >> FreeBSD being an open source project, you are welcome to contribute
> >> back your work anytime. But since I don't imagine we'll see that
> >> patch coming anytime soon, I'll stick with this new LinuxKPI-powered,
> >> Plasma-desktop running awesomeness.
> >>
> >> (Written from my brand new Lenovo P71 which worked flawlessly out of
> >> box)
> >
> > Please tell me more about you're modern hardware, Kris Vice President
> > of Engineering at iXsystems.
> >
> > Try asking a person who doesn't run server infrastructure software and
> > hardware to get that stuff up and running, would you?
>
> Do you want to ask me? I'm mostly a private individual and linux/debian
> user that got fed up with the Linux fragmentation and direction of
> development (from a user perspective). I found my new home in FreeBSD.
> I migrated my (hobby) root server and have a few jails up and running
> and doing random stuff on them for myself and friends.
>
> Key to this was that I was able to get FreeBSD up and running on my
> Laptop - with the drm-next kmod - and use it daily to get used to it and
> learn about it. Actually it was a pain in the ass because back then I
> had to learn how to make -current run and even worse, I had to use the
> drm-next graphics branch from a github repository which wasn't even
> on the main FreeBSD account. I was forced to update the kernel every
> once in a while because the pkg update would complain otherwise. It
> frequently broke and I had to deal with it and learn how to recover it.
>
> The alternative would have been to go back to Linux, which has a whole
> lot more to complain about. So I stayed. And I'm happy with it.
>
> I accepted all this trouble to have decent graphics support. In all
> the time I had to fight -current issues a lot more than anything
> drm/graphics related. This stuff was always stable for me.
>
> I saw a few people trying out FreeBSD. And the first thing after the
> Installation is always: Graphics and Wifi. That's what people need.
>
> These are "desktop needs", where supporting new hardware fast is more
> important than being rock stable and feature complete.
>
> Just my 2 cents,
> Stefan
>
> --
> Stefan Hagen
> Mail: s...@codevoid.de | encryption key in header.
> gopher://codevoid.de | https://codevoid.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"
>
Like you said you're doing hobby work, that's fine. Take the time to test
that bleeding edge stuff on a branch somewhere.

You guys cannot expect reasonable people who have machines running
production code to have to deal with that type of nonsense that you just
described.

You left Linux because it's an unorganized mess, FreeBSD is not Linux.
There are clear rules and restrictions if you guys cannot understand this
then this is just a waste of time.

FreeBSD is server first and while that may suck for hobbyist at first, once
you understand that people who run servers do not care about graphics as
much as hobbyist do they need a reliable core.

The linuxkpi stuff the total antithesis of what I understand to be the
FreeBSD philosophy. Try reading it again:
https://www.freebsd.org/doc/handbook/nutshell.html

You guys can't expect to destroy the stability for everyone because a few
hobbyist who volunteer in their free time want to wreck the system.

Work on your code to improve the quality instead of trying to turn the
FreeBSD kernel into a thin wrapper around Linux kernel. Solve the
engineering problems instead of asking for quick fix solutions.

Any of you linuxkpi guys who are pushing this, what will be enough?

Haven't you guys gotten enough leeway from the core team?
How many breaking changes do you want to introduce to the FreeBSD kernel vs
engineering your software to work well within the existing infrastructure?

Which one of you guys dare to stand up and define a goal?
___
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: drm / drm2 removal in 12

[Stefan Hagen]

blubee blubeeme wrote:
> On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote:
>> I've been personally using the new DRM bits since almost day one. I
>> haven't found it to be unstable in the slightest. Compared to not
>> having it and being forced to run 5+ year old hardware, it's been a
>> huge blessing for those of us who care about running FreeBSD as a
>> modern desktop / laptop.
>>
>> FreeBSD being an open source project, you are welcome to contribute
>> back your work anytime. But since I don't imagine we'll see that
>> patch coming anytime soon, I'll stick with this new LinuxKPI-powered,
>> Plasma-desktop running awesomeness.
>>
>> (Written from my brand new Lenovo P71 which worked flawlessly out of
>> box)
>
> Please tell me more about you're modern hardware, Kris Vice President
> of Engineering at iXsystems.
>
> Try asking a person who doesn't run server infrastructure software and
> hardware to get that stuff up and running, would you?

Do you want to ask me? I'm mostly a private individual and linux/debian
user that got fed up with the Linux fragmentation and direction of
development (from a user perspective). I found my new home in FreeBSD.
I migrated my (hobby) root server and have a few jails up and running
and doing random stuff on them for myself and friends.

Key to this was that I was able to get FreeBSD up and running on my
Laptop - with the drm-next kmod - and use it daily to get used to it and
learn about it. Actually it was a pain in the ass because back then I
had to learn how to make -current run and even worse, I had to use the
drm-next graphics branch from a github repository which wasn't even
on the main FreeBSD account. I was forced to update the kernel every
once in a while because the pkg update would complain otherwise. It
frequently broke and I had to deal with it and learn how to recover it.

The alternative would have been to go back to Linux, which has a whole
lot more to complain about. So I stayed. And I'm happy with it.

I accepted all this trouble to have decent graphics support. In all
the time I had to fight -current issues a lot more than anything
drm/graphics related. This stuff was always stable for me.

I saw a few people trying out FreeBSD. And the first thing after the
Installation is always: Graphics and Wifi. That's what people need.

These are "desktop needs", where supporting new hardware fast is more
important than being rock stable and feature complete.

Just my 2 cents,
Stefan

-- 
Stefan Hagen
Mail: s...@codevoid.de | encryption key in header.
gopher://codevoid.de | https://codevoid.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: drm / drm2 removal in 12

[blubee blubeeme]

On Sat, Aug 25, 2018 at 4:27 PM Matthew Macy  wrote:

> Hi Owen -
> I understand that you're enthusiastic and you just want what's best for
> the project. However, there's a couple of points I hope you'll take to
> heart. First, please read what you sent and think about the tone and word
> choice. It's extremely negative and critical - you're actively alienating
> people on the list. You're not going to be successful engaging any open
> source community or workplace if you choose to communicate like this.
> Second, this is a volunteer project. One needs to establish a track record
> of producing patches and working with developers to get them committed.
> Regardless of how sound your technical position is - you're going to have a
> hard time being acknowledged if there is no contribution to match.
>
> Best wishes.
> -M
>
True on both points my tone is just a reflection of attitudes of the
individuals that I am currently addressing.

Some people enjoy making contributions w/o waving a banner constantly
wanting acknowledgement, a pat on the head and good job from everyone.

How far will core FreeBSD bend over backwards to accommodate these devs.
Their project is half baked at best and sure it works; sorta if the moon is
just right.

This is the beauty of an open source project, we bring the best to the
table, not rip off two legs only to glue them back on later just
slightly askew.

This isn't a world where everyone gets a gold star, people fail even if
they work very hard, failure is still an option.

I guess the most important question to ask is what's the standards that the
FreeBSD Foundation want to represent, uphold, and maintain?

>
>
> On Fri, Aug 24, 2018 at 4:07 PM blubee blubeeme 
> wrote:
>
>>
>>
>> On Sat, Aug 25, 2018 at 6:26 AM Warner Losh  wrote:
>>
>>> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy  wrote:
>>>
>>> > On Fri, Aug 24, 2018 at 14:53 Ali  wrote:
>>> >
>>> > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
>>> > > > Just in case anyone misses the change to UPDATING:
>>> > > >
>>> > > > 20180821:
>>> > > > drm and drm2 have been removed. Users on powerpc, 32-bit
>>> > > hardware,
>>> > > > or with GPUs predating Radeon and i915 will need to
>>> install the
>>> > > > graphics/drm-legacy-kmod. All other users should be able
>>> to use
>>> > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
>>> > > > graphics/drm-next-kmod, graphics/drm-devel-kmod.
>>> > > > Note that this applies only to 12.
>>> > >
>>> > > I see that The removal of drm and drm2 has been reverted on svn.
>>> Could
>>> > > you please kindly share the reasons behind the re-inclusion?
>>> > >
>>> >
>>> >
>>> > I can’t really give the blow by blow of internal project drama, but the
>>> > gist of it is that “best practices” (which are not yet actually
>>> documented
>>> > anywhere that I’ve seen) were not followed with regards to the
>>> deprecation
>>> > process. Warner and others believe that we can address the objectives
>>> of
>>> > the drm removal (improving the user experience and communicating that
>>> > drm/drm2 are _completely_ unsupported apart from continuing to compile)
>>> > through less disruptive means.
>>> >
>>>
>>> Just so.
>>>
>>> Our only continued frustration is that we were never given any guidance
>>> by
>>> > RE or core on said “best practices” when the discussion was taking
>>> place in
>>> > May and then those groups behaved as if this were a surprise when the
>>> > removal happened. I’m cautiously optimistic that this well expedite
>>> > improving communications on those matters.
>>> >
>>>
>>> All the problems that are exposed by this aren't technical. This one is
>>> social, but no less important.
>>>
>>> Warner
>>> ___
>>> 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"
>>>
>>
>> I've been watching this debacle for quite some time now and I'd just like
>> to ask why the rush?
>>
>> The graphics team is working very hard to destroy the stability of
>> FreeBSD just so that they can force their uncooked work down users throats.
>>
>> The Linuxkpi is unstable at best, alpha level software that's constantly
>> in need of someone to go and fix something on FreeBSD because Linux devs
>> decided to make some changes or implement a new feature.
>>
>> This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM
>> Goals
>>
>>- Move DRM headers to a similar location as Linux
>>-
>>
>>Use kmalloc() instead of malloc(9)
>>- Use kref
>>-
>>
>>Use idr and get rid of drm_gem_names.c
>>- Use PCI API
>>- Use Linux locking primitives
>>
>> is garbage, if you want to use develop Linux code and use Linux then go
>> do that on Linux.
>>
>> Are these guys insane and please avoid the nonsense about you're doing
>> this in your spare 

Re: drm / drm2 removal in 12

[Ali Abdallah]

Isn't Intel supposed to be working on a native drm driver for FreeBSD?

https://bwidawsk.net/blog/index.php/2018/06/i965-compiler-architecture-from-2015/

On Sat, Aug 25, 2018 at 12:19 AM, Matthew Macy  wrote:

>
>
> On Fri, Aug 24, 2018 at 14:53 Ali  wrote:
>
>> On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
>> > Just in case anyone misses the change to UPDATING:
>> >
>> > 20180821:
>> > drm and drm2 have been removed. Users on powerpc, 32-bit
>> hardware,
>> > or with GPUs predating Radeon and i915 will need to install the
>> > graphics/drm-legacy-kmod. All other users should be able to use
>> > one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
>> > graphics/drm-next-kmod, graphics/drm-devel-kmod.
>> > Note that this applies only to 12.
>>
>> I see that The removal of drm and drm2 has been reverted on svn. Could
>> you please kindly share the reasons behind the re-inclusion?
>>
>
>
> I can’t really give the blow by blow of internal project drama, but the
> gist of it is that “best practices” (which are not yet actually documented
> anywhere that I’ve seen) were not followed with regards to the deprecation
> process. Warner and others believe that we can address the objectives of
> the drm removal (improving the user experience and communicating that
> drm/drm2 are _completely_ unsupported apart from continuing to compile)
> through less disruptive means. I am only acting as a lightning rod and
> representative of the graphics team and so have done an inadequate job of
> tracking their activities with respect to project timelines. As a result of
> this misunderstanding Johannes Lundberg will be sponsored for a bit and
> will be able to be involved in internal discussions that impact his work.
>
> Our only continued frustration is that we were never given any guidance by
> RE or core on said “best practices” when the discussion was taking place in
> May and then those groups behaved as if this were a surprise when the
> removal happened. I’m cautiously optimistic that this well expedite
> improving communications on those matters.
>
>
> 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: drm / drm2 removal in 12

[Matthew Macy]

Hi Owen -
I understand that you're enthusiastic and you just want what's best for the
project. However, there's a couple of points I hope you'll take to heart.
First, please read what you sent and think about the tone and word choice.
It's extremely negative and critical - you're actively alienating people on
the list. You're not going to be successful engaging any open source
community or workplace if you choose to communicate like this. Second, this
is a volunteer project. One needs to establish a track record of producing
patches and working with developers to get them committed. Regardless of
how sound your technical position is - you're going to have a hard time
being acknowledged if there is no contribution to match.

Best wishes.
-M


On Fri, Aug 24, 2018 at 4:07 PM blubee blubeeme  wrote:

>
>
> On Sat, Aug 25, 2018 at 6:26 AM Warner Losh  wrote:
>
>> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy  wrote:
>>
>> > On Fri, Aug 24, 2018 at 14:53 Ali  wrote:
>> >
>> > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
>> > > > Just in case anyone misses the change to UPDATING:
>> > > >
>> > > > 20180821:
>> > > > drm and drm2 have been removed. Users on powerpc, 32-bit
>> > > hardware,
>> > > > or with GPUs predating Radeon and i915 will need to install
>> the
>> > > > graphics/drm-legacy-kmod. All other users should be able to
>> use
>> > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
>> > > > graphics/drm-next-kmod, graphics/drm-devel-kmod.
>> > > > Note that this applies only to 12.
>> > >
>> > > I see that The removal of drm and drm2 has been reverted on svn. Could
>> > > you please kindly share the reasons behind the re-inclusion?
>> > >
>> >
>> >
>> > I can’t really give the blow by blow of internal project drama, but the
>> > gist of it is that “best practices” (which are not yet actually
>> documented
>> > anywhere that I’ve seen) were not followed with regards to the
>> deprecation
>> > process. Warner and others believe that we can address the objectives of
>> > the drm removal (improving the user experience and communicating that
>> > drm/drm2 are _completely_ unsupported apart from continuing to compile)
>> > through less disruptive means.
>> >
>>
>> Just so.
>>
>> Our only continued frustration is that we were never given any guidance by
>> > RE or core on said “best practices” when the discussion was taking
>> place in
>> > May and then those groups behaved as if this were a surprise when the
>> > removal happened. I’m cautiously optimistic that this well expedite
>> > improving communications on those matters.
>> >
>>
>> All the problems that are exposed by this aren't technical. This one is
>> social, but no less important.
>>
>> Warner
>> ___
>> 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
>> "
>>
>
> I've been watching this debacle for quite some time now and I'd just like
> to ask why the rush?
>
> The graphics team is working very hard to destroy the stability of FreeBSD
> just so that they can force their uncooked work down users throats.
>
> The Linuxkpi is unstable at best, alpha level software that's constantly
> in need of someone to go and fix something on FreeBSD because Linux devs
> decided to make some changes or implement a new feature.
>
> This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM
> Goals
>
>- Move DRM headers to a similar location as Linux
>-
>
>Use kmalloc() instead of malloc(9)
>- Use kref
>-
>
>Use idr and get rid of drm_gem_names.c
>- Use PCI API
>- Use Linux locking primitives
>
> is garbage, if you want to use develop Linux code and use Linux then go do
> that on Linux.
>
> Are these guys insane and please avoid the nonsense about you're doing
> this in your spare time.
>
> If you cannot devote the resources to do something right then don't do it
> at all.
>
> Keep that stuff in to yourself or anyone crazy enough to follow those
> steps to get it up and running, you guys cannot expect to contaminate the
> entire FreeBSD project for this mess.
>
> This is nonsense and I hope that more people who see it as such would say
> so and stop having these guys forcing this crap; it's maintenance hell who
> will maintain it if they decide to leave?
>
> Best,
> Owen
>
>
___
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: drm / drm2 removal in 12

[blubee blubeeme]

On Sat, Aug 25, 2018 at 10:04 AM Mark Linimon  wrote:

> On Sat, Aug 25, 2018 at 07:07:24AM +0800, blubee blubeeme wrote:
> > Are these guys insane and please avoid the nonsense about you're doing
> this
> > in your spare time.
>
> Let us know how whatever OS you wind up using instead works for you.
> I suggest you look for one that will put up with your constant harangues.
>
> There are very few people on the mailing lists as nasty and rude as
> yourself.  It is tiresome, demotivating, and childish.  Please go
> elsewhere.
>
> mcl
>
Your opinion has been noted but this issue isn't about me.

It's about the Graphics devs coding themselves into a corner and looking
for an easy button so they can continue to feel good about their toy.

There's a reason the changes they tried to force down the FreeBSD source
tree was reverted; It does not meet any standards of quality.

I have no inside knowledge other than my ability to think clearly and it's
obvious that The FreeBSD team wanted to hint at them that their code
doesn't pass the sniff test.

Instead of being whiny brats improve your code and have it work without
breaking compatibility with what has been working for quite a long time.

Here's the play by play;
You guys push this mess contaminating the FreeBSD source tree, some long
standing user tries to update their machines and it blows up;
1) Most will just leave
2) Some will complain
   2a) You guys will say; Read UPDATING. bleh bleh blen
They'll get aggravated, thereby aggravating people who came to this
platform for Stability.

Users who actually use FreeBSD to get things done do not time to trawl
these mailing lists, they have real world problems to solve with real world
constraints.

There are OS with kqueue and all those things it's called Linux; You can go
there and play w/ that stuff to your hearts content.

If you want your code to get merged, make sure it follows the guidelines
and not break the systems for people who are already using the platform.

Now, I understand hearing harsh criticism about your work might hurt your
feelings and all but here's the antidote;
work harder,
improve your code,
try again when your code quality improves.

You guys cannot expect people to accept these kludges in their systems that
they run everyday.

It's an open source project, you can't get mad because your code isn't
accepted, it's your jobs and engineers to do better not expect users to
jump through hoops to accommodate your subpar attempts at coding.

This isn't about me, it's about the quality of code that you guys are
trying to submit.

Best,
Owen
___
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: drm / drm2 removal in 12

[Mark Linimon]

On Sat, Aug 25, 2018 at 07:07:24AM +0800, blubee blubeeme wrote:
> Are these guys insane and please avoid the nonsense about you're doing this
> in your spare time.

Let us know how whatever OS you wind up using instead works for you.
I suggest you look for one that will put up with your constant harangues.

There are very few people on the mailing lists as nasty and rude as
yourself.  It is tiresome, demotivating, and childish.  Please go elsewhere.

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: drm / drm2 removal in 12

[blubee blubeeme]

On Sat, Aug 25, 2018 at 8:40 AM Pete Wright  wrote:

>
>
> On 8/24/18 4:07 PM, blubee blubeeme wrote:
>
> > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM
> > Goals
> >
> > - Move DRM headers to a similar location as Linux
> > -
> >
> > Use kmalloc() instead of malloc(9)
> > - Use kref
> > -
> >
> > Use idr and get rid of drm_gem_names.c
> > - Use PCI API
> > - Use Linux locking primitives
> >
> > is garbage, if you want to use develop Linux code and use Linux then go
> do
> > that on Linux.
> having a hard time not feeding the troll here...but what specifically is
> garbage.  as in, what implementation of all this work do you have
> available that has been developed independently which also enables
> support for modern desktop and portable systems that you can buy today?
> > Are these guys insane and please avoid the nonsense about you're doing
> this
> > in your spare time.
>
The idea that FreeBSD relax it's standards just so that some devs have an
easier time
bringing up a half baked idea is nonsense.

Let's take power management, after you guys do all this work to get the
graphics card working
how much of devd will you need to implement to get that working properly?

I don't understand why this concept seems so hard to grasp but FreeBSD is
not Linux
why are some people continually trying to turn it into some Frankenstein
thing.

If you guys consider yourself developers then do what developers do and
solve problems
with constraints, if you cannot accomplish that stop pushing these breaking
changes.

None of these kmod guys seems to have put any thought into long
term maintenance of
this project. Look at the mailing list, every few days there's some
breaking changes waiting
for patches because something changed in Linux-land...

If you can't solve the problem in a maintainable way, you will just create
bigger problems for
developers down the line. Until you guys have something that's at least as
stable as what's
available now, keep working on it.

Some people take pride in their work and deliver a working product, they
don't need to twist
peoples arms into getting their way.

speaking as someone who's been working on this from pretty much the day
> of the initial CFT (maybe before?) - i don't know anyone who's getting
> paid for this specific work.  at least when it comes to GPU support.
> but, if you have the means, I'd love to work on this full time and am
> open to any serious offers :)
>
> -pete
>
I'd hope you have something more compelling than [http://nomadlogic.org]
as your calling card.

-- 
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: drm / drm2 removal in 12

[Pete Wright]

On 8/24/18 4:07 PM, blubee blubeeme wrote:


This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM
Goals

- Move DRM headers to a similar location as Linux
-

Use kmalloc() instead of malloc(9)
- Use kref
-

Use idr and get rid of drm_gem_names.c
- Use PCI API
- Use Linux locking primitives

is garbage, if you want to use develop Linux code and use Linux then go do
that on Linux.
having a hard time not feeding the troll here...but what specifically is 
garbage.  as in, what implementation of all this work do you have 
available that has been developed independently which also enables 
support for modern desktop and portable systems that you can buy today?

Are these guys insane and please avoid the nonsense about you're doing this
in your spare time.


speaking as someone who's been working on this from pretty much the day 
of the initial CFT (maybe before?) - i don't know anyone who's getting 
paid for this specific work.  at least when it comes to GPU support.  
but, if you have the means, I'd love to work on this full time and am 
open to any serious offers :)


-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: drm / drm2 removal in 12

[blubee blubeeme]

On Sat, Aug 25, 2018 at 7:43 AM Kris Moore  wrote:

> On 8/24/18 7:07 PM, blubee blubeeme wrote:
> > On Sat, Aug 25, 2018 at 6:26 AM Warner Losh  wrote:
> >
> >> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy  wrote:
> >>
> >>> On Fri, Aug 24, 2018 at 14:53 Ali  wrote:
> >>>
>  On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
> > Just in case anyone misses the change to UPDATING:
> >
> > 20180821:
> > drm and drm2 have been removed. Users on powerpc, 32-bit
>  hardware,
> > or with GPUs predating Radeon and i915 will need to install
> >> the
> > graphics/drm-legacy-kmod. All other users should be able to
> >> use
> > one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
> > graphics/drm-next-kmod, graphics/drm-devel-kmod.
> > Note that this applies only to 12.
>  I see that The removal of drm and drm2 has been reverted on svn. Could
>  you please kindly share the reasons behind the re-inclusion?
> 
> >>>
> >>> I can’t really give the blow by blow of internal project drama, but the
> >>> gist of it is that “best practices” (which are not yet actually
> >> documented
> >>> anywhere that I’ve seen) were not followed with regards to the
> >> deprecation
> >>> process. Warner and others believe that we can address the objectives
> of
> >>> the drm removal (improving the user experience and communicating that
> >>> drm/drm2 are _completely_ unsupported apart from continuing to compile)
> >>> through less disruptive means.
> >>>
> >> Just so.
> >>
> >> Our only continued frustration is that we were never given any guidance
> by
> >>> RE or core on said “best practices” when the discussion was taking
> place
> >> in
> >>> May and then those groups behaved as if this were a surprise when the
> >>> removal happened. I’m cautiously optimistic that this well expedite
> >>> improving communications on those matters.
> >>>
> >> All the problems that are exposed by this aren't technical. This one is
> >> social, but no less important.
> >>
> >> Warner
> >> ___
> >> 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"
> >>
> > I've been watching this debacle for quite some time now and I'd just like
> > to ask why the rush?
> >
> > The graphics team is working very hard to destroy the stability of
> FreeBSD
> > just so that they can force their uncooked work down users throats.
> >
> > The Linuxkpi is unstable at best, alpha level software that's constantly
> in
> > need of someone to go and fix something on FreeBSD because Linux devs
> > decided to make some changes or implement a new feature.
> >
> > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM
> > Goals
> >
> >- Move DRM headers to a similar location as Linux
> >-
> >
> >Use kmalloc() instead of malloc(9)
> >- Use kref
> >-
> >
> >Use idr and get rid of drm_gem_names.c
> >- Use PCI API
> >- Use Linux locking primitives
> >
> > is garbage, if you want to use develop Linux code and use Linux then go
> do
> > that on Linux.
> >
> > Are these guys insane and please avoid the nonsense about you're doing
> this
> > in your spare time.
> >
> > If you cannot devote the resources to do something right then don't do it
> > at all.
> >
> > Keep that stuff in to yourself or anyone crazy enough to follow those
> steps
> > to get it up and running, you guys cannot expect to contaminate the
> entire
> > FreeBSD project for this mess.
> >
> > This is nonsense and I hope that more people who see it as such would say
> > so and stop having these guys forcing this crap; it's maintenance hell
> who
> > will maintain it if they decide to leave?
> >
> > Best,
> > Owen
> > ___
> > 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"
>
> I've been personally using the new DRM bits since almost day one. I
> haven't found it to be unstable in the slightest. Compared to not having
> it and being forced to run 5+ year old hardware, it's been a huge
> blessing for those of us who care about running FreeBSD as a modern
> desktop / laptop.
>
> FreeBSD being an open source project, you are welcome to contribute back
> your work anytime. But since I don't imagine we'll see that patch coming
> anytime soon, I'll stick with this new LinuxKPI-powered, Plasma-desktop
> running awesomeness.
>
> (Written from my brand new Lenovo P71 which worked flawlessly out of box)
>
>
> --
> Kris Moore
> Vice President of Engineering
> iXsystems
> Enterprise Storage & Servers Driven By Open Source
>
> ___
> freebsd-current@freebsd.org mailing list
> 

Re: drm / drm2 removal in 12

[Kris Moore]

On 8/24/18 7:07 PM, blubee blubeeme wrote:
> On Sat, Aug 25, 2018 at 6:26 AM Warner Losh  wrote:
>
>> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy  wrote:
>>
>>> On Fri, Aug 24, 2018 at 14:53 Ali  wrote:
>>>
 On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
> Just in case anyone misses the change to UPDATING:
>
> 20180821:
> drm and drm2 have been removed. Users on powerpc, 32-bit
 hardware,
> or with GPUs predating Radeon and i915 will need to install
>> the
> graphics/drm-legacy-kmod. All other users should be able to
>> use
> one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
> graphics/drm-next-kmod, graphics/drm-devel-kmod.
> Note that this applies only to 12.
 I see that The removal of drm and drm2 has been reverted on svn. Could
 you please kindly share the reasons behind the re-inclusion?

>>>
>>> I can’t really give the blow by blow of internal project drama, but the
>>> gist of it is that “best practices” (which are not yet actually
>> documented
>>> anywhere that I’ve seen) were not followed with regards to the
>> deprecation
>>> process. Warner and others believe that we can address the objectives of
>>> the drm removal (improving the user experience and communicating that
>>> drm/drm2 are _completely_ unsupported apart from continuing to compile)
>>> through less disruptive means.
>>>
>> Just so.
>>
>> Our only continued frustration is that we were never given any guidance by
>>> RE or core on said “best practices” when the discussion was taking place
>> in
>>> May and then those groups behaved as if this were a surprise when the
>>> removal happened. I’m cautiously optimistic that this well expedite
>>> improving communications on those matters.
>>>
>> All the problems that are exposed by this aren't technical. This one is
>> social, but no less important.
>>
>> Warner
>> ___
>> 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"
>>
> I've been watching this debacle for quite some time now and I'd just like
> to ask why the rush?
>
> The graphics team is working very hard to destroy the stability of FreeBSD
> just so that they can force their uncooked work down users throats.
>
> The Linuxkpi is unstable at best, alpha level software that's constantly in
> need of someone to go and fix something on FreeBSD because Linux devs
> decided to make some changes or implement a new feature.
>
> This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM
> Goals
>
>- Move DRM headers to a similar location as Linux
>-
>
>Use kmalloc() instead of malloc(9)
>- Use kref
>-
>
>Use idr and get rid of drm_gem_names.c
>- Use PCI API
>- Use Linux locking primitives
>
> is garbage, if you want to use develop Linux code and use Linux then go do
> that on Linux.
>
> Are these guys insane and please avoid the nonsense about you're doing this
> in your spare time.
>
> If you cannot devote the resources to do something right then don't do it
> at all.
>
> Keep that stuff in to yourself or anyone crazy enough to follow those steps
> to get it up and running, you guys cannot expect to contaminate the entire
> FreeBSD project for this mess.
>
> This is nonsense and I hope that more people who see it as such would say
> so and stop having these guys forcing this crap; it's maintenance hell who
> will maintain it if they decide to leave?
>
> Best,
> Owen
> ___
> 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"

I've been personally using the new DRM bits since almost day one. I
haven't found it to be unstable in the slightest. Compared to not having
it and being forced to run 5+ year old hardware, it's been a huge
blessing for those of us who care about running FreeBSD as a modern
desktop / laptop.

FreeBSD being an open source project, you are welcome to contribute back
your work anytime. But since I don't imagine we'll see that patch coming
anytime soon, I'll stick with this new LinuxKPI-powered, Plasma-desktop
running awesomeness.

(Written from my brand new Lenovo P71 which worked flawlessly out of box)


-- 
Kris Moore
Vice President of Engineering
iXsystems
Enterprise Storage & Servers Driven By Open Source

___
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: drm / drm2 removal in 12

[blubee blubeeme]

On Sat, Aug 25, 2018 at 6:26 AM Warner Losh  wrote:

> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy  wrote:
>
> > On Fri, Aug 24, 2018 at 14:53 Ali  wrote:
> >
> > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
> > > > Just in case anyone misses the change to UPDATING:
> > > >
> > > > 20180821:
> > > > drm and drm2 have been removed. Users on powerpc, 32-bit
> > > hardware,
> > > > or with GPUs predating Radeon and i915 will need to install
> the
> > > > graphics/drm-legacy-kmod. All other users should be able to
> use
> > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
> > > > graphics/drm-next-kmod, graphics/drm-devel-kmod.
> > > > Note that this applies only to 12.
> > >
> > > I see that The removal of drm and drm2 has been reverted on svn. Could
> > > you please kindly share the reasons behind the re-inclusion?
> > >
> >
> >
> > I can’t really give the blow by blow of internal project drama, but the
> > gist of it is that “best practices” (which are not yet actually
> documented
> > anywhere that I’ve seen) were not followed with regards to the
> deprecation
> > process. Warner and others believe that we can address the objectives of
> > the drm removal (improving the user experience and communicating that
> > drm/drm2 are _completely_ unsupported apart from continuing to compile)
> > through less disruptive means.
> >
>
> Just so.
>
> Our only continued frustration is that we were never given any guidance by
> > RE or core on said “best practices” when the discussion was taking place
> in
> > May and then those groups behaved as if this were a surprise when the
> > removal happened. I’m cautiously optimistic that this well expedite
> > improving communications on those matters.
> >
>
> All the problems that are exposed by this aren't technical. This one is
> social, but no less important.
>
> Warner
> ___
> 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"
>

I've been watching this debacle for quite some time now and I'd just like
to ask why the rush?

The graphics team is working very hard to destroy the stability of FreeBSD
just so that they can force their uncooked work down users throats.

The Linuxkpi is unstable at best, alpha level software that's constantly in
need of someone to go and fix something on FreeBSD because Linux devs
decided to make some changes or implement a new feature.

This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM
Goals

   - Move DRM headers to a similar location as Linux
   -

   Use kmalloc() instead of malloc(9)
   - Use kref
   -

   Use idr and get rid of drm_gem_names.c
   - Use PCI API
   - Use Linux locking primitives

is garbage, if you want to use develop Linux code and use Linux then go do
that on Linux.

Are these guys insane and please avoid the nonsense about you're doing this
in your spare time.

If you cannot devote the resources to do something right then don't do it
at all.

Keep that stuff in to yourself or anyone crazy enough to follow those steps
to get it up and running, you guys cannot expect to contaminate the entire
FreeBSD project for this mess.

This is nonsense and I hope that more people who see it as such would say
so and stop having these guys forcing this crap; it's maintenance hell who
will maintain it if they decide to leave?

Best,
Owen
___
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: drm / drm2 removal in 12

[Warner Losh]

On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy  wrote:

> On Fri, Aug 24, 2018 at 14:53 Ali  wrote:
>
> > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
> > > Just in case anyone misses the change to UPDATING:
> > >
> > > 20180821:
> > > drm and drm2 have been removed. Users on powerpc, 32-bit
> > hardware,
> > > or with GPUs predating Radeon and i915 will need to install the
> > > graphics/drm-legacy-kmod. All other users should be able to use
> > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
> > > graphics/drm-next-kmod, graphics/drm-devel-kmod.
> > > Note that this applies only to 12.
> >
> > I see that The removal of drm and drm2 has been reverted on svn. Could
> > you please kindly share the reasons behind the re-inclusion?
> >
>
>
> I can’t really give the blow by blow of internal project drama, but the
> gist of it is that “best practices” (which are not yet actually documented
> anywhere that I’ve seen) were not followed with regards to the deprecation
> process. Warner and others believe that we can address the objectives of
> the drm removal (improving the user experience and communicating that
> drm/drm2 are _completely_ unsupported apart from continuing to compile)
> through less disruptive means.
>

Just so.

Our only continued frustration is that we were never given any guidance by
> RE or core on said “best practices” when the discussion was taking place in
> May and then those groups behaved as if this were a surprise when the
> removal happened. I’m cautiously optimistic that this well expedite
> improving communications on those matters.
>

All the problems that are exposed by this aren't technical. This one is
social, but no less important.

Warner
___
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: drm / drm2 removal in 12

[Matthew Macy]

On Fri, Aug 24, 2018 at 14:53 Ali  wrote:

> On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
> > Just in case anyone misses the change to UPDATING:
> >
> > 20180821:
> > drm and drm2 have been removed. Users on powerpc, 32-bit
> hardware,
> > or with GPUs predating Radeon and i915 will need to install the
> > graphics/drm-legacy-kmod. All other users should be able to use
> > one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
> > graphics/drm-next-kmod, graphics/drm-devel-kmod.
> > Note that this applies only to 12.
>
> I see that The removal of drm and drm2 has been reverted on svn. Could
> you please kindly share the reasons behind the re-inclusion?
>


I can’t really give the blow by blow of internal project drama, but the
gist of it is that “best practices” (which are not yet actually documented
anywhere that I’ve seen) were not followed with regards to the deprecation
process. Warner and others believe that we can address the objectives of
the drm removal (improving the user experience and communicating that
drm/drm2 are _completely_ unsupported apart from continuing to compile)
through less disruptive means. I am only acting as a lightning rod and
representative of the graphics team and so have done an inadequate job of
tracking their activities with respect to project timelines. As a result of
this misunderstanding Johannes Lundberg will be sponsored for a bit and
will be able to be involved in internal discussions that impact his work.

Our only continued frustration is that we were never given any guidance by
RE or core on said “best practices” when the discussion was taking place in
May and then those groups behaved as if this were a surprise when the
removal happened. I’m cautiously optimistic that this well expedite
improving communications on those matters.


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: drm / drm2 removal in 12

[Ali]

On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote:
> Just in case anyone misses the change to UPDATING:
> 
> 20180821:
> drm and drm2 have been removed. Users on powerpc, 32-bit hardware,
> or with GPUs predating Radeon and i915 will need to install the
> graphics/drm-legacy-kmod. All other users should be able to use
> one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
> graphics/drm-next-kmod, graphics/drm-devel-kmod.
> Note that this applies only to 12.

I see that The removal of drm and drm2 has been reverted on svn. Could
you please kindly share the reasons behind the re-inclusion? 

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

drm / drm2 removal in 12

[Matthew Macy]

Just in case anyone misses the change to UPDATING:

20180821:
drm and drm2 have been removed. Users on powerpc, 32-bit hardware,
or with GPUs predating Radeon and i915 will need to install the
graphics/drm-legacy-kmod. All other users should be able to use
one of the LinuxKPI-based ports: graphics/drm-stable-kmod,
graphics/drm-next-kmod, graphics/drm-devel-kmod.

Note that this applies only to 12.

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