Hi,
Lukand wrote:
It seems I could not get input from mouse now. What does happens is that keyboard interferes mouse, eg. input from keyboard has interference with mouse input. Through moving mouse and clicking on it does nothing, but typing keys does.
Sadly there's no way to seperate keyboard input with mouse input except using semaphores as used in multithreading...
I told you that would happen (that the drivers would interfere with each other) and how to avoid the problem
last month.
Mostly; there are 3 different devices, so you need 3 separate drivers (one for the PS/2 controller itself, and one for each type of device that could be plugged into a PS/2 port) in the same way that you'd have multiple drivers for USB (one for the USB controller, and one for each type of device that could be plugged into a USB port).
Note: By "3 separate drivers" I don't necessarily mean (e.g.) 3 separate processes (for micro-kernel) or 3 separate "kernel modules" (for monolithic). It could just be "logical separation" (where the source code is split into 3 separate directories, but it's all assembled/compiled/linked together and becomes a single executable/process/kernel module).The "PS/2 controller driver" would initialise (and test) the controller, determine if there are any devices plugged into the PS/2 ports and get their "device ID", then use the "device ID" to determine which drivers are needed and start the right driver (note that you can have 2 keyboards and no mouse, or 2 mouse and no keyboards, or a bar-code scanner and a touch-pad and no keyboards and no mouse, or...).
The drivers for devices plugged into a PS/2 port (e.g. the keyboard driver and mouse driver) would ask the "PS/2 controller driver" to send bytes to whichever port it's connected to, and the "PS/2 controller driver" would tell the driver for a PS/2 port about any bytes received. The drivers for devices plugged into a PS/2 port would never use any IO ports or IRQs themselves. If you port your OS to a different type of computer (with a different type of PS/2 controller - e.g. the
PL050 on some ARM SoCs) you only need to write a new "PS/2 controller driver" and (assuming C source code or something) will not need to change any driver for a PS/2 device (the keyboard, mouse, bar-code, touch-pad, touch-screen, .... drivers).
Another thing the "PS/2 controller driver" would do is handle "hot-plug" - if the user unplugs a device it'd tell (terminate?) whichever driver was using that PS/2 port, and if a user plugs a device into a previously empty PS/2 port the "PS/2 controller driver" would figure out the type of device that was plugged in and start an appropriate driver. The "PS/2 controller driver" could also (optionally) monitor the other drivers - e.g. if your keyboard driver crashes then "PS/2 controller driver" might notice and start another keyboard driver; and if you install a newer keyboard driver then "PS/2 controller driver" might notice and terminate the old driver and start the new one.
Finally; it'd probably be nice to build support for debugging into your "PS/2 controller driver"; so that anyone writing a driver for any PS/2 device can enable debugging for whichever port the device is connected to and see all bytes received by their driver and see all bytes sent by their driver (without having any code in their driver). This just makes it much easier for people (you) to write drivers for different PS/2 devices.
Cheers,
Brendan
I already do all of that, based on info on PS/2 controller wiki page.