"B. Douglas Hilton" wrote: > > center point with ministicks which are becoming the de-facto standard for game pads. What is needed > is a cubic transform like this: > > f = pow( x / 32768, 1/3 ) * 32768 I guess one could add this into the kernel-sources for now. also, I guess something like (x*32768^2)^1/3 would be faster and more accurate... > > scrutinizing the gpm code. An important aspect is we only want to filter joystick axes, but not hat > axes, and not button presses or dial events. Also, maybe the user would only want to filter one or > two axes. well, I do have such a gamepad, but there aren't much linux-games actually making use of the analogue-capabilities. much more interesting would be to alter other joystick-behaviour, like adding new buttons (i.e. assigning a new button-name to some button-axis combinations), making axes less square but round instead (i.e. diagonal movement should not result in min(x,y) but in (x^2+y^2)^1/2 for treshhold and dead-zone calculations), make movement more smooth, and so on. > > I have subscribed to the list in the meantime while I investigate this project. I think you guys > could do something like this easy, and I think that your mouse repeater technology is highly > appropriate for this. I'm new here too, but I do not think gpm is the right place. it would be nice to turn my mouse into a joystick (for example for some space fighting games for people who are used to playing the wing-commander series with the mouse), and it would be nice to transform some joystick-axes into additional buttons (for example transforming the analogue throttle-control into the 4 buttons used for full, 3/4, 1/2 and 1/4 speed), but considering the lack of such games in linux I would rather start out with joy2key or sdl or something, than actually producing joystick-signals. it would be great if the game-programmer would offer a list of functionality which can be triggered through the input-device, and which functions collide with other functions, and then leave the configuration to some external program. (for example you just can't jump and crouch at the same time in most games so if the configuration-program knows that 2 buttons are handled with the same finger it might assign those functions to those buttons. another example would be assigning one button to 2 functions, like for example swimming up and jumping on the same button since you can't jump under water...) such a thing would be far beyond any gpm-alike program. also, it could be that some users might think that your axis-transformation should be defined on a per-game basis, as maybe some games would do the same thing on their own... what would fit into gpm is better control over mouse-speed, but even that is handled externally by vgalib or X. I think the future of GPM should be on the console with menues, paste-history, adding keys to the queque, displaying info and executing root-commands. I would wish better support for new mice in gpm, with all their buttons and wheels getting an own functionality, and better configurability of buttons and such. as the repeater-protocol I'm using "raw" anyway... a gpm-alike utility for joysticks would only make sense if it could offer the same additional functionality on the console. selecting and pasting with the joystick is too difficult with gpm, some improvements might be neccessary there. the joystick does have more axes than a mouse, or at least more buttons. for example I could imagine some more keyboard-alike handling of selecting text with a joystick where some buttons or hat-axes would move the cursor, some other buttons might select or act as a modifyer for selecting, some other button might be a modifyer for going back or forward by whole words or sentences, and so on... P