CrossOver Support - Community Forums

I couldn't find any better place to post this - oh beloved ninjas! Give this naive a scratchpad!!

This is my current rundown on the linux HID (human interface devices) situation, relative to
the crossover-games situations and the games titles that can/use things like joysticks etc etc...

Mouse and keyboard always work mostly, sometimes a 8 buttoned mouse would be handy...

Firstly -- the game title itself => be considerate of the fact that many (older) game titles,
may have only ever been programmed for keyboard/mouse/analog|digital joysticks...(the ones
that used to plug into your 'gameport' on older model soundcards/mainboards). This was of
course long before the advent of the USB ports. Although 'certain measures' are taken into
account within the linux driver codes here, to offer some form of 'backwards compatibility'
with older style HID events, YMMV wildly depending on what the actual game itself, is coded
to understand....ie; an axis of RX-yaxis is complete nonsense to some games. With this in
mind, and sometimes in very extra-ordinary cases, you might find a game *.ini file you can
manually edit to accept different event names...again, YMMV and luck required...

Note: [u]You'll need get/install the linux joystick-tools package for this lot below. Most
mainstream distros have a package for such.[/u]

0. 'Standard' 2 axis / 4 button / HAT / throttle-wheel gameport joystick. I've not had any
   issues with these at all, except in some cases where the button functions aren't mapped
   the way I'd like them - you can change this by reading this test.

1. Same as above, but USB connected. Not as good responsive wise compared to the above,
   a bit too abrupt or quick...hard to explain. If you can lower the sensitivity in the
   game options themselves, that helps.

[todo: cal procedure]

2. Hardware-hacked Xbox 360 gamepad -- usb-debug is throwing useful but cryptic messages
   about the device not accepting device enumeration blablablah. I haven't checked the code,
   but this might be (in english) "how dare you plug me into a USB-2.0 port!"....

3. Logitech 'Precision' USB gamepad. This thing works - type the following, you should see;

bash-3.2$ jstest /dev/js0

Driver version is 2.1.0.
Joystick (Logitech Logitech(R) Precision(TM) Gamepad) has 2 axes (X, Y)
and 10 buttons (Trigger, ThumbBtn, ThumbBtn2, TopBtn, TopBtn2, PinkieBtn, BaseBtn, BaseBtn2, BaseBtn3, BaseBtn4).
Testing ... (interrupt to exit)
Axes: 0:-32767 1:-32767 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off

You can press buttons and fool with things to familiarize yourself with the control layout. Once finished,
hit Crtl-C to quit jstest. Now, you have to (auto) calibrate the device - type the following ;

bash-3.2$ jscal /dev/js0

Joystick has 2 axes and 10 buttons.
Correction for axis 0 is broken line, precision is 0.
Coeficients are: 112, 142, 5534751, 5534751
Correction for axis 1 is broken line, precision is 0.
Coeficients are: 112, 142, 5534751, 5534751

That's it! Now start your game of choice, go into the game's options menu, and setup things
to your likings.

4. 'GT-4' Boxxer Steering wheel/pedals/gearshift/handbrake unit. Built for PS/PS1/PS2 but
   comes with PS=>USB adapter (and windows driver disc) for PC use. The linux USBHID driver
   interprets the situation thusly ;

bash-3.2$ jstest /dev/js2

Driver version is 2.1.0.
Joystick (USB Wheel ) has 7 axes (X, Y, Z, Rx, Ry, Hat0X, Hat0Y)
and 12 buttons (Trigger, ThumbBtn, ThumbBtn2, TopBtn, TopBtn2, PinkieBtn, BaseBtn, BaseBtn2, BaseBtn3, BaseBtn4, BaseBtn5, BaseBtn6).
Testing ... (interrupt to exit)
Axes: 0:-32767 1: 0 2: 0 3: 0 4: 0 5: 0 6: 0 Buttons: 0:off 1:off 2:off 3:off 4:off 5:off 6:off 7:off 8:off 9:off 10:off 11:off

