In D20724#449198, @mat wrote:

In D20724#449167, @zeising wrote:

In D20724#449059, @mat wrote:

I think you are trying to put really too much magic in xorg-cat.

I am merely replicating the functionality that was in bsd.xorg.mk. All of this is in the old bsd.xorg.mk, and there it works. bsd.xorg.mk is only pulled in from bsd.ports.mk if USE_XORG or XORG_CAT is defined, perhaps it is better left this way, rather than converted to USES?

Save for the generic framework files, nothing should be left as a bsd.*.mk file, everything should be moved to a USES. The move is better if it is done by someone who actually understands what the file does.

In D20724#449170, @tijl wrote:

I found two ports with USES=autoreconf and XORG_CAT: x11-drivers/xf86-input-egalax and x11-drivers/xf86-video-intel. The former isn't maintained by x11@ and is fetched from github. If such non-X.org ports are allowed to use XORG_CAT then they may be fetched from gitlab and not need autoreconf for instance, so you cannot include autoreconf.mk. If XORG_CAT is only meant for X.org ports and use by other ports is unsupported then you can keep the libtool.mk and autoreconf.mk includes (as in 9e63b55 but without " || ${USES:Mautoreconf}") and for special cases like x11-drivers/xf86-video-intel you can add "USES= autoreconf libtool" to the port Makefile instead of just USES=autoreconf.

In D20724#449059, @mat wrote:

I think you are trying to put really too much magic in xorg-cat.

In D20724#449034, @tijl wrote:

I think the problem is you are including autoreconf.mk before setting libtool_ARGS. Try moving "libtool_ARGS?= #empty" to right before each libtool.mk include (there are two) so it's only defined if libtool is used. Then include autoreconf.mk if "USE_GITLAB && BUILDSYS == autotools" right after ". endif # ${_XORG_CAT} == <category>".

Update patch again.
Move things around in Uses/autoreconf.mk to check for libtool things later. Uses/autoreconf.mk checks if libtool is being used, by checking libtool_ARGS, and if it's set, add a dependency on libtoolize. Move this check later, in the POSTMKINCLUDED phase, to avoid issues where we're hitting autoreconf before setting libtool_ARGS, and then not bringing in libtoolize.

Updated diff based on comments from @mat

In D20732#448839, @mat wrote:

In D20732#448816, @zeising wrote:

In D20732#448815, @mat wrote:

Could you also add documentation for USES=xorg-cat?

I purposefully omitted it, since it is supposed to be internal to xorg ports, not used by other ports, similar to qt-dist.mk.

Mmmm, I do not understand, you mean I'll have to document it myself when the other review hits the tree? All USES have to be documented, otherwise, the only one who knows how it works is you, so, the bus factor is 1, and it is very bad.

In D20732#448815, @mat wrote:

Could you also add documentation for USES=xorg-cat?

Updated based on comments from @tobik .

In D20724#448218, @kwm wrote:

This porters-handbook chapter needs to be updated/rewritten, maybe there are other bits elsewhere in the porters-handbook that also need attention.
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/using-x11.html

Thank you very much for the review @tobik !
I think I've fixed everything, I'm just going to do a local smoke test, and then I'll update the patch in phabricator as well.

Some notes about the patch: Uses/xorg.mk and possibly Uses/xorg-cat.mk will be copied from bsd.xorg.mk using svn cp or svn mv as needed. Current patch is pulled from our git repo with rename detection turned off when generating the patch.

LGTM

Updates based on comments from @imp and some wordsmithing.

One minor nit, otherwise you're good to go.

Fixes based on comments from @bcr .
mandoc -Tlint complains a lot about useless macro: Tn for all the .Tn PCI. This style is all over the file, and should probably be changed in a separate pass.

I assume you've run it through poudriere to ensure it builds and packages OK.
should libxatracker be made amd64 and i386 only? I assume it's only relevant for those architectures.

I think editing xf86-input-mouse is the better option as well.

In D20507#442998, @phascolarctos_protonmail.ch wrote:

In any case, libinput list-devices does not return any output.

In D20507#442964, @jan.kokemueller_gmail.com wrote:

This was tried some years ago, but then reverted as the probing was deemed too intrusive (see r255152 and r255210). I don't know if something changed in the meantime.
I've had "synaptics_support" and "trackpoint_support" enabled for years on my Thinkpads without problems though.

This is for current only, where changes to the drivers has been made as well, and evdev is the default. Which version of FreeBSD are you using? Can you provide logs, and output from libinput list-devices.

Also enable trackpad support by default.

This has been running fine during the night. From a graphics drivers no apparent regressions are visible, from light testing.

Running the latest version of this patch on top of r347562M.
Machine boots and graphics comes up no problems, this with the built in Intel graphics in i7-3520M.
I'll leave the machine running during the night, in case something happens.

What is remaining in this review?

I'll give this a spin and look for regressions in graphics land, but it might take a day or two. Can you add x11 as group reviewer?

This is still running fine from a graphics perspective.
DRM has been broken for some time now, what's needed to get this in?

I've been running the new version of the patch for about 2 hours without any graphics issues. I'll let the computer run through the night.

I've had further success stories graphics wise, and my laptop is still running, so from a graphics perspective, this is good to go.

I've been running this for about 8 hours, on a mostly idle laptop with Firefox running, so far so good. I would like to give the reporters on the mailing list some time to test as well, since the hang is very random (I might have been lucky). I'll keep running the patch though.

Hi!
Is this related to the recent graphics GPU hungs, or is this another issue?
Just checking so that I know what to look for.

In general, I'm not sure -devel ports are usually slave ports, slave ports are more often to have ports with different options, such as nox11 variants. You also need to check with the owner of the original port for approval, since you're touching that one. You also need do add CONFLICTS since I assume both ports can't be installed at the same time (installing things in the same place).