Multi-console gamepad driver for GPIO

[Schnell]

Sorry to be asking so many questions, it's probably user error again. I ran the

Code: Select all

# jscal -s 4,1,0,0,0,6972137,6972137,1,0,0,0,6547006,6468127,1,0,0,0,536854528,536854528,1,0,0,0,536854528,536854528 /dev/input/jsX

command, and it doesn't seem to help the fact that the analogue stick on the N64 controller doesn't reach a maximum. I assume that is supposed to fix it, but when the analogue stick is pressed all the way up, it doesn't reach a max. The character in game cannot run.
Thanks again,
Schnell

[marqs]

Sorry to be asking so many questions, it's probably user error again. I ran the

Code: Select all

# jscal -s 4,1,0,0,0,6972137,6972137,1,0,0,0,6547006,6468127,1,0,0,0,536854528,536854528,1,0,0,0,536854528,536854528 /dev/input/jsX

command, and it doesn't seem to help the fact that the analogue stick on the N64 controller doesn't reach a maximum. I assume that is supposed to fix it, but when the analogue stick is pressed all the way up, it doesn't reach a max. The character in game cannot run.
Thanks again,
Schnell

The calibration applies only to applications which use Joystick API. There are several other input interfaces (libev, udev, SDL etc.) in linux which may have their own calibration procedures or not one at all. SDL1 apps can be forced to use joystick api by setting a specific environment variable ("export SDL_JOYSTICK_DEVICE=/dev/input/js0" for 1st joystick), and apparently it is also possible to tell RetroArch to use Joystick API directly by setting "input_joypad_driver = linuxraw" in retroarch.cfg.

[Soullous]

Hi marqs,

I'm back.

So, version 1.2 seems to have fixed all of the previous issues with the PSX controllers, but it has introduced a new one. In my previous post, I had said that the Raspberry Pi had frozen up a few times when I was trying to configure the controllers, but then it started working again. Well, it seems that the freezing is happen randomly, and it's happening pretty often. The Raspberry Pi itself doesn't seem to be freezing up, but all of the inputs stop working, including the keyboard. I'm still able to SSH into the pi and run commands, and shut it down with my Mausberry circuit, but the controllers (and keyboard) just randomly stop working. AFAIK, this is a new issue with v 1.2 of the driver. Unfortunately, it makes the console unusable for all practical purposes, because there is no telling when it's going to stop working. When this happens, the only way to get the controllers working again is to do a complete shutdown and restart of the Pi. This appears to happen most often while navigating EmulationStation, especially after first starting up (although this may just be my imagination). However, I have seen it happen in game as well.

[marqs]

Hi marqs,

I'm back.

So, version 1.2 seems to have fixed all of the previous issues with the PSX controllers, but it has introduced a new one. In my previous post, I had said that the Raspberry Pi had frozen up a few times when I was trying to configure the controllers, but then it started working again. Well, it seems that the freezing is happen randomly, and it's happening pretty often. The Raspberry Pi itself doesn't seem to be freezing up, but all of the inputs stop working, including the keyboard. I'm still able to SSH into the pi and run commands, and shut it down with my Mausberry circuit, but the controllers (and keyboard) just randomly stop working. AFAIK, this is a new issue with v 1.2 of the driver. Unfortunately, it makes the console unusable for all practical purposes, because there is no telling when it's going to stop working. When this happens, the only way to get the controllers working again is to do a complete shutdown and restart of the Pi. This appears to happen most often while navigating EmulationStation, especially after first starting up (although this may just be my imagination). However, I have seen it happen in game as well.

Hmm, could you check the last entries of kernel log (/var/log/kern.log) after input 'freeze' for clues? There was no such changes between 1.0-1.2 which should cause these kind of issues. The driver disables interrupts for the duration of communication with the pad, but if re-enabling did not work properly then there would be more grave issues. More likely is that input device framework goes to some weird state for some reason if everything else works.

[Soullous]

I'm not sure how helpful the log is, because nothing seemed to get written to it immediately after it froze up. But, I just booted it up and played around with the the controllers in emulation station until it froze, and here are the complete log entries from kern.log from the time it booted up until the time it froze. It looks like everything was written to the log during boot within 1 second.

