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_f >>> reebsd.org" >>> >>> >Received on Tue Jan 03 2017 - 09:45:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:09 UTC