The unit has 3 different modes of operation - Digital | Analog | Race

There is currently no possible way for me to post the amount of data jstest
spews out here with this device, nor show you how/what the relative modes
do to the mapping layouts/values once selected.

A jscal run looked something like this ;

bash-3.2$ jscal -c /dev/js2
Joystick has 7 axes and 12 buttons.
Correction for axis 0 is none (raw), precision is 0.
Correction for axis 1 is none (raw), precision is 0.
Correction for axis 2 is none (raw), precision is 0.
Correction for axis 3 is none (raw), precision is 0.
Correction for axis 4 is none (raw), precision is 0.
Correction for axis 5 is none (raw), precision is 0.
Correction for axis 6 is none (raw), precision is 0.

Calibrating precision: wait and don't touch the joystick.
Done. Precision is: 127, 128 Axis 4: 127, 128 Axis 5: 0, 0 Axis 6: 0, 0
Axis: 0: 0
Axis: 1: 1
Axis: 2: 1
Axis: 3: 1
Axis: 4: 1
Axis: 5: 0
Axis: 6: 0

Move axis 0 to minimum position and push any button.
Hold ... OK.
Move axis 0 to center position and push any button.
Hold ... OK.
Move axis 0 to maximum position and push any button.
Hold ... OK.
Move axis 1 to minimum position and push any button.
Hold ... OK.
Move axis 1 to center position and push any button.
Hold ... OK.
Move axis 1 to maximum position and push any button.
Hold ... OK.
Move axis 2 to minimum position and push any button.
Hold ... OK.
Move axis 2 to center position and push any button.
Hold ... OK.
Move axis 2 to maximum position and push any button.
Hold ... OK.
Move axis 3 to minimum position and push any button.
Hold ... OK.
Move axis 3 to center position and push any button.
Hold ... OK.
Move axis 3 to maximum position and push any button.
Hold ... OK.
Move axis 4 to minimum position and push any button.
Hold ... OK.
Move axis 4 to center position and push any button.
Hold ... OK.
Move axis 4 to maximum position and push any button.
Hold ... OK.
Move axis 5 to minimum position and push any button.
Hold ... OK.
Move axis 5 to center position and push any button.
Hold ... OK.
Move axis 5 to maximum position and push any button.
Hold ... OK.
Move axis 6 to minimum position and push any button.
Hold ... OK.
Move axis 6 to center position and push any button.
Hold ... OK.
Move axis 6 to maximum position and push any button.
Hold ... OK.

Setting correction to:
Correction for axis 0: broken line, precision: 0.
Coeficients: 1, 1, -2147483648, -2147483648
Correction for axis 1: broken line, precision: 1.
Coeficients: 128, 128, -2147483648, -2147483648
Correction for axis 2: broken line, precision: 1.
Coeficients: 128, 128, -2147483648, -2147483648
Correction for axis 3: broken line, precision: 1.
Coeficients: 128, 128, 4194176, 4227201
Correction for axis 4: broken line, precision: 1.
Coeficients: 128, 128, -2147483648, -2147483648
Correction for axis 5: broken line, precision: 0.
Coeficients: 1, 1, 268427264, -2147483648
Correction for axis 6: broken line, precision: 0.
Coeficients: 0, 0, -536854528, -536854528

This was done with the thing set in 'analog' mode. Most of the
'magic' here is working out exactly what Axis number relates to
which actual control...ie; Axis 1 actually maps to the brake
pedal for instance, other axis maps to HAT type pad, you'll
have fun setting this one up.....

When I get some sane approach happening, I'll add more, but it
=should= try to work in linux.

Cool, good information here.

Just as a note I have done work to enable gamepads on the mac as well. So much of this work will also translate to the mac as well.

Another note is that gamepads/joysticks (linux and Mac) will only currently work on games programed for direct input (dinput). More modern games which want xinput will not see or be able to use joysticks yet.