Code: Select all

Jan 24 21:17:42 retropie kernel: [   34.750836] uart-pl011 3f201000.uart: no DMA platform data
Jan 24 21:17:46 retropie kernel: [   38.239507] ------------[ cut here ]------------
Jan 24 21:17:46 retropie kernel: [   38.239552] WARNING: CPU: 0 PID: 2471 at drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c:2484 vchiq_release_internal+0xa8/0x24c()
Jan 24 21:17:46 retropie kernel: [   38.239560] Modules linked in: binfmt_misc gamecon_gpio_rpi(O) snd_bcm2835 snd_pcm snd_seq snd_seq_device snd_timer snd uinput 8192cu bcm2835_gpiomem uio_pdrv_genirq uio joydev evdev
Jan 24 21:17:46 retropie kernel: [   38.239641] CPU: 0 PID: 2471 Comm: HTV Notify Tainted: G        W  O    4.1.13-v7+ #826
Jan 24 21:17:46 retropie kernel: [   38.239648] Hardware name: BCM2709
Jan 24 21:17:46 retropie kernel: [   38.239682] [<80018444>] (unwind_backtrace) from [<80013e08>] (show_stack+0x20/0x24)
Jan 24 21:17:46 retropie kernel: [   38.239702] [<80013e08>] (show_stack) from [<8055a188>] (dump_stack+0x98/0xe0)
Jan 24 21:17:46 retropie kernel: [   38.239720] [<8055a188>] (dump_stack) from [<80026aa8>] (warn_slowpath_common+0x8c/0xc8)
Jan 24 21:17:46 retropie kernel: [   38.239739] [<80026aa8>] (warn_slowpath_common) from [<80026ba0>] (warn_slowpath_null+0x2c/0x34)
Jan 24 21:17:46 retropie kernel: [   38.239756] [<80026ba0>] (warn_slowpath_null) from [<80393018>] (vchiq_release_internal+0xa8/0x24c)
Jan 24 21:17:46 retropie kernel: [   38.239772] [<80393018>] (vchiq_release_internal) from [<80393c14>] (vchiq_ioctl+0x770/0x16f0)
Jan 24 21:17:46 retropie kernel: [   38.239791] [<80393c14>] (vchiq_ioctl) from [<80156508>] (do_vfs_ioctl+0x420/0x618)
Jan 24 21:17:46 retropie kernel: [   38.239806] [<80156508>] (do_vfs_ioctl) from [<80156744>] (SyS_ioctl+0x44/0x6c)
Jan 24 21:17:46 retropie kernel: [   38.239821] [<80156744>] (SyS_ioctl) from [<8000f980>] (ret_fast_syscall+0x0/0x54)
Jan 24 21:17:46 retropie kernel: [   38.239833] ---[ end trace 6fc2efa2382183b8 ]---
Jan 24 21:17:46 retropie kernel: [   38.239845] vchiq: vchiq_ioctl: cmd VCHIQ_IOC_RELEASE_SERVICE returned error -1 for service TVNT:2466

[marqs]

I'm not sure how helpful the log is, because nothing seemed to get written to it immediately after it froze up. But, I just booted it up and played around with the the controllers in emulation station until it froze, and here are the complete log entries from kern.log from the time it booted up until the time it froze. It looks like everything was written to the log during boot within 1 second.

I tried to reproduce the issue using by setup (Linux raspberrypi2 4.0.6-v7+, SCPH-10010 controller, gamecon_gpio_rpi v1.2) but there was no freezes in Emulatationstation menus or during gameplay. I also left ES idle for 20 minutes and it was working without any problems when I came back. A quick googling of those vchiq errors shows people getting these in various contexts so I suspect the gamepad driver is not the reason behind the freezes. Some users apparenty have got the issue fixed by switching to a better power supply or by decreasing overclock or with firmware update.

[mrdt]

Hi guys,

I am running RetroPie v3.4 and gamecon_gpio_rpi v1.2, with the latest firmware (4.1.17-v7+ & Linux headers 4.1.17+v7+_4.1.17-v7+-2) on a RPi2.
I got 2 nes controllers, their both working fine with gamecon_gpio_rpi v1.2, as well on jtest, retropie menu as in games.
The problem is that I have to manually start the module everytime i reboot or restart the Raspberry.
I added the line at /etc/modules like this:

