For now I've 'solved' my joystick problem via getting a diferent, working joystick.

jstest-gtk shows numbers on two axes running from 0 to -32000

and [hid] gives me the same inputs, 'abs_x' and 'abs_y' as numbers in the range 0-256.

WIth jstest the numbers naturally take some big jumps, but seem consistent with the joystick motion.

With [hid] the values jerk about fairly randomly -- These are maybe the original numbers mod 256 of something?

Is there anything available to bring in the original raw data so I can put it into more linear order?

As usual, having to find out my own answers... Some of my thrift store joysicks were simply clunky, some were lacking the right gameport->usb converter. With that fixed, the numbers are reasonably steady and the main problem is using them to move a gui pointer of some sort.

Best so far -- Make a [canvas] and tinker with the properties to have it [say] receive messages as something like 'joyrcv' Then, hook your |hid| outlets to |route abs_x abs_y etc] into a message like
| ; (
| joyrcv pos $1 $2 (

and your canvas will move to the coordinates from the joystick every time you trigger that message. Also, while you're changing the properties, you can color code the canvas and shrink it to a nice portable size like 3X3. Can also make the message read:
;
joyrcv delta $1 $2 -- to simply move that canvas relative to its current position. But to use that I'd need to convert the numbers to a different range, like say dividing and subtracting to get them into low negative, 0, and low positive values.

You can take a look a my patch for HID to XYZ that i use for moving gem textures. It is still in development, but may give you some starting points.
hid_xyz.pd

I use a Xbox 360 Controller. The Left Stick is mapped to X/Y and RT/LT are mapped to Z. Nothing more is currently used.

@az Well, audio is messy enough and I can't get csoundapi to work on my 64 pd-extended, so I'm unlikely to be using gem.

But it looks somewhat like what I'm getting to...

movething.pd

Main trouble with that: Sending 'delta $1 0' too seldom makes for slow response; too often loses my little wandering cvn "cursor" somewhere off-screen. Still tinkering with this.

@forrest As someone else was asking about on another thread:

You can easily crash your pd if you haven't fed the right numbers into the number box[es -- (One for every joystick one's prehensile toes may be working)] I'm using to open the [hid] ...

So for anyone seriously using the patch I just sent -- unless you're using two sticks you can get rid of much of it. And then (because the system may well assign different numbers the next time you boot) -- First run:

{print(
|
[hid]

to get the right number[s]

@forrest There's still a bug in this patch... constant acceleration, no wonder I lose my cursor.

Anyway, more later.

The bug in the logical design: it should have been like this:
cursormv.pd

The whole patch (so far): movething.pd

If you have performance issues, i suggest using [f] objects instead of number boxes. For monitoring purposes i found it useful to have a switch to output numbers in boxes. As your patch grows this will always be a factor, since GUI updates are quite CPU-heavy.

[route abs_x ...]
|  
|     &#160;           [X] <- monitoring
[ f ]   [spigot]       
|        [0.123\ <- number box