Hi,
MilkyGirl wrote:One thing I am wondering now is with writing software to recognize and use devices, such as a PS/2 mouse to start off simply with, I'd like to ask some general questions:
Normally you'd have support for multi-tasking (and multi-threading), memory management and IPC; then you'd build a device driver framework on top of those things.
The hardware is naturally a hierarchical tree, and the software should also be a hierarchical tree. For example, at the top you'd have PCI host controllers, and one of them might have a "PCI to LPC bridge" as a child, which might have a "PS/2 controller" as a child, which might have a "PS/2 keyboard" as one child and a "PS/2 mouse" as another child. For device detection (and starting device drivers) you'd start from the top of the tree and work down - e.g. your PCI host controller driver is responsible for finding PCI devices on its bus and starting drivers for them, your "PCI to LPC bridge" driver is responsible for finding legacy devices and starting drivers for them, your "PS/2 controller" driver is responsible for detecting which sorts of PS/2 devices are connected to it and starting drivers for them.
A device driver may need to talk to its parent and its children. For example, a PS/2 keyboard driver (or mouse, touchscreen, touchpad, bar-code scanner, etc) would ask the PS/2 controller driver (its parent) to send bytes, and the PS/2 controller driver would tell its children about bytes received. The interface between (parent/child) device drivers depends on the type of device driver. For example, the interface used by a PS/2 controller driver and a PS/2 device driver may be very different to the interface used by a serial port driver and a serial port mouse.
In addition; a device driver may need an interface that normal software can use, and these interfaces need to be standardised. For example, you might have a PS/2 keyboard driver and a USB keyboard driver, and normal software (e.g. a GUI) shouldn't need to know or care which of these device drivers it's using because they both provide the exact same interface.
Finally, for good OSs (which doesn't necessarily include any existing OSs), device drivers also provide an interface for system management. For example, a device driver might track statistics for the device (e.g. how long it's been in operation) and know the device's "mean time between failures", and know exactly what sort of device it is. By using this information the OS might tell a system administrator "
this keyboard is due for regularly scheduled cleaning" or "
you'd better order a replacement "PS/2, US international QWERTY cordless keyboard" because this one has been in use for 9950 hours and the mean time between failures is 10000 hours".
This means that a device driver has up to deal with up to 6 interfaces - the interface provided by the kernel (for memory management, scheduling, IPC, etc), the device's hardware interface, the interface provided by its parent device, the interface it provides to its children, the interface it provides to normal software (GUI, file systems, the network stack, etc), and the interface it provides for system management utilities.
As an OS developer; it's your job to design (up to) 5 of those interfaces; and write specifications so that other people can develop device drivers for your OS and use the device drivers your OS already has.
MilkyGirl wrote:1.If I develop a super simple GUI by just filling a screen one color in mode 13h, and develop a point-and-click object, how would I go about best detecing and capturing movement through the GUI to the driver and execute it?
The only right answer is "To talk to the mouse/trackball/touchpad/touchscreen/joystick driver, the GUI does whatever your specifications say it should do".
MilkyGirl wrote:2.When writing ANY device driver in general, where would one get references, or possibly insight on how one would algorithmically or theoretically write software to move a screen object, update the screen, video drivers, GUI, etc.
Aside from just studying a piece of hardware, where else would one really understand the concepts behind design when it comes to actually writing code?
Simplified; applications tell the GUI what they want to display, GUI combines that info (from multiple applications and its own menus/desktop, etc) somehow and tells the video driver/s what it wants displayed, and video driver just displays what it's been told to display. For input devices this is reversed - e.g. keyboard driver tells GUI when a key was pressed, GUI decides if it should handle the keypress itself or forward it to an application (and which application).
For the concepts behind design when it comes to actually writing code, it's best to design one piece at a time then implement one piece at a time. For example, you might design the kernel's IPC then implement it; then design the video driver's interface them implement the video driver, then design the PS/2 controller's interface and implement that driver, then design the PS/2 keyboard driver's interface and implement that driver; and only then (when everything it relies on actually exists) worry about designing a GUI. If you try to mush it all together (e.g. designing and implementing everything at the same time) then you'll end up with dog vomit.
Cheers,
Brendan