Code: Select all

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

uinput
joydev
snd-bcm2835
gamecon_gpio_rpi map=0,0,2,2

Maybe i can get some help here, i can't seem to find what i'm missing.

Update!

I got it fixed :

Create a file called ''gamecon.conf'' in /etc/modprobe.d/

Code: Select all

sudo nano /etc/modprobe.d/gamecon.conf 

with just this single line (remember to replace ''map=0,0,2,2'' with your own configuration):

Code: Select all

options gamecon_gpio_rpi map=0,0,2,2

Now in /etc/modules add just the module name and omit the map parameter:

Code: Select all

gamecon_gpio_rpi

Now your module should load fine on boot.
You could confirm your module is working after reboot or restart by running:

Code: Select all

lsmod

It will show you all the modules that are active

Best regards,
Mario.

[Soullous]

I'm not sure how helpful the log is, because nothing seemed to get written to it immediately after it froze up. But, I just booted it up and played around with the the controllers in emulation station until it froze, and here are the complete log entries from kern.log from the time it booted up until the time it froze. It looks like everything was written to the log during boot within 1 second.

I tried to reproduce the issue using by setup (Linux raspberrypi2 4.0.6-v7+, SCPH-10010 controller, gamecon_gpio_rpi v1.2) but there was no freezes in Emulatationstation menus or during gameplay. I also left ES idle for 20 minutes and it was working without any problems when I came back. A quick googling of those vchiq errors shows people getting these in various contexts so I suspect the gamepad driver is not the reason behind the freezes. Some users apparenty have got the issue fixed by switching to a better power supply or by decreasing overclock or with firmware update.

Sorry for the long delay on the response. I haven't had a lot of time to test this, but from what I have seen so far, disabling overclock seems to have solved the issue. Now I just need to figure out which are the correct overclock settings to have a stable and fast system. I'll reply back if anything changes.

Also, I've got a Pi 3 on the way tomorrow, so I'll be testing with that over the next few days, too.

[Frederose]

My NES controller only seems to work in Emulationstation, but not in the actual roms. I understand that SNESDev might be the problem. Any idea what to do ? How do I switch from the default snes controller in gamecon to NES ? The readme file display weird characters so it is useless.

[marqs]

Also, I've got a Pi 3 on the way tomorrow, so I'll be testing with that over the next few days, too.

Ok, hopefully it works straight out of the box.

My NES controller only seems to work in Emulationstation, but not in the actual roms. I understand that SNESDev might be the problem. Any idea what to do ? How do I switch from the default snes controller in gamecon to NES ? The readme file display weird characters so it is useless.

Have you installed both SNESDev and gamecon? If the controller works in ES but not with actual emulators, it sounds more like that the pad configuration is not passed to the emulators. Gamecon readme file is in compressed format, so you need to open with zless or similar.

[Soullous]

Also, I've got a Pi 3 on the way tomorrow, so I'll be testing with that over the next few days, too.

Ok, hopefully it works straight out of the box.

Yes, it seems to be working. No problems.

[pawelkrak]

Hi. I'm used latest 3.7 retropie. I have joystick connected and working when used: modprobe --first-time db9_gpio_rpi map=1.
When i reboot my RPi2, driver not loaded. I must start each time manually with modprobe then working ok.

my etc/modules

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
uinput
joydev
snd-bcm2835
db9_gpio_rpi map=1

any ideas? thanx

[marqs]

Hi. I'm used latest 3.7 retropie. I have joystick connected and working when used: modprobe --first-time db9_gpio_rpi map=1.
When i reboot my RPi2, driver not loaded. I must start each time manually with modprobe then working ok.

my etc/modules

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
uinput
joydev
snd-bcm2835
db9_gpio_rpi map=1

any ideas? thanx

Check the solution a couple posts back from mrdt.

[ByteFlinger]

Hi

I am not entirely certain this is the correct thread to ask this.

