Joypad plugin for Linux available! - Page 2

krz · April 29th, 2002, 23:34

Hmm.. I don't know how one program could experience the delay while another one doesn't. The kernel is pausing for a specific amount of time (while reading the controller). User space programs don't even talk directly to the gamecon driver. The kernel periodically polls the controller for button/axis status and posts events to the input system. User space programs then read those input system events, as I'm sure you know

The only thing I can think of would be if the program implemented it's own controller communication routines (talked directly to the parallel port, and not use the Linux input API -- bad idea). Can you ask the user what other programs they ran, without experiencing any slowdowns?

Just so you know, I experienced the system slowdown while running the jstest (part of inpututils) program, so I doubt the slowdown is related to anything specific to your plugin.

--
Keith

**ammoQ** · April 30th, 2002, 00:14

He said "tuxracer" and "all other games"... Anyway, I invited him to join this forum. I'm pretty sure the other programs do not implement their own communication routines (at least on my system, tuxracer doesn't have the s-bit set)

.

__________________
If you think my English is bad, wait till you read my Polish.

**ammoQ** · April 30th, 2002, 00:18

jstest has a --old mode, maybe the other programs use this mode? This would reduce workload, since the 0.x interface only supports for 2 buttons and 2 axes with 8 bit resulotion?

__________________
If you think my English is bad, wait till you read my Polish.

Last edited by ammoQ; April 30th, 2002 at 07:28..

chuzwuzza · April 30th, 2002, 08:16

I am that other user.

I noticed you saying that your problem was lesser when using the controller in digital mode. I have one of the old-school digital only controllers -- bought my psx before the dual-shock came out and never really saw the point to getting an analog controller

But yeah, I have no problems in any other games. Just this plugin... and xjoypad.

chuzwuzza · April 30th, 2002, 08:29