-aric

this is great stuff. but what games, say the years between XXXX and XXXX would they be.

or would it basically be ones that can run on vista as well as xp will not run on mac COG?
i am basically trying to get far cry to work with a gamepad, but does not seem to work.

thanks for this great update though :)...

lewis

Posted:

this is great stuff. but what games, say the years between XXXX and XXXX would they be.

Well, understand this is very much one of my 'pet' work-in-progress type meanderings,
and nowhere near complete/finished. The first USB-1.0 standard was introduced in 1996, and
followed with USB-2.0 in the year 2000. I'm not sure where USB-1.1 fit into the picture,
but you can have a read about all this here.

Regarding games titles themselves....that's a hard one. Adaptation of USB based HID controllers
was slow to take off, and so us average users didn't start to see many such things on store
shelves until 2000 and beyond, and game developers knew this as well obviously. Any game
prior to 2003 would be my guess, and any game after 1995 probably fits the bill. Games
produced =after= 2003 are likely...as Aric indicated...to use xinput instead (although some
may still support the dinput layer stuffs).

Remember also, a lot of this is very game specific in practice. For example, take
Rollcage Stage II -- it supports an analog/gameport connected joystick "beautifully" (I
mean that, it actually works better in crossover/wine/linux than on a real 'doze box ;),
but getting...say...a USB gamepad to work with it, requires 'extra jellybeans'. Aric has
already mentioned dinput.dll --- in the Rollcage Stage II instance, you actually need
dinput8.dll -and- set this to 'native' in winecfg - hey presto, USB gamepad works.

Due to the existence of that one example, I just know what's going to happen next -- I
am going to have to test/check/play/adjust/winecfg/dll_mangle/hold my tongue just so...
for all my driving sim titles to discover what does and what doesn't work, and what you
need to do to get things working...work in progress, wip, WIP, WIP!!! PIT NOW !!...

This thread, is my scratchpad of notes so related, which -may- give Mac users a decent
enough hammer to have a swing at things with -- any fixups/work-arounds/magic chants
related to any specific game title, will appears in it's related C4 tips&tricks...

...damn that AI driver!!!...I clearly had A-pillar advantage going into that corner..Flatout
with gamepad 😉

ps: Flatout will be the first title I get finished, because it SOOOO lends itself to
really fun gamepad play ;-]

thats great stuff thank you for that information.

no, i was not asking for ALL the titles :). but was wondering in what year to year stage they would of been in for dinput. but thank you for that rough estimate :)

ah ha, so dinout8.dll ehhh?. i may have a looky cook at that then. see if i can get some shenanigans going. actually, just so i dont bugger COG. how would i go about installing dinput8.dll in COG 8 [crossover games 8]. i should ask people who know rather than jumping in and possibly buggering it. or is it by going into the manage bottles/control panel/add,remove software?

thanks for the info, muchos helpo...

lewis

=BIG=NOTE= about mouse weirdness/warping

Yes...mice are HIDs too....

In some games using crossover-games/linux, you may suffer from a mouse-warping effect
(mouse pointer leaves the window causing loss of focus/game control, inability to do
a full 360degree turn in games etc etc), and enabling the 'allow directx apps to grab
mouse' function in winecfg doesn't help at all.

I have it on good authority, a lot of this problem is related to the linux Xserver's
input-dev-layer driver, which is yet to support the so called 'xinput2' protocol, which,
once in the main X tree, should help/fix these issues here. Apparently, this fixup is
in the X GIT tree, so it shouldn't be too far away from making it mainstream.

Until then, try and stay sane....(at least, as sane as I am here ;)

Lewis G. Edwards wrote:

thats great stuff thank you for that information.

no, i was not asking for ALL the titles :). but was wondering in
what year to year stage they would of been in for dinput. but thank
you for that rough estimate :)

