On this MPR121 capacitive keypad (link), what is the purpose of the IRQ out?
What is the IRQ out in I2C?
I'll give a slightly different focus from some other answers.
Remember that I2C Slaves cannot initiate an I2C bus transaction. Therefore if you have an I2C keypad or touch screen controller (or other HMI) how would the I2C Master know when to request data from the I2C keypad controller, to ask whether or not there had been a touch or release?
Three possibilities include:
I2C Master sometimes polls the I2C keypad controller, but not as a high priority.
Problem - Potential delay between the touch/release and the I2C Master polling the I2C keypad controller, leads to poor user experience, due to perceived "lag" (delay) between a touch/release and the machine's response.
I2C Master spends lots of time polling the I2C keypad controller, to minimise any lag between a touch/release and the I2C Master actually detecting that this has occurred.
Problem - I2C Master has fewer CPU cycles for doing anything else, since it is spending so much of its time polling the I2C keypad controller. The I2C bus also has reduced bandwidth for bus transactions to any other I2C devices, due to so many polls to the I2C keypad controller.
I2C Slave has an extra "interrupt" signal connected to the I2C Master (not part of the I2C specification, but this was introduced in SMBus). This allows the I2C Slave to alert the I2C Master and effectively say "poll me now!".
Problem - Requires an extra signal line between the I2C Master and the I2C Slave.
As you see, your I2C keypad controller chose the last option (some I2C touch screen controllers do the same thing.) This is an example of the poll vs. interrupt choice, which occurs in computer science and elsewhere in life e.g. you could stay awake and continuously check the clock to see when to get up in the morning (polling), or you could set an alarm and let that wake you (interrupt).
From the datasheet:
The MPR121 is an Inter-Integrated Circuit (I2C) compliant device with an additional interrupt that is triggered any time a touch or release of a button is detected.
Therefore the nIRQ output changes state whenever a touch or release of a button is detected.
Per the part used on that board's data sheet here, "This pin is triggered any time a touch or release is detected."
Although the I2C is a multi-master bus which would in theory allow a device like a keypad to send data to the main controller any time a key was hit and the bus is idle, life for an I2C master is much easier if it is the only master on the bus. Unless the (every) bus master is prepared for the possibility of another device requesting attention at arbitrary times, there won't be any way for a device like a keyboard to let anyone know when something happens, unless it is continuously and repeatedly asked. If power consumption isn't an issue, a system could simply ask such devices about their state any time there isn't anything better to do. Such an approach, however, would consume power continuously even when nothing of interest is happening.
In many cases, the simplest way to deal with this is to have such devices include a separate "interrupt request" pin which essentially means "I have something interesting to say--ask me about it and I'll tell you". If multiple devices share the same output pin, the master will be able to go to sleep when nobody has anything interesting to say (and nothing interesting is happening anywhere else). As soon as anything interesting happens, someone will assert the /IRQ pin, whereupon the master can start asking devices what they have to say.
It would be possible for the master to use a separate /IRQ input for each device, and then use those to determine which device it should talk to, but in many cases that isn't really needed. If a device has nothing to say, asking it won't generally take very long. What's important is recognizing the times where nobody has anything interesting to say, and minimizing power consumption during those times.