Hmm odd... I just compiled the inpututils package just to make absolutely sure, and My system *does* experience the slowdown with that.
I'm just going to compile tuxracer now to check that...
(The last time I used my gamepad in linux was some time ago/several kernels ago. I don't remember any slowdown while playing tuxracer though... we shall find out in a few minutes)

chuzwuzza · April 30th, 2002, 08:48

Well that is truly bizarre.

I've just run tuxracer. Playing with the gamepad I get a miserable 20-30fps. Without the gamecon kernel module loaded, I get a silky smooth 110fps.

I'm positive I used to play with no slowdown with my gamepad.
That would have been back when I was using Debian unstable with about kernel 2.4...9 or 10. Maybe 11. Now I'm using Gentoo linux with kernel 2.4.19-r1 (presumably some sort of 2.4.18 kernel with some gentoo patches on it)

**ammoQ** · April 30th, 2002, 13:25

could it be that the older versions of gamecon.c did not support
all buttons of the pad, so it would have had less work to do?

__________________
If you think my English is bad, wait till you read my Polish.

krz · April 30th, 2002, 15:12

This is making more sense now

You experienced no slowdowns in an older kernel. It is very possible that the gamecon driver has changed since you last tried it. I'm glad to see that other programs are experiencing the slowdown, because it did not make any sense (the pause is in the kernel, and there is nothing a user space program can do about it).

I don't think the old 0.x interface would speed anything up. The gamecon driver does not know anything about what version of the input interface the user space program is using. Even though the old input system on had 2 button/2 axes the gamecon driver will still get all the information it can from the controller. The input system would just filter out the "extra" events.

I made a patch to gamecon.c last night to significantly decrease the PSX controller scanning delay. It should now take about 1.2ms to scan a rumble/analog controller, instead of the 9.6ms it used to take. I also added a module parameter to allow the user to choose their delay rate. I sent the patch to the author and he accepted it, so hopefully we will see a new gamecon driver in the next kernel version. I also improved the controller detection code by giving the controller 1/10th of second after power-up before sending it any commands.

For the adventurous, my gamecon patch can be found here:
http://confusatron.org/~krz/gamecon.c.patch

The patch is against 2.4.17, but the gamecon driver is the same as the one in 2.4.18. It's up to you to apply the patch and rebuild your kernel modules

The new module parameter is "gc_psxdelay" and you can give it a number between 3 and 60, the default is 8. Example:

$modprobe gamecon gc=0,7 gc_psxdelay=3

--
Keith

**ammoQ** · April 30th, 2002, 18:34

Impressive! Hope it will help those gamecon users!

__________________
If you think my English is bad, wait till you read my Polish.

krz · April 30th, 2002, 20:33

Thanks, but the change was pretty small

It should help out gamecon users, anyone here willing to try it out? I'd like to know if this does fix the performance problems, or not.

How about it chuzwuzza? Feel like patching your kernel and rebuilding a module?

**ammoQ** · April 30th, 2002, 22:18

Mastercard ad: Patching the program EUR 0,50; knowing where and how - priceless.

__________________
If you think my English is bad, wait till you read my Polish.

chuzwuzza · May 1st, 2002, 08:45

I'm just patching/compiling now

--edit 5min later--

Goddamn gentoo and it's 50 bazillion kernel variations...

Last edited by chuzwuzza; May 1st, 2002 at 08:54..

chuzwuzza · May 1st, 2002, 10:00

Well after extensive recompiling and swearing about the gentoo developers, I've got your patch applied. and I have this to say: krz, you are my hero

It works beutifully now, super smooth and responsive. As a side note, I have to modprobe gamecon with gc_psxdelay=10. Any less than that and it won't detect the controller there at all. I don't know why, but it works nice and smooth anyway now.

Thanks heaps

**ammoQ** · May 1st, 2002, 13:49

hey, someone should give this krz guy some red stars!

__________________
If you think my English is bad, wait till you read my Polish.

krz · May 1st, 2002, 15:52

Excellent! Thanks for the info about needing to use a delay value of 10 (I'm glad I made the delay a module parameter). I'll have to experiement with an original PSX controller, I was using a dualshock when testing. According to the controller docs I found, the PSX clocks the controller at 250kHz (4us period) so the absolute minimum delay value should be 2 (2us clock high, 2us clock low). I limited the minimum to be 3, just to be safe. However, it doesn't look like 3 is "safe" enough. Thanks for trying my patch! Glad it worked for ya!

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

April 29th, 2002, 23:34	#21
krz Registered User Join Date: Oct 2001 Posts: 10	Hmm.. I don't know how one program could experience the delay while another one doesn't. The kernel is pausing for a specific amount of time (while reading the controller). User space programs don't even talk directly to the gamecon driver. The kernel periodically polls the controller for button/axis status and posts events to the input system. User space programs then read those input system events, as I'm sure you know The only thing I can think of would be if the program implemented it's own controller communication routines (talked directly to the parallel port, and not use the Linux input API -- bad idea). Can you ask the user what other programs they ran, without experiencing any slowdowns? Just so you know, I experienced the system slowdown while running the jstest (part of inpututils) program, so I doubt the slowdown is related to anything specific to your plugin. -- Keith

April 30th, 2002, 00:14	#22
ammoQ Emu author Join Date: Mar 2002 Location: Vienna/Austria/Europe Posts: 1,168	He said "tuxracer" and "all other games"... Anyway, I invited him to join this forum. I'm pretty sure the other programs do not implement their own communication routines (at least on my system, tuxracer doesn't have the s-bit set) . __________________ If you think my English is bad, wait till you read my Polish.

April 30th, 2002, 00:18	#23
ammoQ Emu author Join Date: Mar 2002 Location: Vienna/Austria/Europe Posts: 1,168	jstest has a --old mode, maybe the other programs use this mode? This would reduce workload, since the 0.x interface only supports for 2 buttons and 2 axes with 8 bit resulotion? __________________ If you think my English is bad, wait till you read my Polish. Last edited by ammoQ; April 30th, 2002 at 07:28..

April 30th, 2002, 08:16	#24
chuzwuzza Registered User Join Date: Jan 2002 Posts: 14	I am that other user. I noticed you saying that your problem was lesser when using the controller in digital mode. I have one of the old-school digital only controllers -- bought my psx before the dual-shock came out and never really saw the point to getting an analog controller But yeah, I have no problems in any other games. Just this plugin... and xjoypad.

April 30th, 2002, 08:29	#25
chuzwuzza Registered User Join Date: Jan 2002 Posts: 14	Hmm odd... I just compiled the inpututils package just to make absolutely sure, and My system does experience the slowdown with that. I'm just going to compile tuxracer now to check that... (The last time I used my gamepad in linux was some time ago/several kernels ago. I don't remember any slowdown while playing tuxracer though... we shall find out in a few minutes)

April 30th, 2002, 08:48	#26
chuzwuzza Registered User Join Date: Jan 2002 Posts: 14	Well that is truly bizarre. I've just run tuxracer. Playing with the gamepad I get a miserable 20-30fps. Without the gamecon kernel module loaded, I get a silky smooth 110fps. I'm positive I used to play with no slowdown with my gamepad. That would have been back when I was using Debian unstable with about kernel 2.4...9 or 10. Maybe 11. Now I'm using Gentoo linux with kernel 2.4.19-r1 (presumably some sort of 2.4.18 kernel with some gentoo patches on it)

