I was wandering if there's a way in witch the OS doesn't need to cycle ad infinitum waiting for the input from keyboard (or other input device) and if there are any OS using that. I can't believe that we do need to waste cycling just to wait for input, why can't the input do something once is pressed instead of having the machine to wait for the action.
Long story short:
How keyboard input is currently handled - polling or interrupts?
You can just check keyboard input using a non blocking function and if there is nothing, cooperatively yield, using sleep(1) or similar construct.
You don't need to waste the CPU you've been scheduled.
It's totally possible a blocking keyboard function might yield by itself and the OS will only resume the thread once it has input.
Most modern programs don't get input in a loop as you describe. You can use event handling or interrupts to avoid wasted cycles.
The only time I've seen polling is when dealing with a raw DirectX input device (since they fall outside the scope of the typical H/W architecture). You have to poll those devices (which could be mice, keyboards, joysticks, gamepads, etc...) to get their current state. As everyone else has stated, the typical keyboard is handled via interrupts.
All device input from all devices on all Linux-based OS is all interrupt-driven. Busy waiting (active polling) for data is not used.
Windows is probably all interrupt-driven, also. (Windows has that DOS legacy hiding inside it -- polling may still happen in there.)
All of Linux works the same way. The kernel waits for interrupts, queues up the interrupts and checks the scheduler to handle the highest-priority interrupt next. Process scheduling is always lower priority than interrupt scheduling.
The keyboard interrupts are handled by a driver which buffers the information. A window manager (Gnome, for example) fetches stuff from the buffer to create a stream of keyboard interrupts.
You can buy numerous really good books on OS design that cover the relationship between device drivers and the kernel. Start with http://lwn.net/Kernel/LDD3/
Clock interrupts, BTW, are how process scheduling happens. Absent any device activity, the clock will interrupt periodically, forcing the kernel to look at the schedule, possibly changing which process is executing. A process that uses a lot of CPU has it's priority lowered. A process that does a lot of I/O spends most of it's time waiting for I/O to finish, so it's priority is raised.
Edit
Also, there are -- sometimes -- DMA devices which bypass kernel interrupt handling for block transfers of bytes. An interrupt initiates the transfer, but the device lives on the bus and accesses memory directory. Video displays, disks (and in the olden times, network devices) may be DMA. Keyboards, however, are so low volume that DMA isn't a helpful optimization.
Usually it goes like this:
So, there is no polling (active wait) at any stage.
Edit: As far as I remember, the Linux kernel sometimes switches to polling for devices that would otherwise flood it with interrupts (think fast network card receiving a huge number of packets). Under these conditions, it saves CPU time instead of wasting it - OS gets a large chunk of data with one poll instead of many small chunks with many interrupts. When polling no longer gets any data, the OS switches back to waiting-for-intterupt mode.
USB devices cannot generate interrupts and are therefore polled by the operating system many times per second. Gamers sometimes like to increase this polling frequency to get a more responsive mouse.
Games often use polling to handle input, but other applications are far more likely to sleep until the operating system sends them input.