ah ha, so dinout8.dll ehhh?. i may have a looky cook at that then.
see if i can get some shenanigans going. actually, just so i dont
bugger COG. how would i go about installing dinput8.dll in COG 8
[crossover games 8]. i should ask people who know rather than
jumping in and possibly buggering it. or is it by going into the
manage bottles/control panel/add,remove software?

thanks for the info, muchos helpo...

lewis

I believe dinput8.dll is part of the directx installation....however, you can also Try this!

You can copy this file to (linux path shown) ;

~/.cxgames/bottle_name/drive_c/windows/system32

To do this, use cxsetup to configure the bottle, and then use winecfg to configure
wine to run in windowed mode ('Emulate a virtual desktop');

0. Start cxsetup

1. Highlight the bottle you installed the game into

2. Click on 'Configure' => 'Control Panel' => 'winecfg' -- the Wine Configuration GUI will appear

3. Then click on the 'Libraries' tab ..

4. In the 'New override for library', input dinput8.dll and click 'Add'

5. Now, in the 'Existing overrides:' section, find dinput8 => click on 'Edit' and change it to 'Native'

6. Click on Apply, Ok, exit....try the game again.

right i need to say sorry first, but also thanks at the same time.

i really should have said that i am running MAC OSX 5.8. so i am sorry if i did not say that in the first place. your post and the other cats post on gamepads did interest me so much i ended up forgetting that this was for a linux format. so that i say sorry for, as you have written up and very nice walk-through on how to install it.

but at the same time, will also thank you for even writing this up, not just for me, but for others to gander at if they too are having trouble.
if you or anybody else does know of a way to do this in OSX, that would be great. i may put up a new post actually.

thanks...

lewis

No problem friend, the information recording is important, regardless of OS/platform
being used...ie; we still all have to deal with the same end result, right? (getting
a windows titles to do what we want). And we're both going to end up using crossover
and wine to do that, right? My quasi-temporal-chronospheric display unit suggests to
me that the Mac input layer isn't all that far off from being a happening thang, and
lessons learnt here -should- help/aim such resolutions. I personally hope so anyhow (^8

aye, it pretty much was just the same as your linux step by step. i have just done it, have not tried it yet though [fingers crossed right around].

if it does not work, it does not work. but the knowledge of how to do it was what i mostly needed so as to try it myself.

thanks again. this forum is even quicker than the max/msp forum i am on, very impressed...

lewis

pretty much a no on my side for it to work with Far Cry. although i have not tried with other games as of yet.

i get an error message from the screen of when it should come up with the 'ubisoft' logo. basically pops up saying 'critical error: error loading DLL: CryInput.dll, error code 126'.

hmmm, what to do?...

lewis

do you have directx installed into the same bottle?

its weird because when go into configure/manage bottles[winxp]/applications. i see the direct x runtime-modern. but am not am to install it from there. it just takes me straight to the software installer but does not show anything for directx on the list. just the games, and thats it.

any ideas?...

lewis

Ummm....in the linux version at least, the directx-modern will only install
inot a winXP bottle (I think?)...you need use directx legacy for non winXP
bottles I believe

ok, is directx legacy available anywhere, or would i have to purchase it [hopefully not :)]...

Click <Show service packs and dependancies> in the Crossover Installer, and you'll see more choices pop up, two of which being Microsoft DirectX Runtime - Legacy, or Microsoft DirectX Runtime - Legacy (Download).

was very weird because my preferences had those feature hidden, now i can access all the other downloads.

thanks...

lewis

FlatOut all but done...

http://www.codeweavers.com/compatibility/browse/name/?app_id=4119;tips=1

..just need unravel the wheel business a bit

right i have got an error that pops up and the game wont even start up
"CRITICAL ERROR: error creating input system"

what do i need to do to get rid of that and fix the game?

thanks...

lewis

yo,

i just done a re-install of COG 8, and that has gotten everything back to normal. luckily i have only one game at the moment on steam and just had to download that again.

