Use interrupts. A mouse is a slow, slow device, and frequently inactive. Devoting a polling process to the mouse would be wasteful of CPU cycles because a majority of the time the polling device would find the mouse status unchanged from the previous poll. This could be dealt with by increasing the polling interval, but then the mouse would seem unresponsive when it is in use.
Most people got this one mostly right, although there were some odd justifications. Contexts switches appeared in some answers, although it wasn't usualy clear whether the claim was that an poll requires fewer context switches than does an interrupt (it doesn't) or whether interrupts use fewer context switches over all (it does).
A user process making a non-block disk I-O call returns immediately after issuing an operation (a read or write), rather than blocking until the operation continues.
The principle change required by non-blocking is a new system call that lets a user process determine when its o.k. to manipulate the buffer passed along with the disk operation. This status system call would, for example, return false while the buffer is being used in the operation and true when the buffer is ready for further use by the user process.
Another change, not required but helpful for providing improved concurrency, is internal buffering within the disk driver. Internal buffering lets the controller finish with the user-process supplied earlier than might be possible otherwise (this makes more sense for reading than for writing). On the other hand, copying increases the cost for the operation by moving data one more time than is necessary.
For example at time t1, X stopped executing and Z began executing.
Identify X, Y, and Z with the execution traces for the two applications and the I-O controller (it will not be possible to distinguish between the two applications). Describe the execution history of the whole system moving from left to right along the x-axis (be sure to use your identified processes in your description, not X, Y, and Z).
With only one CPU, both application processes can't be running at the same time. Because it is running at the same time as both X and Y, it must be that Z is the I-O controller and X and Y are the application processes.
Reading from left to right, application X starts and runs until t1, at which point it issues an I-O request, which is handled by the controller. Some time after t1 application Y starts and runs until t2, at which point it leaves the CPU and a short time later regains the CPU as application X is still waiting for its I-O request to finish. At t3 application X's I-O request is completed and application Y makes an I-O request. The controller continues execution, as does application X; application Y is suspended. The I-O request finishes at t4. Application X terminates at t5, at which point application Y regains the CPU and terminates a short time later.
A lot of answers had two user processes runing at the same time, which should have been a tip-off that there was something suspect in your answer.
Two processes can always cause deadlock by successfully allocating half of an available resource and then requesting the other half. Because this can never happen, it must be that there can't be two processes running at the same time. The scheduler is a non-preemptive, batch scheduler.
A number of people, aparently remenbering the non-preemptive requirement for deadlock, suggested using a preemptive scheduler. But, a preemptive scheduler only manages the CPU; it is not directly involved with managing other resources. Some people mentioned a scheduler the implemented the Banker's Algorithm. Besides the fact that this contradicted the "no special requirements" part of the question, you don't put an implementation of the Banker's Algorithm in the scheduler; it belongs in the global resource manager.