April 30th, 2002, 13:25	#27
ammoQ Emu author Join Date: Mar 2002 Location: Vienna/Austria/Europe Posts: 1,168	could it be that the older versions of gamecon.c did not support all buttons of the pad, so it would have had less work to do? __________________ If you think my English is bad, wait till you read my Polish.

April 30th, 2002, 15:12	#28
krz Registered User Join Date: Oct 2001 Posts: 10	This is making more sense now You experienced no slowdowns in an older kernel. It is very possible that the gamecon driver has changed since you last tried it. I'm glad to see that other programs are experiencing the slowdown, because it did not make any sense (the pause is in the kernel, and there is nothing a user space program can do about it). I don't think the old 0.x interface would speed anything up. The gamecon driver does not know anything about what version of the input interface the user space program is using. Even though the old input system on had 2 button/2 axes the gamecon driver will still get all the information it can from the controller. The input system would just filter out the "extra" events. I made a patch to gamecon.c last night to significantly decrease the PSX controller scanning delay. It should now take about 1.2ms to scan a rumble/analog controller, instead of the 9.6ms it used to take. I also added a module parameter to allow the user to choose their delay rate. I sent the patch to the author and he accepted it, so hopefully we will see a new gamecon driver in the next kernel version. I also improved the controller detection code by giving the controller 1/10th of second after power-up before sending it any commands. For the adventurous, my gamecon patch can be found here: http://confusatron.org/~krz/gamecon.c.patch The patch is against 2.4.17, but the gamecon driver is the same as the one in 2.4.18. It's up to you to apply the patch and rebuild your kernel modules The new module parameter is "gc_psxdelay" and you can give it a number between 3 and 60, the default is 8. Example: $modprobe gamecon gc=0,7 gc_psxdelay=3 -- Keith

April 30th, 2002, 18:34	#29
ammoQ Emu author Join Date: Mar 2002 Location: Vienna/Austria/Europe Posts: 1,168	Impressive! Hope it will help those gamecon users! __________________ If you think my English is bad, wait till you read my Polish.

April 30th, 2002, 20:33	#30
krz Registered User Join Date: Oct 2001 Posts: 10	Thanks, but the change was pretty small It should help out gamecon users, anyone here willing to try it out? I'd like to know if this does fix the performance problems, or not. How about it chuzwuzza? Feel like patching your kernel and rebuilding a module?

April 30th, 2002, 22:18	#31
ammoQ Emu author Join Date: Mar 2002 Location: Vienna/Austria/Europe Posts: 1,168	Mastercard ad: Patching the program EUR 0,50; knowing where and how - priceless. __________________ If you think my English is bad, wait till you read my Polish.

May 1st, 2002, 08:45	#32
chuzwuzza Registered User Join Date: Jan 2002 Posts: 14	I'm just patching/compiling now --edit 5min later-- Goddamn gentoo and it's 50 bazillion kernel variations... Last edited by chuzwuzza; May 1st, 2002 at 08:54..

May 1st, 2002, 10:00	#33
chuzwuzza Registered User Join Date: Jan 2002 Posts: 14	Well after extensive recompiling and swearing about the gentoo developers, I've got your patch applied. and I have this to say: krz, you are my hero It works beutifully now, super smooth and responsive. As a side note, I have to modprobe gamecon with gc_psxdelay=10. Any less than that and it won't detect the controller there at all. I don't know why, but it works nice and smooth anyway now. Thanks heaps

May 1st, 2002, 13:49	#34
ammoQ Emu author Join Date: Mar 2002 Location: Vienna/Austria/Europe Posts: 1,168	hey, someone should give this krz guy some red stars! __________________ If you think my English is bad, wait till you read my Polish.

May 1st, 2002, 15:52	#35
krz Registered User Join Date: Oct 2001 Posts: 10	Excellent! Thanks for the info about needing to use a delay value of 10 (I'm glad I made the delay a module parameter). I'll have to experiement with an original PSX controller, I was using a dualshock when testing. According to the controller docs I found, the PSX clocks the controller at 250kHz (4us period) so the absolute minimum delay value should be 2 (2us clock high, 2us clock low). I limited the minimum to be 3, just to be safe. However, it doesn't look like 3 is "safe" enough. Thanks for trying my patch! Glad it worked for ya!