but i think for the time being, no gamepads can be used for far cry at this moment in time. obviously with what we have all been talking about in this thread it would be the much older games. or ones with gamepads specifically in mind.

looks like it is mousing for me then, need to buy a mouse now :)...

lewis

...hmmm...might be activex making it's presence known (ugly, ugly..)
but to your credit you gave it your best shot. I'm sure the Mac
input layer will improve over time...oh, and if you end up buying
a mouse, get one with 18 buttons or something (might make Descent 3
more useful to control...haha)

Oh and BTW, do you know if the Mac's can use the ev_dev interface?
Like...I know a can map some HID controls to keyboard keypress events
in linux using the ev_dev API and lots of mystical phrases...

boof, now you are asking something i dont know [dust balls through the brains :)]

i think the best cats to ask, would be the mac people in this forum. i mean the hardcore mac people, the ones who even know what kind of nuts they use to assemble them and where they came from, and who done the final test of them [a guy called george i think]. :)

i am not a complete mac dunce, just things like that are a little bit over my head. i do know how to do Max5 stuff and convert HID signal to control things, like faders and drum pads, but not what you are asking for.

good luck in :)...

lewis

haha, nice reply -- that's fine, perhaps Ken and/or Aric might shine some
light on this....talking about light, IR light that is, I'm pretty sure
in linux I could do game HID control via my DVD remote control....

...right now though, time to attack this GT-4 steering-wheel set....

Regards,

Don

Artist Formally Known as Dot wrote:

FlatOut all but done...

http://www.codeweavers.com/compatibility/browse/name/?app_id=4119;tips=1

..just need unravel the wheel business a bit

Readers of some of my other posts will already know that I'm from a past
time of industrial computer process control backgrounds, and will find it
no surprize to find me here with linux fooling about with game HIDs. For
the record...yes, my coffee cup is always full...and yes, a bottle of Valium
sits within reach on the desk infront of me (-B After seeing the initial output
from jstest last night, I freaked out and went to bed for inspiration...

A bit of background static => yes, I did look at the included windows drivers
stuffs...2 .dll files (nearly 1.5mb total size!...must be some evul magic in
those kittens), and by the looks of it the whole shumozzle works by creating
registry hooks back to aforesaid .dll files to obtain control data. Whether
this swings off xinput or dinput or activx input I have no idea...and as a
matter of fact, I do not want to know either...I can see what I need to know...

This all becomes worse, when one consults the largely inadequate and vaguely
translated book of clues pretending to be an instructional setup manual. I guess
they figured "well, the drivers are all going to work so why bother?" and that's
probably all sane and reasonable in 'normal usage situations' - here, we're
attempting the para-normal, and so anything is likely to happen next...

Now...there =are= some clues...at some point, the book describes how if you
have the wheel setup in say 'analog' mode, certain buttons/functions become
remapped/cojoined...and the same was also suggested regarding the 'normal' and
'race' modes as well. It doesn't clearly say what button/functions actually get
remapped and where to or what...it just mentions this will happen relative to
whatever mode you have selected.

You can see this effect, with jstest running and changing the modes -- it's
too much to post here, but I did screenshot the xterm output if anyone wants
a peek-boo.....and this is still also background static - configuring the thing
is where the real fun begins....

As in my previous posting here, regarding a jscal run to calibrate this thing,
it initializes into 'Normal' mode. This is probably a 'Good Thing' [tm]. Your
axis mappings will look like this ;

axis 0 - brake
axis 1 - throttle
axis 2 - gearshift
axis 3 - steering
axis 4 - HAT up/down
axis 5 - handbrake
axis 6 - throttle also (??...perhaps I should email the code maintainer on this)

If you select 'Analog' mode, the following happens ;

axis 4 missing? (gearstick?)
axis 5 & 6 HAT up/down/left/right become active

If you select 'Race' mode, the thing goes totally wacko, remapping axis' to
wheel buttons, and I think the pedals themselves stopped working altogether.
Don't use this mode....not unless you're up for a steep learning curve ;)

