The "sensor" has usually something to make the pictures (IAS) and something to calculate out of the pictures movement (DSP) additionally to some parts for control of led (ctrl), operation (oscillator) and communication (serial port).
This movement data is transfered to a microcontroller (MCU) who will handle the connection to the PC and controls all the buttons and additional features that might be necessary.
The firmware usually refers to the code running on the MCU, the SROM refers to the code running in the DSP.
So while your firmware might be done somewhere in a chinese garage by the cheapest option available, the SROM is released from the sensor vendor, ususally some kind of international corporation.
Meaning even if the sensor uses native 1800 cpi the result could be influenced by the mcus firmware (delayed, lost, changed etc).
However the chances that this happens on a native setting are slim and at least you would not suffer from bad algorithms that may have been used to get form 1800 (native) to 450 cpi.
Much more elegant would be to get all cpi values supported as native values by the SROM.