Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 7: Understanding Device Drivers

Similar presentations


Presentation on theme: "Chapter 7: Understanding Device Drivers"— Presentation transcript:

1 Chapter 7: Understanding Device Drivers

2 Overview Device Driver Architecture Native Device Drivers
Device Driver Memory Management Device Driver Interrupt Handling Stream Device Drivers Display Driver Architecture Primer on GDI Programming Inside Display Drivers

3 Device Driver Architecture
Windows CE Architecture Device Power Management

4 Windows CE Architecture
Microsoft OEM ISV, OEM Applications Embedded Shell WIN32 APIs COREDLL, WINSOCK, OLE, COMMCTRL, COMMDLG, WININET, TAPI Windows CE Shell Services Remote Connectivity Kernel Library GWES Device Manager File Manager IrDA TCP/IP OAL Bootloader Drivers Device drivers File drivers Network drivers OEM Hardware

5 Device Power Management
Power status notification function Shutdown operations Save device state to preallocated storage Issue commands to the device that is shutting down Set a flag within the driver to note that it has been shut down Do not call Win32 API functions during a shutdown sequence

6 Native Device Drivers Overview of Native Device Drivers
Programming Model MDD/PDD Layers Battery and Notification LED Device Drivers PC Card Socket Device Drivers Keyboard Device Drivers

7 Overview of Native Device Drivers
Designed to drive built-in devices Provided by OEMs Supports custom interfaces Loaded by GWES Device Driver Interface (DDI) Interface between the OS and device drivers is called DDI DDI functions are defined for each device driver class DDI functions are defined by Microsoft and cannot be changed

8 Programming Model GWES DDI functions DDI functions Monolithic
device driver Device Driver MDD layer DDSI functions PDD layer Hardware

9 MDD/PDD Layers Model Device Driver (MDD) Layer Provided by Microsoft
Platform-independent code Communicates with GWES and Kernel Handles interrupts Platform-Dependent Driver (PDD) Layer Provided by OEMs Focus only on specific platform porting issue Communicates with the hardware

10 MDD/PDD Layers (continued)
MDD layer handles the DDI interface Interface between MDD and PDD is the Device Driver Service-Provider Interface (DDSI) DDSI interfaces may be redefined by OEMs with corresponding changes in the MDD layer When performance is an issue, the PDD layer can be bypassed - all processing can be done in MDD layer MDD code is provided as source code and as libraries

11 Battery and Notification LED Device Drivers
Battery device driver Provides information about power level of main and backup batteries Library statically linked with GWES Monolithic; uses only DDI functions Notification LED driver Handles all requests to turn the system notification LED on or off

12 PC Card Socket Device Drivers
Manages any PC Card sockets Abstracts hardware specifics so that a PC Card driver can run unchanged on any platform The MDD Layer exposes functions that can be used when developing a stream interface device driver for individual PC Cards MDD functions constitute the Card Services library PPD layer exposes low-level functions that constitute the Socket Services library

13 Keyboard Device Drivers
MDD Layer Maps scan code to virtual key code Generates character data associated with VK code Packages keyboard messages and puts them in the system message queue PDD Layer Retrieves scan code from hardware

14 Device Driver Memory Management
Memory Management Functions Windows CE Address Space Drivers and Pointer Data Driver Memory Access Memory Access in Drivers

15 Memory Management Functions
Device drivers are user-mode modules - it is necessary to map physical memory to virtual memory VirtualAlloc, VirtualFree: reserve, free virtual memory MEM_RESERVE VirtualCopy: maps a physical memory range to a virtual memory range PAGE_NOCACHE PAGE_PHYSICAL

16 Memory Management Functions (continued)
MapPtrToProcess GetCurrentProcess GetOwnerProcess UnMapPtr SetProcPermissions Volatile qualifier

17 Windows CE Address Space
4 GB Not Used Accessable via MmMapiIoSpace 3 GB 512M Non-Cached Above 2G-3G Mapped to physical memory 0xA 512M Cached Virtual address space 2 GB 0x Memory mapped files Briefly discuss process slots slot 0 is for the current running process 0-64k in each slot is for NULL pointers 1gb-2gb for memory mapped files System manipulates memory via pages, OEM dependent for the size Slot 32 Slot 32 64 MB Slot 1 32 MB Slot 0 64 KB NULL pointers