Understanding/interpreting exactly what jscal is wanting you to do exactly,
is not immediately intuitive -- you'll hit this effect first up, when it
comes to calibrating axis 0 (the brake pedal). It needs to know when the
brake pedal is off (press a button), when it is in it's center position
(equates to partial brake) (oress a button), and when the brake pedal is
fully depressed (hold or press a button). Same goes for throttle calibration,
steering/gears etc follow more or less the same rules (I guess 'center' on
the gearshift axis means a sequential shift gearbox? :)....

I haven't played with it a lot yet, but that's the layout. It takes up too
much room here...I'll have to shift it all over to the deb box and have a
play with it there, but it is working...

From my other posting; quote -- "[i]Note: At some stage, I had compiled-in the 'analog' joystick kernel source (rather than
have it as a module), and discovered upon embarking on this testing here, that there was absolutely no way to get the gameport
connected analog joystick to register into /dev/input in any way what-so-ever...it wasn't even being seen by kernel. I recompiled
the kernel to leave analog.ko as a module instead, and all is now good. I doubt many people will cross this bridge, but for the
sake of completeness...I'm using a pristine linux-2.6.26 tree.[/i]"

This doesn't quite detail what actually will happen...in practice,,,with linux-2.6.26 (I happen to 'like' 2.6.26 in the
same way I disliked 2.6.22....this will mean something to someone hopefully ;) Having established that the analog driver
needs to be a loadable_module and =not= builtin to the kernel proper, at that sane time the joydev support =was= 'in
kernel' as such, and this didn't seem to upset the penguin. In this analog gameport connected joystick case, the actual
gameport itself is part of my emu10k1 soundcard (SBLive!), and as such this layer is handled be the emu10k1_gp.ko module
which iirc lives in drivers/input/somewhere. One could automate a lot of this (perhaps this is already so on a Deb system),
but for Mr. OCD here something like modprobe -a analog [opts] always seems to get the module autoloader doing it right...

That said...the device is going to appear mapped to /dev/js0 -- plugin a gamepad, and it will get enumerated to /dev/js1,
the steeringwheel will appear at /dev/js2 and so on....all seems sound enough. Now...what I was trying to do, was map
around the dreaded mouse-warping thang Postal2 currently suffers from, hopeful to get it to accept input from the USB
gamepad instead -- after all, the ingame options include joystick support. That's when I discovered it was 'listening'
to one joystick device at all == the gameport connected analog joystick...aka; /dev/js0 So, on a hunch, I decided to
set about unplugging/replugging things, trying to get the USB gamepad to appear at /dev/js0....pfffft!...

The -only- way I found to achieve this, was to unplug all HIDs, manually remove analog.ko from the running penguin,
-then- plugin the USB gamepad as per normal, and it'll calibrate happily as /dev/js0

Did it help Postal2..??...nope, not a bit...but something was learnt ;)

I grew up with analog joysticks -- I still have a working 500mHz pentium box,
complete with Voodoo2 videocard and a genuine SB-16 soundcard with optional
wavetable chip. It has one purpose in life -- it runs the original Rollcage
release. Rollcage is what F1-GP should be...but I am so good at that title,
many times friends have suggested I youtube some of the wild tricks that
game is capable of...like...ie; launching a Number 1 seeker missile and
catching a lift on it piggyback style....crazy stuff. But I digress....

I've concluded with Rollcage Stage 2, that I'm on average 1 second per
lap quicker with the analog joystick, compared to the best I can manage
with the gamepad. That's still 'damn close' considering I'm no gamepad
exponent, and for sure my son would put me to shame here in this regard...

Wtth FlatOut, using the gamepad input, I'm finding the sensitivity setting
is having little effect at all...I'll re-check this, but if I'm right here,
you should turn sensitivity off altogether, and try find a 'comfortable'
deadzone setting instead (seemed to be working)...