I am planning to build myself a little gaming console with the Rpi 3 using retropie and I would really like to be able to use my snes (and potentially others) game pads with it, partially to get the least amount of latency (compared to usb), partially for the novelty of it and partially to have it as a little project and learn something new.

I am a programmer but not very experienced with the hardware side of it.

Having done a bit of reading, it is my understanding that, in its simplest form, it should be possible to wire up 2 snes controllers directly to the gpio port and use the drivers to get it working, is this correct?

My idea at the moment is to buy a ribbon cable with a 40 pin adapter at the ends, cut one of the ends, try to figure out which of the little wires match which pins and wire 2 snes ports (from snes extension cables) to it. Assuming a bit of luck with 3.3v compatible controllers and whatnot would that work?

The reason I ask is that I see so many people casually talk about using their controllers and the retropie wiki seems to indicate it might just be possible to wire it up yet when googling for resources, @petrockblog's blog comes up often with all kinds of neat PCBs and circuitry like the power block thus leaving me uncertain whether one needs some extra hardware to connect the controllers to the gpio port.

[marqs]

I am planning to build myself a little gaming console with the Rpi 3 using retropie and I would really like to be able to use my snes (and potentially others) game pads with it, partially to get the least amount of latency (compared to usb), partially for the novelty of it and partially to have it as a little project and learn something new.

Gamecon driver is currently configured to be polled every 10ms - compared to USB it's a bit slower pace (basic USB is 8ms if I remember correctly) but has less processing overhead (no USB stack etc.) so total latency is probably less indeed. In practice, however, bigger portion of latency is likely to be caused by OS, GPU drivers and/or monitor.

Having done a bit of reading, it is my understanding that, in its simplest form, it should be possible to wire up 2 snes controllers directly to the gpio port and use the drivers to get it working, is this correct?

Yes, there's instructions and connection diagram on RetroPie wiki.

The reason I ask is that I see so many people casually talk about using their controllers and the retropie wiki seems to indicate it might just be possible to wire it up yet when googling for resources, @petrockblog's blog comes up often with all kinds of neat PCBs and circuitry like the power block thus leaving me uncertain whether one needs some extra hardware to connect the controllers to the gpio port.

Typically you don't need extra hw, assuming you're willing to open up the controller cable or have an externsion cord.

[ByteFlinger]

Thank you. I don't know if it is any indication of the lag but I tried playing Atari's breakout with the d-pad (on a USB controller) and it was just impossible. I don't remember the game feeling that way but maybe it did.

[Jazunka]

I'm trying to use psx controllers using gamecon and i ran into some problems.
Using 0.9 the controllers work except for the left analog stick,
After reading that 1.2 should fix this, i installed 1.2 but instead the controllers refused to work at all, altough sometimes evtest returned some input sporadically.
Is there a solution?

[marqs]

I'm trying to use psx controllers using gamecon and i ran into some problems.
Using 0.9 the controllers work except for the left analog stick,
After reading that 1.2 should fix this, i installed 1.2 but instead the controllers refused to work at all, altough sometimes evtest returned some input sporadically.
Is there a solution?

Which pins are you using for data lines? If you are using pins which do not have on-board pull-up resistor, you need to add 1.8k-4.7k pull-up from each data line to 3.3V.

It looks like I've forgot to add this info to wiki, plus RetroPie installation hasn't been updated to fetch newest gamecon (v1.2) either.

[Soullous]

EDIT: I seem to have fixed it by installing the raspberrypi-kernel-headers package. My headers must have gotten corrupted somehow.

Something seems to have broken with the latest kernel. I'm running 4.4.11-v7+. The headers seem to have downloaded and installed just fine, but I'm getting the following error when I try to install the gamecon drivers. I've tried installing both version 1.0 and 1.2:

Code: Select all

DKMS make.log for gamecon_gpio_rpi-1.2 for kernel 4.4.11-v7+ (armv7l)
Fri May 27 23:12:37 EDT 2016
make -C /lib/modules/4.4.11-v7+/build M=/var/lib/dkms/gamecon_gpio_rpi/1.2/build modules
make[1]: Entering directory '/usr/src/linux-headers-4.4.11-v7+'
  CC [M]  /var/lib/dkms/gamecon_gpio_rpi/1.2/build/gamecon_gpio_rpi.o
