If you're writing a real-world program that uses the mouse in Linux, you're most likely writing an X application, and in that case you should ask the X server for mouse events. Qt, GTK, and libsdl are some popular C libraries that provide functions for accessing mouse, keyboard, graphics, timers, and other features needed to write GUI programs. Ncurses is a similar library for terminal applications.
But if you're exploring your system, or you can't use X for whatever reason, here is how it works at the kernel interface.
A core idea in the UNIX philosophy is that "everything is a file". More specifically, as many things as possible should be accessible through the same system calls that you use to work with files. And so the kernel interface to the mouse is a device file. You
open() it, optionally call
select() on it to see if there's incoming data, and
read() to read the data.
In pre-USB times, the specific device file was often a serial port, e.g.
/dev/ttyS0, or a PS/2 port,
/dev/psaux. You talked to the mouse using whatever hardware protocol was built into the mouse. These days, the
/dev/input/* subsystem is preferred, as it provides a unified, device-independent way of handling many different input devices. In particular,
/dev/input/mice will give you events from any mouse attached to your system, and
/dev/input/mouseN will give you events from a particular mouse. In most modern Linux distributions, these files are created dynamically when you plug in a mouse.
For more information about exactly what you would read or write to the mouse device file, you can start with input/input.txt in the kernel documentation. Look in particular at sections 3.2.2 (mousedev) and 3.2.4 (evdev), and also sections 4 and 5.