And it's basically a new port, nothing is common with the old one so I would just copy paste my own Makefile over the old one.

@zeising You mean reverted? There's a lot going on in that commit https://svnweb.freebsd.org/ports?view=revision&revision=418057

Remove devel/acme entry from MOVED where it's reported BROKEN.

Apply reviewer suggestions

Improve strlen safety checks.

Check if strlen=0.

Having to specify each source and header file seems like a huge maintenance burden. For every update in Linux version files get added, removed and renamed. Some sort of recursive directory install would be nice...

hm. EVDEV_SUPPORT enables evdev in "legacy" drivers like psm, ums, ukbd etc. I'm not sure why @johalun added ifdefs for that here, this is a new driver :)

I've been playing around with it here https://gist.github.com/johalun/ffc271a07a0cf50d0bc816138c4eec81 but still no success. Basically there are no interrupts from the device after resume. I don't know if this is because ig4 or the i2c device missing some kind of reset command. I found something in MS docs about sending an i2c reset command which you can see in the resume function but it doesn't do anything which makes me think that ig4 is the problem. Here I simply copy/paste the routine from the attach function to resume but not sure that's enough. Probably need to spend some times reading reference manual for the devices.

Also bump freebsd version so we can have a checkpoint from where the virtualbox drm driver builds.

Add () where needed. Make sure define is followed by a tab.

Move up ONLY_ARCHS in Makefile and set myself as creator of the file.

Fix build by reversing dependencies. Limit build to amd64 and i386.
Build test OK for both archs with poudriere.

Can you MFC to stable/12 as well?

Elegant solution! I will ponder a bit over where's the best place to declare LINUXKPI_VERSION in the DRM repo. The best of course would be to have it in one single place, like the root makefile since both drm drivers and linuxkpi_gplv2 depends on it and there's no guarantee that a certain linux header is always included.

I want the same behaviour for both 4.16 and 5.0, so this doesn't quite work: as far as I can see, 4.16 doesn't define LINUXKPI_VERSION.

I'm guessing we would also have to revert this recent fix https://github.com/FreeBSDDesktop/kms-drm/commit/4d4b2baf9cbc22588fd379e158c717030bce0d29 ?
We could use LINUXKPI_VERSION if you want to do something like this:

In D18041#440083, @hselasky wrote:

Is this patch still relevant?

Take ownership over fs-uae as per agreement with maintainer.

Update diff, include full context.

Abandoned in favor of D20064

Run portfmt

Update distinfo to fix error after changing version.

Everything committed!

Clean up diff

Rebase r347628

Rebase at r347620

Check LINUXKPI_VERSION before declaring IS_ALIGNED (declared in gplv2 code for < 5.0) macro to avoid build error with older out of tree code.
Use function macro for get_random_u32 as suggested by reviewer.

Rebase after committing r347470

Driver does not work after resume. I had to reboot to get working touchpad again.

Fix Makefile according to comments by reviewer.

Change from slave port to separate port.

Rebase r346712

Re-open.

Rebase

Use LINUXKPI_VERSION macro to check what KPI version the client expects, as per discussion. Any code that uses LinuxKPI will define this. We will support at most 2 versions concurrently and it is recommended that that any code that depends on LINUXKPI_VERSION < 50000 is updated to most recent version.

Here's preliminary evdev support. Can you please incorporate it into your patch?
https://gist.github.com/johalun/3c67a678e740b82512cec52bfe926092