In file included from include/linux/mmzone.h:18:0,
                 from include/linux/gfp.h:5,
                 from include/linux/kmod.h:22,
                 from include/linux/module.h:13,
                 from /var/lib/dkms/gamecon_gpio_rpi/1.2/build/gamecon_gpio_rpi.c:31:
include/linux/page-flags-layout.h:5:30: fatal error: generated/bounds.h: No such file or directory
compilation terminated.
scripts/Makefile.build:264: recipe for target '/var/lib/dkms/gamecon_gpio_rpi/1.2/build/gamecon_gpio_rpi.o' failed
make[2]: *** [/var/lib/dkms/gamecon_gpio_rpi/1.2/build/gamecon_gpio_rpi.o] Error 1
Makefile:1384: recipe for target '_module_/var/lib/dkms/gamecon_gpio_rpi/1.2/build' failed
make[1]: *** [_module_/var/lib/dkms/gamecon_gpio_rpi/1.2/build] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.4.11-v7+'
Makefile:5: recipe for target 'all' failed
make: *** [all] Error 2

[Marv007]

Hi marqs,

I'm the guy that had problems with my NES controllers and added a 74LVC245 and 74HCT244 to counter it. I wanted to turn my project into something better looking with a case and everything. But I'm having a hard time with weird readings when nothing is connected.

I connect my PCB (with 74LVC245 and 74HCT244) to the PI without an controller attached
I start the driver with

Code: Select all

sudo modprobe gamecon_gpio_rpi map=0,0,1,1,1,1

and then I do a

Code: Select all

jstest /dev/input/jsX

When I jstest pad 0 it will start with everything on. It will occasionally switch button 1 from on to off and back again in rapid succesion. Then it will pause again for a while and do it again. This repeats indefinitely.
While I was typing this it started switching everything on and off (the axes rarely change) very rapidly without an end.
I wanted to type that the other pads (1-3) behaved differently but they are now all switching all the buttons.

When I tested this yesterday the buttons would only go into the on state without ever changing (when nothing is connected).

I do get normal readings (everything off) when I don't have anything connected to the GPIO pins.

Do you have an idea on what I could do to prevent these readings? I actually don't need a solution, turns out I only have 1 controller that doesn't work with 3.3V. I'm just interested in the problem and the solution



Unrelated but interesting anyway, you can power the controllers without connecting the power pin:

This is all without the PCB.
Connect NES controller without 3V3: random keystrokes. Can interact: holding down A is recognized, no other button is recognized
Connect SNES controller (with 3V3) to same pins while NES controller (without 3V3) is connected: SNES controller works normally, NES is ignored
Connect SNES controller without 3V3: no random keystrokes but only the B works and it sets everything to on

[marqs]

Do you have an idea on what I could do to prevent these readings? I actually don't need a solution, turns out I only have 1 controller that doesn't work with 3.3V. I'm just interested in the problem and the solution

When you don't have a controller connected, input pin of 74LVC245 is floating and thus output can change constantly/randomly due to noise etc. To prevent that, try connecting a 10kohm resistor from that 74LVC245 input pin to 5V or 3.3V.

[larsmjoh]

Hi all,

I am trying to install the db9 driver on a Zero (ie no network) but I am having dependency problems.
When I install the package it complains of not finding the sources to the running kernel:

Code: Select all

Preparing to unpack db9-gpio-rpi-dkms_1.0_all.deb ...
Done.
Unpacking db9-gpio-rpi-dkms (1.0) over (1.0) ...
Setting up db9-gpio-rpi-dkms (1.0) ...
Loading new db9_gpio_rpi-1.0 DKMS files...
First Installation: checking all kernels...
dpkg: warning: version '*-*' has bad syntax: version number does not start with digit
It is likely that 4.4.11+ belongs to a chroot's host
Building for architecture armv6l
Module build for the currently running kernel was skipped since the
kernel source for this kernel does not seem to be installed.

It has been suggested elsewhere that it is sufficient to install kernel headers and that is what I have attempted. However, the kernel headers I've found requires gcc-4.7 and not 4.9, which is what is installed in the latest RetroPI distribution:

Code: Select all

