Specifications and algorithmic process for driver writing?

[MilkyGirl]

Hey, since my last question I've been having great success with a lot of the info provided, and I'm moving forward with Assembly and OS development.

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:

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?

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?

3.With a GUI library itself, are there any tutorials, insights, or at least design implementations of how one would accomplish a GUI or window system, etc.? Any books that delve in to this process, etc.?

Thanks.

[Combuster]

Did you ever write a game on top of plain SDL/DirectDraw? Those systems work primarily by going to the basics. You can't use native user interfaces as they break or look ugly, and even the mouse cursor must typically be drawn by you. It becomes even trickier if you go and make some interface like OpenTTD where you have a playfield with tons of windows and widgets (hint!) floating above it with all the user interaction tuning that comes along with it. And if you drop the "OS development" labels like that, you'll quickly find out there's actually a lot of source material on how you would proceed with custom user interfaces.

And when you know how that end of the party works, it becomes much easier to see what the other - driver - end should be doing.

And it's not a particular shame to leech designs from existing systems, as you can reuse parts of the wisdom of the engineers that built it. Truth be told, I expect that you'll be making a few very poor clones with your apparent experience first, but you'll learn from that as well.


At any rate, you won't be finding tutorials considering the whole architecture. That's the exercise for your own creativity.

[MilkyGirl]

I've used SDL and DirectX APIs before, but I don't get your point in full.

I obviously will be original with graphics data, as I am planning to write a program that draws .SBI custom format BITMAPs and renders them on the screen.

Here is one of my first drawn pointer examples, specifically for 640x480 screen mode in its current size: http://oi49.tinypic.com/z1usn.jpg

[Brendan]

Hi,

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.

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".

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

[tom9876543]

MilkyGirl,

Don't try to run before you have proven you can crawl.

Please develop a text mode based kernel before trying to implement graphics and a GUI.
Make sure the text based kernel can run multiple applications and read files from disk etc.
Networking would be good but I suppose you could choose to build the GUI before networking.

I look forward to downloading your text based kernel. Until then, don't waste time asking graphics questions.

[greyOne]

MilkyGirl,

Don't try to run before you have proven you can crawl.

Please develop a text mode based kernel before trying to implement graphics and a GUI.
Make sure the text based kernel can run multiple applications and read files from disk etc.
Networking would be good but I suppose you could choose to build the GUI before networking.

I look forward to downloading your text based kernel. Until then, don't waste time asking graphics questions.

Random reply to an old thread,
But you know, there's no given correct order to make things in.
If someone wants implement a graphical UI instead of a text based one, they reserve the right to do so.
James T. Klik if there are still any concerns.

Networking is probably one of the last things I'll do, save file IO and multitasking for example.
On the other hand, I run nicely in 80x50 text mode and have a functional buddy demand paging system.

Also, I'm pretty sure no one is obligated to let you try their kernel...

[Combuster]

Additional reply to a randomly bumped thread: The OP got himself banned.