The HAL configuration for the Logitech gamepad has only a few changes from the decade-ago (!) version.
The HAL driver will reverse the direction of the Y and Z axes by feeding -127.5 to the scale
inputs:

The flat
inputs make sure the joystick knob has a dead zone around the rest position; otherwise, the axes tend to crawl off without a hand on the controls.
The gamepad doesn’t emit any values until you poke a button or move a joystick, the driver starts up with all zeros in its counts
registers, so the HAL axis position
pins emit XYZA = -1 +1 +1 -1 just as if you had the joysticks jammed hard at their upper-left corners. The only way out is to squelch the joystick until a button gets pressed and the machine is turned on:

The Gamepad-Valid signal forcibly disables all four axes:

That’s from an earlier iteration of the axis priority logic, before I got the Kicad annotate-starting-at-100 code working.
I somewhat finessed the startup issue by dedicating two of the gamepad’s back-panel buttons to clearing the initial E-Stop and turning the machine on:

However, if you flip those two conditions with the LinuxCNC GUI, the joysticks will remain zeroed until you do poke a button or move a knob. So, without the Gamepad-Valid
logic, the Sherline will take off for the far upper left corner at a pretty good clip, which is not what you want.
The gamepad outputs remain valid for the rest of the session, so there’s no need to reset the Gamepad-Valid
flipflop. HAL does not take kindly to hotplugging USB devices, so (AFAICT) you can’t hard-reset the gamepad + driver to the initial no-data-yet condition.
Earlier versions of the top two schematics used CONSTANT symbols, but it turns out PARAMETER symbols work just as well and the resulting setp
commands eliminate the need for nets and real time functions.