shipit!

In D58753#1350996, @adrian wrote:

In D58753#1350991, @nick_spun.io wrote:

In D58753#1350915, @adrian wrote:

(a) what was this for again
(b) .. why can't we have a freebsd dmabuf implementation that we can use, and linuxkpi plugs into that?

(a) lol this was for Cyberpunk 2077 in "Proton-under-Linuxulator"
(b) You mean something in base? I definitely don't see a reason _not_ to

ok, for maximum lols, please add something like this in your commit message

Locally tested:

• cyberpunk 2077 running in proton in linuxulator (still working on audio though!)

and (b) yeah, let's find dumbbell when they're active on IRC and go figure out what's required to just make a native dmabuf implementation for freebsd. Surely it's not going to move THAT quickly, and it'll help us in our desire for native drivers for stuff.

I didn't work on the implementation of dma-buf for FreeBSD. We have this BSD-licensed implementation in drm-kmod right now and we can surely move that to base. I find it receives changes infrequently in Linux, so hopefully, that shouldn't be something that slows down or interferes with making a given version of drm-kmod compatible with multiple versions of FreeBSD.

In D58753#1350991, @nick_spun.io wrote:

In D58753#1350915, @adrian wrote:

(a) what was this for again
(b) .. why can't we have a freebsd dmabuf implementation that we can use, and linuxkpi plugs into that?

(a) lol this was for Cyberpunk 2077 in "Proton-under-Linuxulator"
(b) You mean something in base? I definitely don't see a reason _not_ to

In D58753#1350915, @adrian wrote:

(a) what was this for again
(b) .. why can't we have a freebsd dmabuf implementation that we can use, and linuxkpi plugs into that?

well if dumbbell says ok :-)

(a) what was this for again
(b) .. why can't we have a freebsd dmabuf implementation that we can use, and linuxkpi plugs into that?

maybe condition to the presence of /usr/bin/tic considering that it does not exist in FreeBSD 13 and it won't be MFCed

Judging by the mailing list, these instructions not being in here are causing problems. I will commit this tonight when I get home.

Thanks @bcr! One thing I've been struggling with is I'd like to tell them but haven't liked anything I've come up with is "hey check the version of the package and make sure it matches the version of the kernel".

I've found two small nits. The rest looks god enough to commit I would say. As mentioned by others, we can always fix other things found in a followup commit.

Committed as e86781da6b600e8096a42a6f44b2b7f97ff08251

I've been hacking on this a while, here's what I've got so far.

One problem that keeps me from wanting to merge this, is that the Xorg FreeType Module has not existed in at least 15 years, but I can't really find any information about that to rewrite the relevant areas.

I think you can commit it, if there's an improvement, we can change it later.
Thanks for all the improvements.

Thanks Jim, these are all great!

A few minor edits. Good job on this section.

Here's my current draft, I am not suggesting this is mergable currently,
maybe parts of it are, but here's just what I've got so far in case
anyone is interested in this issue.

Some language and typo fixes.

Next revision will include increased detail about fonts and configuring touchpads with libinput, however I am really hoping to fix this problem at what I perceive to be the root with upstream manpage.

Fixed xrefs

Additional attempting to clarify more of the instructions. It's still WIP, but appreciate any general feedback.
Thanks @bcr for showing me the testing instructions! Proofreading the rendered output is massively easier!