The example driver for this article will show how to write a basic display driver which does not have any hardware associated with it. Instead this display driver will implement graphics to memory and an application will be used to display those graphics. This article will only be focusing on display drivers themselves and will not use VMWare but require just your local machine.
The first place to start is to show the display driver architecture as it is in Windows NT. This is essential in supporting the new Desktop Window Manager however Windows Vista still supports the old display driver model in conjunction with the old Window Manager.
This article will not be covering LDDM. The display driver model consists of two pieces, the miniport driver and the display driver.
The miniport driver is loaded into system space and is responsible for enumerating devices and managing device resources. The display driver is loaded into session space and is responsible for implementing the actual GDI graphics calls. The driver is responsible for implementing these calls however it wants which can be done in software or deferred to the graphics card itself.
The display driver has full control over how a line is drawn or how a transparency effect is implemented. The miniport driver is loaded into system space and is responsible for managing display device resources and enumerating devices. This driver exports APIs which your driver will link against and use. Surprised a driver can export APIs? Don't be. Drivers use the PE format and have export and import tables.
In fact all the APIs you use you are just linking against the kernel and other drivers. I will note there is a slight difference between linking against kernel and user mode drivers.
If a driver links against a driver that is not currently loaded into memory, that driver will become loaded into memory however the DriverEntry for that driver will not be called. The DriverEntry itself is not called until the driver is directly loaded using ZwLoadDriver , loaded by the system or with the service API as we were shown previously.
In any case, VideoPrt. This driver does a few things one of which is to implement common code so that video driver writers do not need to rewrite the same code.
SYS and your miniport. The VideoPrt. SYS will also create the device objects for the display and when you call the initialization routine it will thunk your driver object's entry points to point to VideoPrt. If you notice the first two arguments are the ones passed into your DriverEntry routine however it simply calls them "Context1" and "Context2" as if your video miniport driver is "special".
Don't be fooled, this driver entry is the same as what we worked with before and the first "Context1" is actually your driver object. Once you pass your driver object to VideoPortInitialize all your entry points to your driver are thunked to point to VideoPrt. SYS will call instead when it needs to. This means that you do not need to directly deal with IRPs in a video miniport.
SYS will instead handle them, break them down and then determine when you need to be informed about the data. This is essentially a mild, broken down version of the IRP in a different data structure. You simply need to return there is no special handling of this data structure as there is with IRPs. The documentation specifies that you should only use the " VideoPort " APIs in a miniport however since this is also just a regular system level driver you can still link against any kernel API you wish and I have done this before.
This is not the case with the display driver itself as we will see later. Since we do not have any hardware our miniport driver will be pretty thin and easy. The following code shows how the video miniport DriverEntry is constructed:. I mentioned before you simply pass the DriverObject directly through to the VideoPrt. SYS driver as shown above. You also fill in a data structure which contains entries into your driver which the VideoPrt.
SYS driver will call to perform various actions. Since I don't have any hardware I simply implement enough of a miniport to make the system happy. However in this implementation there is nothing we need done. If you don't have any then that removes everything but the necessary to keep the driver model happy.
The display driver links against WIN32K. These APIs are actually found in the kernel and in user mode. Prior to NT4 the display drivers were in user mode. In any case the same API set used by display drivers is also used by printer drivers.
Conforming to this API set also allows the display driver to be movable to user or kernel with minimal work. The display driver however is not loaded into system memory but instead session space. Session space is the kernel equivalent of process isolation. In user mode processes have their own virtual memory address space and in the kernel sessions have their own virtual memory address space.
System space is the kernel memory which is global to all sessions. Git stats commits. Failed to load latest commit information. View code. Overview This project is focused on providing Windows graphics driver samples.
Work on the driver was started in August Sample Graphics Driver Status The sample driver builds and installs on a raspberry pi 2 and supports a variety of operations. Roles Project Coordinator There is only one active project coordinator who oversees all aspects of the project. Microsoft Developer Individual Microsoft developers contribute source to the project following the submission process outlined below without further review.
Solo Developer Individuals not part of Microsoft contribute source to the project following the submission process outlined below but those submissions will be reviewed by the Project Coordinator before inclusion in the project. Support There is currently no active support for how to use the sample driver beyond what is documented in the Wiki. Contribution Process By Solo Developers Solo developers can contribute to the project in various ways including implementing unassigned tasks within an area of the driver, extending the existing testing coverage and adding additional documentation which helps describe the existing drivers functionality.
About This repository contains graphics driver samples used to demonstrate how to write graphics driver for the windows platform.
Resources Readme. Code of conduct. Releases No releases published. Packages 0 No packages published. For more information, see Keyboard and mouse HID client drivers.
To enhance the functionality of a legacy keyboard, the vendor can supply a keyboard filter driver. For more information, see the Kbfiltr sample. Keyboard and mouse HID client drivers. To enhance the functionality of a legacy mouse, the vendor can supply a mouse filter driver.
For more information, see the Moufiltr sample. For more information, see the Kbfiltr sample and Moufiltr sample. Microsoft provides support for web services scanners that is, scanners that are meant to be used over the web by means of the WSD scan driver wsdscan. However, a web services scanner device that supports WSD Distributed Scan Management must implement two web services protocols.
To enhance the functionality of a plotter, you can create a minidriver, which consists of one or more plotter characterization data PCD files. For more information, see Plotter Driver Minidrivers. For more information, see Pscript Minidrivers. To enhance the functionality of a non-PostScript printer, you can create a minidriver, which consists of one or more generic printer description GPD files.
For more information, see Microsoft Universal Printer Driver. Beginning with Windows 8, Microsoft provides a single in-box class driver that supports PostScript and non-PostScript printers as well as plotters. Used on its own, without modification, this printer driver provides basic printing support.
0コメント