18 Drivers and Pointer data
OS manages pointers passed directly as parameters Driver must map All pointers contained in structs DeviceIOControl buffers often are structs that contain data, some of which may be pointers. Use MapPtrToProcess( SomePtr, GetOwnerProcess()) GetOwnerProcess() is used only in the context of a driver and cannot be used by Apps.

19 APP APP APP DM DM APP APP Driver Memory Access Slot 0
App is mapped into Slot 0 Mapped pointer App Calls DeviceIOControl DM mapped into Slot 0 DM DM Sets permissions to App space DM Calls xxx_IoControl Driver Calls MapPtrToProcess DM APP APP Original pointer Slot 0 Driver returns from xxx_IoControl DM Re-Sets permissions to App space App is mapped into Slot 0

20 Memory Access in Drivers
If driver creates a thread to do the work. MapPtrToProcess() will not work without some help You must use GetCurrentPermissions() and SetProcPermissions() to capture and reset the process permissions.

21 Device Driver Interrupt Handling
Interrupt Run Time Interrupt Service Thread Interrupt Management Functions Typical IST Start Typical IST Typical Stop

22 Interrupt Run Time Exception Handler Interrupt Support Handler Kernel
IST Driver 6 5 8 4 7 2 3 9 ISR OAL routines OAL I/O Routines 1 OEM Hardware

23 Interrupt Service Thread
Uses user-mode thread of device drivers for built-in devices Does the actual processing of the interrupt Creates an event object associated with the logical interrupt IST remains idle most of the time, awakened when the kernel signals the event object IST usually runs at above-normal priority

24 Interrupt Service Thread (continued)
Boost IST priority with CeSetThreadPriority function Create an event object with CreateEvent function Associate event object with SYSINTR_ by calling InterruptInitialize function Code a loop whose first operation is WaitForSingleObject The kernel signals the event object, which causes WaitForSingleObject to return Perform I/O in the device and process data Call InterruptDone to signal interrupt handling completion

25 Interrupt Management Functions
ISR HookInterrupt UnhookInterrupt IST InterruptInitialize InterruptDone InterruptDisable

26 Typical IST Start struct ISTData // Declare the Strucure to pass to the IST { HANDLE hThread; // IST Handle DWORD sysIntr; // Logical ID HANDLE hEvent; // handle to the event to wait for interrupt volatile BOOL abort; // flag to test to exit the IST }; ISTData g_KeypadISTData; // Create event to link to IST g_KeypadISTData.hEvent = CreateEvent(NULL, FALSE, FALSE, NULL); // Translate IRQ to an logical ID (x86 CEPC) g_KeypadISTData.sysIntr =Mapirq2Sysintr(5); // start the thread g_KeypadISTData.hThread = CreateThread(NULL,0,&KeypadIST, &g_KeypadISTData, 0, NULL);

27 Typical IST Start (Continued)
//Change the threads priority CeSetThreadPriority(g_KeypadISTData.hThread,0); //disconnect any previous event from logical ID InterruptDisable(g_KeypadISTData.sysIntr); // Connect Logical ID with Event InterruptInitialize(g_KeypadISTData.sysIntr, g_KeypadISTData. hEvent,NULL,0);

