1 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN"[]>
5 <title>Mouse Drivers</title>
9 <firstname>Alan</firstname>
10 <surname>Cox</surname>
13 <email>alan@redhat.com</email>
21 <holder>Alan Cox</holder>
26 This documentation is free software; you can redistribute
27 it and/or modify it under the terms of the GNU General Public
28 License as published by the Free Software Foundation; either
29 version 2 of the License, or (at your option) any later
34 This program is distributed in the hope that it will be
35 useful, but WITHOUT ANY WARRANTY; without even the implied
36 warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
37 See the GNU General Public License for more details.
41 You should have received a copy of the GNU General Public
42 License along with this program; if not, write to the Free
43 Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
48 For more details see the file COPYING in the source
49 distribution of Linux.
57 <title>Introduction</title>
59 <title>Earlier publication</title>
61 Parts of this document first appeared in Linux Magazine under a
62 ninety day exclusivity.
67 Mice are conceptually one of the simplest device interfaces in the
68 Linux operating system. Not all mice are handled by the kernel.
69 Instead there is a two layer abstraction.
73 The kernel mouse drivers and userspace drivers for the serial mice are
74 all managed by a system daemon called <application>gpm</application>
75 - the general purpose mouse driver. <application>gpm</application>
76 handles cutting and pasting on the text consoles. It provides a
77 general library for mouse-aware applications and it handles the
78 sharing of mouse services with the
79 <application>X Window System</application> user interface.
82 Sometimes a mouse speaks a sufficiently convoluted protocol that the
83 protocol is handled by <application>Gpm</application> itself. Most
84 of the mouse drivers follow a common interface called the bus mouse
88 Each read from a bus mouse interface device returns a block of data.
89 The first three bytes of each read are defined as follows:
92 <title>Mouse Data Encoding</title>
93 <tgroup cols=2 align=left>
97 <entry>0x80 + the buttons currently down.</entry>
100 <entry>Byte 1</entry>
101 <entry>A signed value for the shift in X position</entry>
104 <entry>Byte 2</entry>
105 <entry>A signed value for the shift in Y position</entry>
111 An application can choose to read more than 3 bytes. The rest of the
112 bytes will be zero, or may optionally return some additional
113 device-specific information.
116 The position values are truncated if they exceed the 8bit range (that
117 is -127 <= delta <= 127). While the value -128 does fit into a
121 The <mousebutton>buttons</mousebutton> are numbered left to right as
122 0, 1, 2, 3.. and each button sets the relevant bit. So a user pressing
123 the left and right button of a three button mouse will set bits 0 and 2.
126 All mice are required to support the <function>poll</function>
127 operation. Indeed pretty much every user of a mouse device uses
128 <function>poll</function> to wait for mouse events to occur.
131 Finally the mice support asynchronous I/O. This is a topic we have not
132 yet covered but which I will explain after looking at a simple mouse
137 <chapter id="driver">
138 <title>A simple mouse driver</title>
140 First we will need the set up functions for our mouse device. To keep
141 this simple our imaginary mouse device has three I/O ports fixed at I/O
142 address 0x300 and always lives on interrupt 5. The ports will be the X
143 position, the Y position and the buttons in that order.
147 #define OURMOUSE_BASE 0x300
149 static struct miscdevice our_mouse = {
150 OURMOUSE_MINOR, "ourmouse", &our_mouse_fops
153 __init ourmouse_init(void)
156 if(check_region(OURMOUSE_BASE, 3))
158 request_region(OURMOUSE_BASE, 3, "ourmouse");
160 misc_register(&our_mouse);
166 The <structname>miscdevice</structname> is new here. Linux normally
167 parcels devices out by major number, and each device has 256 units.
168 For things like mice this is extremely wasteful so a device exists
169 which is used to accumulate all the odd individual devices that
170 computers tend to have.
173 Minor numbers in this space are allocated by a central source, although
174 you can look in the kernel <filename>Documentation/devices.txt</filename>
175 file and pick a free one for development use. This kernel file also
176 carries instructions for registering a device. This may change over time
177 so it is a good idea to obtain a current copy of this file first.
180 Our code then is fairly simple. We check nobody else has taken our
181 address space. Having done so we reserve it to ensure nobody stamps
182 on our device while probing for other ISA bus devices. Such a probe
183 might confuse our device.
186 Then we tell the misc driver that we wish to own a minor number. We also
187 hand it our name (which is used in
188 <filename class="directory">/proc/misc</filename>) and a set of file
189 operations that are to be used. The file operations work exactly like the
190 file operations you would register for a normal character device. The misc
191 device itself is simply acting as a redirector for requests.
194 Next, in order to be able to use and test our code we need to add some
195 module code to support it. This too is fairly simple:
200 int init_module(void)
202 if(ourmouse_init()<0)
207 void cleanup_module(void)
209 misc_deregister(&our_mouse);
210 free_region(OURMOUSE_BASE, 3);
218 The module code provides the normal two functions. The
219 <function>init_module</function> function is called when the module is
220 loaded. In our case it simply calls the initialising function we wrote
221 and returns an error if this fails. This ensures the module will only
222 be loaded if it was successfully set up.
225 The <function>cleanup_module</function> function is called when the
226 module is unloaded. We give the miscellaneous device entry back, and
227 then free our I/O resources. If we didn't free the I/O resources then
228 the next time the module loaded it would think someone else had its I/O
232 Once the <function>misc_deregister</function> has been called any
233 attempts to open the mouse device will fail with the error
234 <errorcode>ENODEV</errorcode> (<errorname>No such device</errorname>).
237 Next we need to fill in our file operations. A mouse doesn't need many
238 of these. We need to provide open, release, read and poll. That makes
239 for a nice simple structure:
243 struct file_operations our_mouse_fops = {
244 NULL, /* Mice don't seek */
245 read_mouse, /* You can read a mouse */
246 write_mouse, /* This won't do a lot */
247 NULL, /* No readdir - not a directory */
248 poll_mouse, /* Poll */
249 NULL, /* No ioctl calls */
251 open_mouse, /* Called on open */
252 NULL, /* Flush - 2.2+ only */
253 close_mouse, /* Called on close */
258 There is nothing particularly special needed here. We provide functions
259 for all the relevant or required operations and little else. There is
260 nothing stopping us providing an ioctl function for this mouse. Indeed
261 if you have a configurable mouse it may be very appropriate to provide
262 configuration interfaces via ioctl calls.
265 The open and close routines need to manage enabling and disabling the
266 interrupts for the mouse as well as stopping the mouse being unloaded
267 when it is no longer required.
271 static int mouse_users = 0; /* User count */
272 static int mouse_dx = 0; /* Position changes */
273 static int mouse_dy = 0;
274 static int mouse_event = 0; /* Mouse has moved */
276 static int open_mouse(struct inode *inode, struct file *file)
283 if(request_irq(mouse_intr, OURMOUSE_IRQ, 0, "ourmouse", NULL))
297 The open function has to do a small amount of housework. We keep a count
298 of the number of times the mouse is open. This is because we do not want
299 to request the interrupt multiple times. If the mouse has at least one
300 user then it is set up and we simply add to the user count and return
301 <returnvalue>0</returnvalue> for success.
304 Firstly we use <function>MOD_INC_USE_COUNT</function> to ensure that
305 while the mouse is open nobody will unload it and cause a nasty crash.
306 We must do this before we sleep - and grabbing the interrupt might sleep.
309 We grab the interrupt and thus start mouse interrupts. If the interrupt
310 has been borrowed by some other driver then <function>request_irq</function>
311 will fail and we will return an error. If we were capable of sharing an
312 interrupt line we would specify <constant>SA_SHIRQ</constant> instead of
313 <constant>zero</constant>. Provided that everyone claiming an interrupt
314 sets this flag, they get to share the line. <hardware>PCI</hardware> can
315 share interrupts, <hardware>ISA</hardware> normally however cannot.
318 We do the housekeeping. We make the current mouse position the starting
319 point for accumulated changes and declare that nothing has happened
320 since the mouse driver was opened.
323 The release function needs to unwind all these:
326 static int close_mouse(struct inode *inode, struct file *file)
330 free_irq(OURMOUSE_IRQ, NULL);
336 We count off a user and provided that there are still other users need
337 take no further action. The last person closing the mouse causes us to
338 free up the interrupt. This stopps interrupts from the mouse from using
339 our CPU time, and lets us use <function>MOD_DEC_USE_COUNT</function> so
340 that the mouse can now be unloaded.
343 We can fill in the write handler at this point as the write function for
344 our mouse simply declines to allow writes:
348 static ssize_t write_mouse(struct file *file, const char *buffer, size_t
356 This is pretty much self-explanatory. Whenever you write you get told
357 it was an invalid function.
360 To make the poll and read functions work we have to consider how we
361 handle the mouse interrupt.
365 static struct wait_queue *mouse_wait;
366 static spinlock_t mouse_lock = SPIN_LOCK_UNLOCKED;
368 static void ourmouse_interrupt(int irq, void *dev_id, struct pt_regs *regs)
372 unsigned char new_buttons;
374 delta_x = inb(OURMOUSE_BASE);
375 delta_y = inb(OURMOUSE_BASE+1);
376 new_buttons = inb(OURMOUSE_BASE+2);
378 if(delta_x || delta_y || new_buttons != mouse_buttons)
380 /* Something happened */
382 spin_lock(&mouse_lock);
386 mouse_buttons = new_buttons;
387 spin_unlock(&mouse_lock);
389 wake_up_interruptible(&mouse_wait);
395 The interrupt handler reads the mouse status. The next thing we do is
396 to check whether something has changed. If the mouse was smart it would
397 only interrupt us if something had changed, but let's assume our mouse
398 is stupid as most mice actually tend to be.
401 If the mouse has changed we need to update the status variables. What we
402 don't want is the mouse functions reading these variables to read them
403 during a change. We add a spinlock that protects these variables while we
407 If a change has occured we also need to wake sleeping processes, so we
408 add a wakeup call and a <structname>wait_queue</structname> to use when
409 we wish to await a mouse event.
412 Now we have the wait queue we can implement the poll function for the
413 mouse relatively easily:
417 static unsigned int mouse_poll(struct file *file, poll_table *wait)
419 poll_wait(file, &mouse_wait, wait);
421 return POLLIN | POLLRDNORM;
427 This is fairly standard poll code. First we add the wait queue to the
428 list of queues we want to monitor for an event. Secondly we check if an
429 event has occured. We only have one kind of event - the
430 <varname>mouse_event</varname> flag tells us that something happened.
431 We know that this something can only be mouse data. We return the flags
432 indicating input and normal reading will succeed.
435 You may be wondering what happens if the function returns saying 'no
436 event yet'. In this case the wake up from the wait queue we added to
437 the poll table will cause the function to be called again. Eventually
438 we will be woken up and have an event ready. At this point the
439 <function>poll</function> call will exit back to the user.
442 After the poll completes the user will want to read the data. We now
443 need to think about how our <function>mouse_read</function> function
447 static ssize_t mouse_read(struct file *file, char *buffer,
448 size_t count, loff_t *pos)
451 unsigned char button;
464 if(file->f_flags&O_NDELAY)
466 interruptible_sleep_on(&mouse_wait);
467 if(signal_pending(current))
473 We start by validating that the user is reading enough data. We could
474 handle partial reads if we wanted but it isn't terribly useful and the
475 mouse drivers don't bother to try.
478 Next we wait for an event to occur. The loop is fairly standard event
479 waiting in Linux. Having checked that the event has not yet occured, we
480 then check if an event is pending and if not we need to sleep.
483 A user process can set the <constant>O_NDELAY</constant> flag on a file
484 to indicate that it wishes to be told immediately if no event is
485 pending. We check this and give the appropriate error if so.
488 Next we sleep until the mouse or a signal awakens us. A signal will
489 awaken us as we have used <function>wakeup_interruptible</function>.
490 This is important as it means a user can kill processes waiting for
491 the mouse - clearly a desireable property. If we are interrupted we
492 exit the call and the kernel will then process signals and maybe
493 restart the call again - from the beginning.
496 This code contains a classic Linux bug. All will be revealed later in this
497 article as well as explanations for how to avoid it.
502 spinlock_irqsave(&mouse_lock, flags);
506 button = mouse_buttons;
520 if(mouse_dx == 0 && mouse_dy == 0)
523 spin_unlock_irqrestore(&mouse_lock, flags);
526 This is the next stage. Having established that there is an event
527 going, we capture it. To be sure that the event is not being updated
528 as we capture it we also take the spinlock and thus prevent parallel
529 updates. Note here we use <function>spinlock_irqsave</function>. We
530 need to disable interrupts on the local processor otherwise bad things
534 What will occur is that we take the spinlock. While we hold the lock
535 an interrupt will occur. At this point our interrupt handler will try
536 and take the spinlock. It will sit in a loop waiting for the read
537 routine to release the lock. However because we are sitting in a loop
538 in the interrupt handler we will never release the lock. The machine
539 hangs and the user gets upset.
542 By blocking the interrupt on this processor we ensure that the lock
543 holder will always give the lock back without deadlocking.
546 There is a little cleverness in the reporting mechanism too. We can
547 only report a move of 127 per read. We don't however want to lose
548 information by throwing away further movement. Instead we keep
549 returning as much information as possible. Each time we return a
550 report we remove the amount from the pending movement in
551 <varname>mouse_dx</varname> and <varname>mouse_dy</varname>. Eventually
552 when these counts hit zero we clear the <varname>mouse_event</varname>
553 flag as there is nothing else left to report.
557 if(put_user(button|0x80, buffer))
559 if(put_user((char)dx, buffer+1))
561 if(put_user((char)dy, buffer+2))
564 for(n=3; n < count; n++)
565 if(put_user(0x00, buffer+n))
573 Finally we must put the results in the user supplied buffer. We cannot
574 do this while holding the lock as a write to user memory may sleep.
575 For example the user memory may be residing on disk at this instant.
576 Thus we did our computation beforehand and now copy the data. Each
577 <function>put_user call</function> is filling in one byte of the buffer.
578 If it returns an error we inform the program that it passed us an
579 invalid buffer and abort.
582 Having written the data we blank the rest of the buffer that was read
583 and report the read as being successful.
587 <chapter id="debugging">
588 <title>Debugging the mouse driver</title>
591 We now have an almost perfectly usable mouse driver. If you were to
592 actually try and use it however you would eventually find a couple of
593 problems with it. A few programs will also not work with as it does not
594 yet support asynchronous I/O.
597 First let us look at the bugs. The most obvious one isn't really a driver
598 bug but a failure to consider the consequences. Imagine you bumped the
599 mouse hard by accident and sent it skittering across the desk. The mouse
600 interrupt routine will add up all that movement and report it in steps of
601 127 until it has reported all of it. Clearly there is a point beyond
602 which mouse movement isn't worth reporting. We need to add this as a
603 limit to the interrupt handler:
607 static void ourmouse_interrupt(int irq, void *dev_id, struct pt_regs *regs)
611 unsigned char new_buttons;
613 delta_x = inb(OURMOUSE_BASE);
614 delta_y = inb(OURMOUSE_BASE+1);
615 new_buttons = inb(OURMOUSE_BASE+2);
617 if(delta_x || delta_y || new_buttons != mouse_buttons)
619 /* Something happened */
621 spin_lock(&mouse_lock);
626 if(mouse_dx < -4096)
628 if(mouse_dx > 4096)
631 if(mouse_dy < -4096)
633 if(mouse_dy > 4096)
636 mouse_buttons = new_buttons;
637 spin_unlock(&mouse_lock);
639 wake_up_interruptible(&mouse_wait);
645 By adding these checks we limit the range of accumulated movement to
649 The second bug is a bit more subtle, and that is perhaps why this is
650 such a common mistake. Remember, I said the waiting loop for the read
651 handler had a bug in it. Think about what happens when we execute:
660 and an interrupt occurs at this point here. This causes a mouse movement
661 and wakes up the queue.
665 interruptible_sleep_on(&mouse_wait);
669 Now we sleep on the queue. We missed the wake up and the application
670 will not see an event until the next mouse event occurs. This will
671 lead to just the odd instance when a mouse button gets delayed. The
672 consequences to the user will probably be almost undetectable with a
673 mouse driver. With other drivers this bug could be a lot more severe.
676 There are two ways to solve this. The first is to disable interrupts
677 during the testing and the sleep. This works because when a task sleeps
678 it ceases to disable interrupts, and when it resumes it disables them
679 again. Our code thus becomes:
688 if(file->f_flags&O_NDELAY)
690 restore_flags(flags);
693 interruptible_sleep_on(&mouse_wait);
694 if(signal_pending(current))
696 restore_flags(flags);
700 restore_flags(flags);
704 This is the sledgehammer approach. It works but it means we spend a
705 lot more time turning interrupts on and off. It also affects
706 interrupts globally and has bad properties on multiprocessor machines
707 where turning interrupts off globally is not a simple operation, but
708 instead involves kicking each processor, waiting for them to disable
709 interrupts and reply.
712 The real problem is the race between the event testing and the sleeping.
713 We can avoid that by using the scheduling functions more directly.
714 Indeed this is the way they generally should be used for an interrupt.
718 struct wait_queue wait = { current, NULL };
720 add_wait_queue(&mouse_wait, &wait);
721 current->state = TASK_INTERRUPTIBLE;
725 if(file->f_flags&O_NDELAY)
727 remove_wait_queue(&mouse_wait, &wait);
728 current->state = TASK_RUNNING;
731 if(signal_pending(current))
733 remove_wait_queue(&mouse_wait, &wait);
734 current->state = TASK_RUNNING;
738 current->state = TASK_INTERRUPTIBLE;
741 remove_wait_wait(&mouse_wait, &wait);
742 current->state = TASK_RUNNING;
746 At first sight this probably looks like deep magic. To understand how
747 this works you need to understand how scheduling and events work on
748 Linux. Having a good grasp of this is one of the keys to writing clean
749 efficient device drivers.
752 <function>add_wait_queue</function> does what its name suggests. It adds
753 an entry to the <varname>mouse_wait</varname> list. The entry in this
754 case is the entry for our current process (<varname>current</varname>
755 is the current task pointer).
758 So we start by adding an entry for ourself onto the
759 <varname>mouse_wait</varname> list. This does not put us to sleep
760 however. We are merely tagged onto the list.
763 Next we set our status to <constant>TASK_INTERRUPTIBLE</constant>. Again
764 this does not mean we are now asleep. This flag says what should happen
765 next time the process sleeps. <constant>TASK_INTERRUPTIBLE</constant> says
766 that the process should not be rescheduled. It will run from now until it
767 sleeps and then will need to be woken up.
770 The <function>wakeup_interruptible</function> call in the interrupt
771 handler can now be explained in more detail. This function is also very
772 simple. It goes along the list of processes on the queue it is given and
773 any that are marked as <constant>TASK_INTERRUPTIBLE</constant> it changes
774 to <constant>TASK_RUNNING</constant> and tells the kernel that new
775 processes are runnable.
778 Behind all the wrappers in the original code what is happening is this
784 We add ourself to the mouse wait queue
789 We mark ourself as sleeping
794 We ask the kernel to schedule tasks again
799 The kernel sees we are asleep and schedules someone else.
804 The mouse interrupt sets our state to <constant>TASK_RUNNING</constant>
805 and makes a note that the kernel should reschedule tasks
810 The kernel sees we are running again and continues our execution
815 This is why the apparent magic works. Because we mark ourself as
816 <constant>TASK_INTERRUPTIBLE</constant> and as we add ourselves
817 to the queue before we check if there are events pending, the race
818 condition is removed.
821 Now if an interrupt occurs after we check the queue status and before
822 we call the <function>schedule</function> function in order to sleep,
823 things work out. Instead of missing an event, we are set back to
824 <constant>TASK_RUNNING</constant> by the mouse interrupt. We still call
825 <function>schedule</function> but it will continue running our task.
826 We go back around the loop and this time there may be an event.
829 There will not always be an event. Thus we set ourselves back to
830 <constant>TASK_INTERRUPTIBLE</constant> before resuming the loop.
831 Another process doing a read may already have cleared the event flag,
832 and if so we will need to go back to sleep again. Eventually we will
833 get our event and escape.
836 Finally when we exit the loop we remove ourselves from the
837 <varname>mouse_wait</varname> queue as we are no longer interested
838 in mouse events, and we set ourself back to
839 <constant>TASK_RUNNABLE</constant> as we do not wish to go to sleep
845 This isn't an easy topic. Don't be afraid to reread the description a
846 few times and also look at other device drivers to see how it works.
847 Finally if you can't grasp it just yet, you can use the code as
848 boilerplate to write other drivers and trust me instead.
853 <chapter id="asyncio">
854 <title>Asynchronous I/O</title>
856 This leaves the missing feature - Asynchronous I/O. Normally UNIX
857 programs use the <function>poll</function> call (or its variant form
858 <function>select</function>) to wait for an event to occur on one of
859 multiple input or output devices. This model works well for most tasks
860 but because <function>poll</function> and <function>select</function>
861 wait for an event isn't suitable for tasks that are also continually
862 doing computation work. Such programs really want the kernel to kick
863 them when something happens rather than watch for events.
866 Poll is akin to having a row of lights in front of you. You can see at a
867 glance which ones if any are lit. You cannot however get anything useful
868 done while watching them. Asynchronous I/O uses signals which work more
869 like a door bell. Instead of you watching, it tells you that something
873 Asynchronous I/O sends the signal SIGIO to a user process when the I/O
874 events occur. In this case that means when people move the mouse. The
875 SIGIO signal causes the user process to jump to its signal handler and
876 execute code in that handler before returning to whatever was going on
877 previously. It is the application equivalent of an interrupt handler.
880 Most of the code needed for this operation is common to all its users.
881 The kernel provides a simple set of functions for managing asynchronous
885 Our first job is to allow users to set asynchronous I/O on file handles.
886 To do that we need to add a new function to the file operations table for
891 struct file_operations our_mouse_fops = {
892 NULL, /* Mice don't seek */
893 read_mouse, /* You can read a mouse */
894 write_mouse, /* This won't do a lot */
895 NULL, /* No readdir - not a directory */
896 poll_mouse, /* Poll */
897 NULL, /* No ioctl calls */
899 open_mouse, /* Called on open */
901 close_mouse, /* Called on close */
902 NULL, /* No fsync on a mouse */
903 fasync_mouse, /* Asynchronous I/O */
908 Once we have installed this entry the kernel knows we support
909 asynchronous I/O and will allow all the relevant operations on the
910 device. Whenever a user adds or removes asynchronous I/O notification
911 on a file handle it calls our <function>fasync_mouse</function> routine
912 we just added. This routine uses the helper functions to keep the queue
913 of handles up to date:
917 static struct fasync_struct *mouse_fasync = NULL;
919 static int fasync_mouse(int fd, struct file *filp, int on)
921 int retval = fasync_helper(fd, filp, on, &mouse_fasync);
930 The fasync helper adds and deletes entries by managing the supplied
931 list. We also need to remove entries from this list when the file is
932 closed. This requires we add one line to our close function:
936 static int close_mouse(struct inode *inode, struct file *file)
938 fasync_mouse(-1, file, 0)
941 free_irq(OURMOUSE_IRQ, NULL);
948 When we close the file we now call our own fasync handler as if the
949 user had requested that this file cease to be used for asynchronous
950 I/O. This rather neatly cleans up any loose ends. We certainly don't
951 wait to deliver a signal for a file that no longer exists.
954 At this point the mouse driver supports all the asynchronous I/O
955 operations, and applications using them will not error. They won't
956 however work yet. We need to actually send the signals. Again the
957 kernel provides a function for handling this.
960 We update our interrupt handler a little:
964 static void ourmouse_interrupt(int irq, void *dev_id, struct pt_regs *regs)
968 unsigned char new_buttons;
970 delta_x = inb(OURMOUSE_BASE);
971 delta_y = inb(OURMOUSE_BASE+1);
972 new_buttons = inb(OURMOUSE_BASE+2);
974 if(delta_x || delta_y || new_buttons != mouse_buttons)
976 /* Something happened */
978 spin_lock(&mouse_lock);
983 if(mouse_dx < -4096)
985 if(mouse_dx > 4096)
988 if(mouse_dy < -4096)
990 if(mouse_dy > 4096)
993 mouse_buttons = new_buttons;
994 spin_unlock(&mouse_lock);
996 /* Now we do asynchronous I/O */
997 kill_fasync(&mouse_fasync, SIGIO);
999 wake_up_interruptible(&mouse_wait);
1005 The new code simply calls the <function>kill_fasync</function> routine
1006 provided by the kernel if the queue is non-empty. This sends the
1007 required signal (SIGIO in this case) to the process each file handle
1008 says should be informed about the exciting new mouse movement that
1012 With this in place and the bugs in the original version fixed, you now
1013 have a fully functional mouse driver using the bus mouse protocol. It
1014 will work with the <application>X window system</application>, will work
1015 with <application>GPM</application> and should work with every other
1016 application you need. <application>Doom</application> is of course the
1017 ideal way to test your new mouse driver is functioning properly. Be sure
1018 to test it thoroughly.