Preparing to unpack linux-headers-4.4.11+_4.4.11+-2_armhf.deb ...
Unpacking linux-headers-4.4.11+ (4.4.11+-2) ...
dpkg: dependency problems prevent configuration of linux-headers-4.4.11+:
 linux-headers-4.4.11+ depends on gcc-4.7; however:
  Package gcc-4.7 is not installed.

dpkg: error processing package linux-headers-4.4.11+ (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-headers-4.4.11+

Where can I find kernel headers matching the kernel and gcc versions of the latest RetroPI distribution?

Thanks,
Lars

[marqs]

Where can I find kernel headers matching the kernel and gcc versions of the latest RetroPI distribution?

Is it possible to upgrade kernel on RetroPI (e.g. using rpi-update)? I just updated the script which generates kernel headers to omit gcc-4.7 depedency so they should install now fine if you have newest RPi foundation kernel (4.4.16+).

[larsmjoh]

Is it possible to upgrade kernel on RetroPI (e.g. using rpi-update)? I just updated the script which generates kernel headers to omit gcc-4.7 depedency so they should install now fine if you have newest RPi foundation kernel (4.4.16+).

I guess this https://github.com/Hexxeh/rpi-update#ro ... -boot_path method should work?

Will try it later this evening...

[larsmjoh]

OK, so I had a try and the upgrade seems to have worked, but when I install the headers i get this at the end:

Code: Select all

...
/bin/sh: 1: bc: not found
Kbuild:66: recipe for target 'include/generated/timeconst.h' failed
make[1]: *** [include/generated/timeconst.h] Error 127
Makefile:987: recipe for target 'prepare0' failed
make: *** [prepare0] Error 2
make: Leaving directory '/usr/src/linux-headers-4.4.16+'

------------------------------
Deleting module version: 1.0
completely from the DKMS tree.
------------------------------
Done.
Loading new db9_gpio_rpi-1.0 DKMS files...
First Installation: checking all kernels...
dpkg: warning: version '*-*' has bad syntax: version number does not start with digit
It is likely that 4.4.16+ belongs to a chroot's host
Building for architecture armv6l
Building initial module for 4.4.16+
Error! Bad return status for module build on kernel: 4.4.16+ (armv6l)
Consult /var/lib/dkms/db9_gpio_rpi/1.0/build/make.log for more information.

The db9 make.log look like this:

Code: Select all

DKMS make.log for db9_gpio_rpi-1.0 for kernel 4.4.16+ (armv6l)
Thu  4 Aug 23:06:24 UTC 2016
make -C /lib/modules/4.4.16+/build M=/var/lib/dkms/db9_gpio_rpi/1.0/build modules
make[1]: Entering directory '/usr/src/linux-headers-4.4.16+'
  CC [M]  /var/lib/dkms/db9_gpio_rpi/1.0/build/db9_gpio_rpi.o
In file included from include/linux/ktime.h:25:0,
                 from include/linux/rcupdate.h:47,
                 from include/linux/srcu.h:33,
                 from include/linux/notifier.h:15,
                 from include/linux/memory_hotplug.h:6,
                 from include/linux/mmzone.h:735,
                 from include/linux/gfp.h:5,
                 from include/linux/kmod.h:22,
                 from include/linux/module.h:13,
                 from /var/lib/dkms/db9_gpio_rpi/1.0/build/db9_gpio_rpi.c:32:
include/linux/jiffies.h:10:33: fatal error: generated/timeconst.h: No such file or directory
 #include <generated/timeconst.h>
                                 ^
compilation terminated.
scripts/Makefile.build:264: recipe for target '/var/lib/dkms/db9_gpio_rpi/1.0/build/db9_gpio_rpi.o' failed
make[2]: *** [/var/lib/dkms/db9_gpio_rpi/1.0/build/db9_gpio_rpi.o] Error 1
Makefile:1385: recipe for target '_module_/var/lib/dkms/db9_gpio_rpi/1.0/build' failed
make[1]: *** [_module_/var/lib/dkms/db9_gpio_rpi/1.0/build] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.4.16+'
Makefile:5: recipe for target 'all' failed
make: *** [all] Error 2

Any tips?