28 Typical IST DWORD KeypadIST(void *dat) {
ISTData* pData= (ISTData*)dat; // loop until told to stop While(!pData->abort) { // wait for the interrupt event... WaitForSingleObject(pData->hEvent, INFINITE) if(pData->abort) break; // Handle the interrupt... // Let OS know the interrupt processing is done InterruptDone(pData->sysIntr); } Return 0;

29 Typical IST Stop //disconnect event from logical ID
InterruptDisable(g_KeypadISTData.sysIntr); // set abort flag to true to let thread know // that it should exit g_KeypadISTData.abort =TRUE; // manually set the event to break thread // out of wait call SetEvent(g_KeypadISTData.hEvent); //wait for thread to exit WaitForSingleObject(g_KeypadISTData.hEvent,INFINITE); CloseHandle(g_KeypadISTData.hEvent); CloseHandle(g_KeypadISTData.hThread);

30 Stream Device Drivers Overview of Stream Interface Device Drivers
Device Manager Programming Model Loading Mechanism Entry Points Programming Considerations Audio Device Drivers File System Drivers

31 Overview of Stream Interface Device Drivers
Designed to support installable devices Common interface for all device drivers Expose device services through Win32 File I/O API functions Loaded, controlled, and unloaded by the Device Manager Can also be loaded directly by an application Often uses services from underlying native drivers Modem driver using the native serial driver

32 Device Manager The goal of a user-level process is to:
Load device drivers either at startup or on connection notifications Register special file names in the system Locate device drivers by obtaining PnP ID or by executing detection routines Track device drivers by reading and writing registry values Unload device drivers

33 Device Manager (continued)
Device file name All operations on device files are redirected to their respective drivers Device file name format is XXXY: where XXX is the prefix and consists of three letters in uppercase Y is the index and allows several devices to be handled by the same driver The names of the stream interface functions always begin with the device file name as a prefix

34 Windows CE-based platform
Programming Model User application Kernel File system code Device manager Stream interface driver Native device Windows CE-based platform Peripheral device

35 Loading Mechanism Load Drivers Listed in HKLM\Drivers\BuiltIn
Required values : Dll, Prefix Useful values : Index, Order Load PCMCIA drivers when detected HKLM\Drivers\PCMCIA\Plug and Play ID HKLM\Drivers\PCMCIA\Detect HKLM\Drivers\PCMCIA\Driver

36 Loading Mechanism (continued)
Application can load a driver dynamically by calling the RegisterDevice function For each loaded device driver, the Device Manager creates a key under HKLM\Drivers\Active Argument passed to the initialization function Hnd : the device handle Name : the device file name Key : the registry path to the device key under HKLM

37 Entry Points XXX_Init Called when Device Manager loads the driver
Initializes resources that are to be used: memory mapping, etc. XXX_Deinit Called when Device Manager unloads the driver Frees allocated resources, stops the IST

38 Entry Points (continued)
XXX_Open Invoked when applications call CreateFile(XXX, …) Returns a context handle that will be used in subsequent calls to XXX_Read, XXX_Write, XXX_Seek, XXX_IOControl, and XXX_Close XXX_Close Invoked when applications call CloseHandle function

39 Entry Points (continued)
XXX_Read Invoked when application calls ReadFile function XXX_Write Invoked when application calls WriteFile function XXX_Seek Allows moving the current I/O pointer

40 Entry Points (continued)
XXX_IOControl Allows performing custom operations that do not necessarily apply to files I/O control code identifies the operation I/O control code is device-specific XXX_PowerXXXX PowerUp and PowerDown notifications Should complete execution as quickly as possible

41 Programming Considerations
Single or multiple access to a device Multiple: XXX_Open always returns a unique context handle Single: XXX_Open returns one context handle on the first call and NULL for subsequent calls For unusual operations on files, use the XXX_IOControl function Read-only or write-only device

42 Audio Device Drivers Sample PCM Waveform Audio Driver WAV prefix
Relies mostly on XXX_IOControl You can use wavemdd.lib to build your own wavepdd.lib and link the two together to form the wavedev.dll Audio Compression Manager driver ACM prefix Codec, Converter, Filter You can refer to Windows NT ACM documentation

43 File System Drivers Designed for drivers that allow data to be read or written in blocks of fixed size Block device functionality Extend the size of the Object Store Store code and data Interoperability between operating systems Registry storage Database storage

44 File System Drivers (continued)
ATA flash memory Emulates the behavior of an ATA-style hard drive with a chip Linear memory flash Uses a software layer called flash translation layer (FTL) to emulate a disk drive Block device prefix is DSK All I/O are handled by the DSK_IOControl function with the same I/O control codes as the ones used by the FAT file system driver

45 Lab A: Developing a Stream Interface Device Driver

46 Display Driver Architecture
Windows CE Graphic Pipeline GPE Driver Pipeline Key Display Driver Source Files

47 Windows CE Graphic Pipeline
DRAWPROG.EXE GWES.EXE DDI.DLL COREDLL.DLL This diagram show shows the flow of control for Windows CE graphical output. Drawing Application (DRAWPROG.EXE) An application must be present to cause graphic output to appear on the display screen. It can be as simple as a "typical Hello World" program, or as complex as a 3D engineering application. Whichever it is, it calls into the 85 or so GDI (Graphics Device Interface) drawing calls that are supported on Windows CE. These are exposed through the main system library, COREDLL.DLL. System Library (COREDLL.DLL) The major set of C-callable API (Application Programming Interface) functions in Windows CE are exposed through a single dynamic link library (DLL), called COREDLL.DLL. In most cases, this library doesn't do the work itself. Instead, this library packages up the parameters for the function call, then triggers a local procedure call (LPC) to another Windows CE process. The specific process to be called depends on the specific function call. All drawing calls (and all windowing calls) get sent to GWES.EXE. Graphics, Windowing, and Events Subsystem (GWES.EXE) The GWES process is responsible for all graphical output, and all interactions with the user. Among the drivers that reside in the GWES address space are display drivers, printer drivers, keyboard drivers, mouse drivers, and touch screen drivers. The Display Driver (DDI.DLL) The default name for the display driver is DDI.DLL, which perhaps stands for "Display Device Interface". As with most DLLs, the outside world communicates through exported functions. DDI.DLL exports a single function: DrvEnableDriver, which returns to the caller a pointer to an array of twenty-seven (27) function pointers. When GWES has work to do with a display driver, it calls one of these 27 functions. Writing a device driver involves writing the code for these 27 functions. (Actually three are specific to printer drivers, which leaves 24 for display driver writers to deal with.) The Hardware The graphic pipeline ends at the hardware. The display driver communicates to the hardware using whatever mechanism that is required by the hardware. This typically involves a combination of memory-mapped video buffers and I/O registers. HARDWARE

48 GPE Driver Architecture
GWES.EXE DrvEnableDriver DDI.DLL DrvEnableDriver GPE.LIB The Windows CE Platform Builder provides a set of helper libraries that simplifies the creation of display drivers when the target hardware uses one of several standard video buffer formats. The Display Driver (DDI.DLL) A display driver built using GPE services does not appear any different to the outside world from a monolithic display driver. In other words, the various components that are discussed here get linked together to form a single dynamic link library. The Graphics Primitive Engine (GPE.LIB) The GPE library is a DIB (Device Independent Bitmap) driver. It can perform all the basic set of drawing for video adapters that have the following characteristics: Video buffer are accessible in system address space Video buffer is non-banked Video buffer is non-planar (I.e. has one plane) Video buffers have one of the following bits-per-pixel: 5, 6, 8, 16, 24, 32. As of this writing, the source code for GPE.LIB does not ship with the regular Platform Builder. However, third-parties can gain access to the source code for GPE for a nominal fee from Microsoft. From the Microsoft web site, you can order a product called "Microsoft Windows CE Platform Builder 3.0 Windows CE 3.0 Source Code." Hardware Acceleration GPE allows for device-specific accelerations for the drawing of either raster (bitmap) or vector (lines and filled areas) graphic primitives. The display driver writer has quite a bit of freedom to tune the performance of a given display solution to take advantage of whatever hardware drawing support might be available. The Emulation Library (EMUL.LIB) Raster drawing functions are commonly referred to as "BitBlt" (an acronym for Bit-Boundary Block Transfer), or sometimes just "BLT" (for Bacon, Lettuce, and Tomato). GPE relies on the emulation library for basic raster drawing support. The source files for EMUL.LIB can be found in the Platform Builder directory tree at: \wince300\public\common\oak\drivers\display\emul. Hardware Acceleration EMUL.LIB HARDWARE – DIB-Compatible Video Buffer

49 Key Display Driver Source Files
In ..\public\common\oak\inc: WINDDI.H – Driver interface definitions EMUL.H – Drawing helpers for raster drawing GPE.H – Basic set of data structures & defines GPE Source Files In ..\private\winceos\ coreos\gwe\mgdi\gpe Here are some important files that will help you work with display drivers – both monolithic and GPE-based display drivers. WINDDI.H This file contains all the core definitions for Windows CE graphic drivers (both display and printer device drivers). This file is of primary interest if you are creating a monolithic driver, since it describes all of the entry points, data types, and symbolic constants that you need to receive and process drawing requests from GWES. This file also contains important definitions for display driver writers who are using GPE, since many GWES data structures percolate through the GPE layer into the GPE objects. EMUL.H This include file describes the set of raster drawing helpers inside the raster emulation library. Creating fast raster output is very important for display driver writers, since most of the pixels on a display screen – upwards of 95% - are drawn using raster drawing calls. (On Windows CE, where all text gets drawn using raster drawing calls, it's common for 100% of all drawing calls to be raster drawing calls.) The emulation library provides a reasonably good solution for drawing raster data in software. However, whenever your display device has the ability to perform any of the drawing using accelerated hardware, you should consider using the hardware in place of the raster emulation library. GPE.H This file contains the basic set of data structures and symbol definitions that you'll need to use the GPE library. GPE Sources Files Microsoft does not ship the GPE source files with Platform Builder. However, if you are a registered user of the Platform Builder, you can order the source files by connecting to the web site. For more details, turn your web browser to:

50 Primer on GDI Programming
Families of Drawing Functions Drawing Coordinates GDI Drawing Functions Drawing Text Drawing Raster Data Drawing Vector Objects Window Drawing: WM_PAINT MINGDI Display Drawing

51 Abc  Families of Drawing Functions Text Raster Vector
Abcdefghijklmnopqrstuvwxyz Abcdefghijklmn  Abc Text Raster Vector  Abcdefghijklmnopqr Abc The three basic types of graphical output are text, raster, and vector. Text To a graphic driver, text consists of tiny sequences of single lines of text (word wrapping is the responsibility of application software, not of graphic drivers). Drivers are responsible for font mapping, the selection of a device-specific physical font to satisfy an application “logical font” request. Drivers are also responsible for choosing the correct color for foreground and background text pixels. Raster Graphic drivers must copy raster graphic data (a.k.a. “bitmaps”), which are always rectangular. Windows supports two types of bitmaps: device-dependent and device-independent (DIB). Vector GDI vector graphic objects have two components: borders and interiors. Borders are drawn with pens; interiors are filled with brushes. For simple devices, a driver converts vector requests to raster data. For smart devices, GDI can make high-level vector requests (ie. “draw a rectangle” or “draw a bezier”). In between, GDI has “software simulations” to convert complex vector figures into simpler polyline/scan-line drawing requests.

52 Drawing Coordinates (0,0) +X +Y
The default GDI drawing coordinates are device coordinates. Origin The origin (0,0) is in the upper-left corner of a device. Display When drawing in a window, this corresponds to “client area coordinates.” To get the size of a window’s client area, call GetClientRect: RECT rClient; // Client area size is (rClient.right, rClient.bottom) GetClientRect(hwnd, &rClient);

53 GDI Drawing Functions Text Drawing - ExtTextOut, DrawText
Vector Drawing - Polyline, Rectangle, Ellipse, Polygon, RoundRect Raster Drawing - SetPixel, PatBlt, BitBlt, MaskBlt Here is a sample of available GDI drawing functions by category.

54 hello Drawing Text (x,y) Draws a line of text.
ExtTextOut (hdc, x, y, Options, pRect, lpstr, cch, int * lpDX); HDC hdc - DC handle. int x - X coordinate int y - Y coordinate UINT Options - NULL Ok. RECT * pRect - NULL Ok. LPTSTR psz - string UINT cch - string length. int * lpDX - NULL - Ok. ExtTextOut(hdc,x,y, NULL, NULL, "hello", 5, NULL); TextOut provides the simplest way to output a single line of text. Characteristics. ExtTextOut has the following characteristics: Draws using the font currently selected in the DC. Requires a string length because it does not stop when it encounters a NULL. Nor does it wrap to a new line when it encounters a ‘\n’. This is because it makes no assumptions about the character set being used. Coordinates don’t refer to character cells, but to logical coordinates. On Windows CE 2.0, the only supported coordinates are pixels. Another Text Drawing Functions. The only other text drawing function supported by Windows CE is: DrawText—Provides some formatting features, such as word-wrap. (x,y) hello

55 Drawing Raster Data Pixels SetPixel GetPixel Fill An Area PatBlt
Copy Device-Dependent Bitmaps BitBlt StretchBlt Draw Device Independent Bitmaps StretchDIBits Here is the basic set of GDI raster drawing functions. Pixels. Illuminate a pixel by calling SetPixel, which is defined: COLORREF SetPixel (HDC hdc, int x, int y, COLORREF cr); hdc is a device context. x and y are the coordinates of the pixel to illuminate. cr identifies a color. Identify a color using one of three different macros: RGB, PALETTEINDEX, or PALETTERGB. SetPixel returns the previous color of the pixel (only for display devices). Examples. SetPixel (hdc, x, y, RGB(255, 0, 0)); // Draw a red pixel. SetPixel (hdc, x, y, PALETTEINDEX(0)); // Use palette index 0 SetPixel (hdc, x, y, PALETTERGB(255, 0, 0)); // Closest red in palette. Device-Dependent Bitmaps A device-dependent bitmap is one created by a display driver to support caching of complex graphics for fast redrawing. For example, the Window Manager creates snapshots to speed up the system menus. Monochrome DDBs can be copied to the printer. Device Independent Bitmaps (DIB) A device-independent bitmap stores raster data in one of several standard formats (1, 4, 8, 16, 24, and 32 bits/pixel).

56 Drawing Vector Objects
Lines Polyline Filled Figures Polygon Ellipse Rectangle Here is a basic set of GDI line drawing functions.

57 Window Drawing: WM_PAINT
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg,...){ switch (msg) { case WM_PAINT: { HDC hdc; PAINTSTRUCT ps; hdc = BeginPaint(hwnd,&ps); // draw, draw, draw... TextOut (hdc,x,y,lp,cb); EndPaint (hwnd, &ps); } This code fragment shows how the WM_PAINT message must be handled. Key Point! BeginPaint and EndPaint must be called when handling the WM_PAINT message. BeginPaint Borrows a DC from the Window Manager. The DC is set up to draw in a window. Clipping is set for a window’s invalid region. EndPaint Returns the a DC to the Window Manager. This call also notifies the Window Manager that the invalid portion of the window is valid. PAINTSTRUCT Structure. Defined in Windows.H as: typedef struct tagPAINTSTRUCT { HDC hdc; // Handle to use when drawing. BOOL fErase; RECT rcPaint; // Rectangle around invalid region. BOOL fRestore; BOOL fIncUpdate; BYTE rgbReserved[16]; } PAINTSTRUCT; Requesting a WM_PAINT Message To generate a WM_PAINT message, declare a window invalid by calling InvalidateRect or InvalidateRgn. Forcing a WM_PAINT Message Once part of a window has been declared invalid (see previous paragraph), an immediate WM_PAINT can be generated by calling UpdateWindow. Normally, this is done to force a window to a known state for special purposes like taking a screen shot.

58 MINGDI Display Drawing
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { HDC hdc = CreateDC(L"display", 0, 0, 0); ExtTextOut(hdc, 10, 10, NULL, NULL, L"Hello World", 11, 0); DeleteDC(hdc); return 0; } Here's another angle on drawing to a display driver. MINGDI Display Drawing One of the most interesting aspects of Windows CE is that each Windows CE-powered device will have different hardware. Some will be headless, built from a reference configuration like MINKERN or MINCOMM. Others will have full windowing support like what you find on desktop versions of Windows – that is certainly what MAXALL provides. In between, there is MINGDI. This version of Windows CE has a display driver, but has no window manager. One of the key roles of the window manager is to help different programs share the display screen. However, the window manager comes at a cost – the overall Windows CE image is larger. For embedded system that don't need the help from the window manager, but want to display graphical information, there is MINGDI. This code fragment shows how CreateDC can be used to obtain access to a device context handle when the window manager is not present. The DC returned by this call is able to draw anywhere on the display screen. It can even be used to draw when the window manager is present, and might be useful if you wish to take a snapshot of the display screen or if you wish to create a screen saver. These are examples of the uses this CreateDC call provides on desktop Windows (yes, it works on desktop Windows). One item worth noting: Make sure that all calls to CreateDC have a matching call to DeleteDC. Failure to do so will create a memory leak, which will eventually cause pixels to spill out of your Windows CE device onto the floor. What a mess it will make!

59 Inside Display Drivers
Display Device Drivers Connecting to a Driver Queries, Attributes and Drawing Disconnecting DDI Vector Functions DDI Raster Functions DDI Text Functions

60 Display Device Drivers
Subset of the Windows NT DDI, with the following differences: Display drivers always present the same functionality Display drivers cannot reject an operation as too complex Display drivers are native drivers because they have a custom interface with GWES Loaded by GWES Note to Renu – I am putting this slide here. This slide comes from page 46 of Module 7.

61 Display Device Drivers (continued)
Display drivers are usually layered Graphic Primitive Engine (GPE) Acts as the MDD layer Optional Handles all the default drawing Requires the display hardware to use a flat-frame buffer PDD layer IHVs provide hardware-specific code Note to Renu – I am putting this slide here. This slide comes from page 47 of Module 7.

62 Display Device Drivers (continued)
Secondary display driver Loaded by the Device Manager when calling CreateDC You cannot use any window manager functions You can easily display the contents of the primary display Accelerating BitBlt and line drawing Default GPE routines Emulated library Hardware acceleration Note to Renu – I am putting this slide here. This slide comes from page 48 of Module 7.

63 Connecting to a Driver CreateDC Only way to access graphic devices
Application CreateDC Only way to access graphic devices Calls driver’s initialization functions CreateDC COREDLL.DLL + GWES.EXE DrvEnableDriver, DrvEnablePDEV, DrvCompletePDEV GDI’s connection to a driver starts with the call to the driver’s DrvEnableDriver entry point. CreateDC This API function provides the only way that GDI allows anyone to create a connection to a graphic device. In fact, the DC returned from calls like BeginPaint (and its cousin, GetDC) have been created by the window manager through calling CreateDC. Driver Initialization This diagram shows the basic set of driver initialization functions. DrvEnableDriver – This function gets called just once – when the driver is first loaded. This role of this function is to pass an array of function pointers to GWES.EXE. It also must copy the GWES support functions so that the driver can get the basic set of support services provided by GWES to graphic drivers. DrvEnablePDEV – This function gets called every time a DC is created. There is, therefore, a one-to-one mapping between API calls to CreateDC and GWES calls to DrvEnablePDEV. DrvCompletePDEV – This call completes the DC creation process. Driver Hardware

64 Queries, Attributes & Drawing
GetDeviceCaps Queries key values SelectObject Object selection function No call to driver Polyline Request to draw Calls driver to do “real- work” Application GetDeviceCaps(…) Polyline(…) SelectObject (…) COREDLL.DLL + GWES.EXE DrvStrokePath From a graphic driver's perspective, there are three interesting things that a graphics application does: (1) Queries, (2) Setting attributes, and (3) drawing. Queries While not the glamorous side of graphic output, the most important thing that an application does is that it makes queries. For example, it has to find out the size of the drawing area before it draws. It has to find out what fonts are available before it draws any text. It must find out about color support before it attempts to draw a photograph. Much of the information comes from the graphic driver. GetDeviceCaps is an important query function. It gives an application the ability to peek into the GDIINFO structure, which is a structure returned by the graphics driver to GDI at DC initialization time – to be more precise, it is returned by the driver when the DrvEnablePDEV function is called. Setting Attributes Applications set attributes. This involves deciding, for example, what font to use when drawing text, and what color to draw the text with. There are a wide range of attribute-setting functions available to applications. None of these result in calls to the driver; instead, GWES sends the key attribute values to the driver during the drawing calls. Drawing Each API-level drawing function results in a call to a driver-level function. Mapping the API-to-DDI function calls can be very helpful in making sure you understand exactly what each driver-level function must do. In this example, calls to the Polyline function become calls to DrvStrokePath within the driver. Driver Hardware

65 Disconnecting Application disconnects from GDI
GDI disconnects from driver. Application DeleteDC COREDLL.DLL + GWES.EXE DrvDisablePDEV Driver Here is what’s involved in disconnecting from a device. DeleteDC This API-level function is the “close shop” pair to CreateDC. DrvDisablePDEV This DDI-level function is the “close shop” pair to DrvEnablePDEV. Hardware

66 DDI Vector Functions Application MoveToEx Polyline Ellipse PolyBezier
Polygon Rectangle COREDLL.DLL + GWES.EXE DrvStrokePath DrvFillPath This figure summarizes the relationship between API and DDI functions. DrvStrokeAndFillPath DrvBitBlt DrvPaint DRIVER

67 DDI Raster Functions App DRIVER SetPixel BitBlt MaskBlt Rectangle
ExtTextOut SetDlBitsToDevice GetDIBits SetDIBits COREDLL.DLL + GWES.EXE This figure summarizes the relationship between API drawing calls and DDI entry points. DrvBitBlt DrvCopyBits DRIVER

68 DDI Text Functions API ExtTextOut DrawText DDI DrvBitBlt
Here is the mapping of API to DDI functions for text.

69 Lab B: Exploring Video Display Drivers

70 Review Device Driver Architecture Native Device Drivers
Device Driver Memory Management Device Driver Interrupt Handling Stream Device Drivers Display Driver Architecture Primer on GDI Programming Inside Display Drivers


Download ppt "Chapter 7: Understanding Device Drivers"

Similar presentations


Ads by Google