I haven't looked at dragonfly I saw a few talks from the FreeBSD guys and it seemed like the main reason for dragonfly was misguided. I am interested in solving the problem within the constraints set fourth by FreeBSD so I won't be forking anything. I might look at that project though. I think the correct way to say it is that if Gallium and AMD conform to the open standard they should work with KMS and the likes. It'll be hard to go and try to talk to them with nothing to show them and hoping they'll support; that'll only happen in a perfect world. You came back to BSD after some work was done, I doubt you are the only person out there who would like to return. Companies follow the money, let's make FreeBSD attractable so that the customers come and that will bring the support from the big players. Right now we are paupers begging and picking up scraps from linux table. Not only that, since they are the loudest voice in the room right now, they will try and push these things in ways that might not be beneficial for BSD. I cam to BSD because I got tired of debian being too outdated, opensuse doesn't let me not have a DM and fedora w/o gnome might as well be a brick. All of that started because of sysemd so I have no choice but to do what I can to improve things over here. Best, Owen On Tue, Jan 3, 2017 at 6:55 PM, Johannes Lundberg <johalun0_at_gmail.com> wrote: > Isn't that the way it was done before and is done on DragonFly? > > Don't forget, linuxkpi also supports AMD and Gallium drivers.... > > It is a complex subject.. in a perfect world we'd have unlimited time and > resources and FreeBSD would be in every man's hand :) > > Good luck! > > On Tue, Jan 3, 2017 at 18:50 blubee blubeeme <gurenchan_at_gmail.com> wrote: > >> It's understandable and I actually came across your twitter account a >> long time ago before I joined this list. >> >> I did look at intels open source gpu drivers. I will be attempting after >> a smaller project to get it up and running on BSD without using the linux >> wrappers. Crazy, I know but nothing tried nothing done and I'm stubborn >> enough to do the work now to have an easier time later. >> >> This is a pretty complex subject and it does touch so many different >> things that are all trying to change, the complexity is pretty high. >> >> We'll see if we can sort that out. >> >> Best, >> Owen >> >> On Tue, Jan 3, 2017 at 6:45 PM, Johannes Lundberg <johalun0_at_gmail.com> >> wrote: >> >> Hi >> >> Not sure about the other graphics drivers but porting a driver like >> drm/i915 for Intel graphics is a massive undertaking (look at the source >> code from Intel!). Intel develops their open source driver for Linux and >> having linuxkpi reduces porting efforts for us from a full time job to a >> few weekends / year. Remember how we had to wait 5 years for Haswell >> support? That's the only reason I had to run Linux for several years >> instead of FreeBSD (and a lot of development time went into Linux just >> because of that, wasted). linuxkpi and friends will be optional, you don't >> have to use if you don't want to. >> >> I'm all for a BSDish system with X & Wayland compositors and GUIs and the >> whole package. But, who's gonna have the time to develop/maintain it? What >> happens when we no longer can run Qt/GTK applications and only a small >> subset of BSD-friendly apps? >> >> I agree with what your saying, but we have to be realistic. Adding >> optional wrapper/support in the kernel plus a thin userland layer like udev >> or epoll etc, does not "taint" FreeBSD in anyway, rather it allows us to >> use newer hardware and a larger set of software with minimal porting >> efforts. >> >> On this project? Not many, we need a lot more. >> >> >> On Tue, Jan 3, 2017 at 6:15 PM, blubee blubeeme <gurenchan_at_gmail.com> >> wrote: >> >> Hi Johannes >> >> I was asking about the current state of those three main items. >> >> I just looked at the linuxkpi thing and it's a wrapper around the linux >> version of DRM but isn't DRM a open standard, if we keep chasing down linux >> the more they move their stuff into their kernel the harder it will become >> to maintain these things on FreeBSD even though it might be more work >> upfront? >> >> It seems like evdev is the same story, xorg was moving to libinput, I >> believe. >> >> Is there a reason why we have to wrap the linux things and why couldn't >> we just write our own that can then be tied closely to the BSD kernel while >> still sticking to the standards. >> >> To be honest I don't have the slightest idea how massive GEM, KMS and DRM >> are just yet but it seems like adding a wrapper around another OS kernel >> into that mix can only go bad. >> >> How many people are working on the project with you at the moment? >> >> Best, >> Owen >> >> On Tue, Jan 3, 2017 at 5:42 PM, Johannes Lundberg <johalun0_at_gmail.com> >> wrote: >> >> Hi Owen >> >> I've been helping out with drm, i915, linuxkpi and evdev in the kernel. >> >> For userland I'm working on Wayland-related stuff. >> >> You can check my twitter (_at_johalun) or this mailing list for my earlier >> posts about how to use this work. >> >> Sorry for asking but exactly what is your question now again? >> >> >> On Tue, Jan 3, 2017 at 16:58 blubee blubeeme <gurenchan_at_gmail.com> wrote: >> >> Howdy >> >> >> >> Is there anyone on this list that works on the graphics stack for FreeBSD? >> >> >> >> Watching this video: https://www.youtube.com/watch? >> v=dZI4pAvK_RY&spfreload=5 >> >> >> >> from a few years ago and what I've gathered so far the new x is getting a >> >> major redesign and a lot of code is moving into the kernel. >> >> >> >> You can take a look at the attached images to get the tl;dr of the talk. >> >> >> >> http://imgur.com/a/Ek4fq >> >> >> >> My question, is anyone here whose doing graphics stack work done any work >> >> on implementing GEM, KMS, DRM in the FreeBSD kernel. >> >> >> >> Even a port of the linux version would be somewhere to start. >> >> >> >> Best, >> >> Owen >> >> _______________________________________________ >> >> freebsd-current_at_freebsd.org mailing list >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org >> " >> >> >> >> >> >> >> >> >> >> >> >> >>Received on Tue Jan 03 2017 - 10:05:02 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:09 UTC