Some (not nearly all..) game titles actually add an extra entry into
control panel that lets you futz with/change/comfigure game controllers
that way -- this would be so cool to collate/converge all known (linux)
inputs into a single location, selectable/adjustable on a per game basis.

Sounds like a good idea, but sounds decidedly ugly to implement at the same timr...

This issue has been forwarded to the Official CodeWeavers Ticket System. If you have observed this issue and would like to report it as well, please open a support ticket or send an email to info@codeweavers.com with a description of what you are seeing and a link to this post.

Thank you!
The CodeWeavers Team

Thank you oh gracious ninja warriors for picking this grain of rice up....

Thinking about it more, I believe I came to the conclusion that the
situation wasn't all that different from the current 'Audio' setup
tab in winecfg....at least, in the linux case that it's where everything
is tidily presented under udev /dev/input/somewhere symlinked out to a
/dev/jsX sevice node....all well and good, but a story I recently read
suggested that 'udev was on the way out' as it were, being replaced by the
console/policy kits or whatever .....and I just threw my arms into the air
and cried openly to an open sky full of ever changing clouds of API's....

All I'm saying here, is beware on imminent change...

Apart from analog.ko's reluctance to relinquish /dev/js0 once it's got
it's teeth into it, the input device enumerations all work pretty well.
Yes, a rare occasion where plug&play actually does that. I can't fault
analog/gameport joystick performance at all - 'faultless' is not a term
I use lightly, but it's appropriate here.

Gamepad is pretty damn good too I hasten to add...especially in FlatOut,
it's big fun. TOCA 3 is probably this weekemd's big challenge...

Btw, I seem to recall some stand-alone game-controller softwares of
a third-party nature, that added like 'centralized' game control options
to control-panel...can anyone confirm/deny if this was just a bad dream?

Oh, and brw...so far, only 'The Neverhood' added any extra game xontroller
extras to control panel/winecfg....

as lushes as a fat whore bone hole, i have come up with a solution. for the time being.

sorry for the sordid image that may pass in the brain just now but i have come up with a good, although different solution.

as you know i have been looking to get my gamepad up and running for my games.
i came across many different paths and all that jazz and was basically not getting anywhere.

but i knew about 'gamepad companion', a software program that convert input into the gamepad etc blah blah blah.

so i tried the demo just to see if it would work on the games in COG. and they do, maybe in not the best fashion as you would need to spend some time to get the right calibrations etc. but just doing some simple messing have come up with a minor solution. and i am able to control and play with the character with my gamepad, no mouse or keyboard needed at all. great.

so even what i was thinking off of the top of my head, maybe the cats from codeweavers or something, may want to get in contact with the cats who made this program and ask about there method of coding or whatever. i dont know the correct terms so pardon my childish pronunciation.

i will do a fair more messing with settings to see if i can get it to properly work 100% on my gamepad.

will let you know the results...

lewis

well after some messing around and all that. the solution is 99% correct.
the one problem is the right analog stick, which is basically your mouse.

in half life it is quite jittery, but in far cry when you mess with more of the options, you can make it much smoother. but in all is still a wee bit jittery.

there are settings in the gamepad companion to make it smoother but does not help too much. but the fact is that with this program, it makes playing games with your gamepad a hell of a lot easier.

aye, its good...

lewis

if anyone has tried ubs overdrive. that is also a good program. but still problems with the right analog stick. it is better than the other one i mentioned, mainly because it is more editable in its controls. but has worse control over the right stick

aye...

Ahh...I thought I remembered seeing things like this around....no immediate
use for ix86/linux but obviously is helping you out (;

Just another general tidbit addition to linux HID devices...

XBOX 360 USB gamepad -- also recognized and working in COG & linux.

There'd be two wys to end up with one of these things;

buy the XBOX controller for PC gamepad (comes fitted with USB cable)
hardware-hack a USB cable onto an original XBOX controller