Linghu Chong Essence Search Engine Search Range Range Embedded Edition
Microsoft Windows CE Display Devices Drivers and Hardware Jason Black and Jon ChristiansensePtember 1997 Introduction to the graphic display structure in the Microsoft? Windows? CE operating system version 2.0 is fundamentally changed. In version 1.0, the graphics device interface (GDI) is directly connected to the hardware of the display device. In version 2.0, GDI is connected to one or more display driver, which is connected to the hardware of the display device in turn. This display structure enables Windows CEs to use various display devices without having to have a port program programmed according to hardware each device. New Windows CE GDI is just a small step toward multifunction. First, we will consider several factors that the Windows CE display device driver is successful. Here we first discuss the interface capabilities that the device driver should implement, and the graphics basic engine class that can be used to simplify the display device driver development task. At the same time, it also tells the support of the equipment driver to GDI. Second, we will give a detailed list that lists the display buffered formats corresponding to each pixel gray scale supported by the Windows CE and describes the hardware of the display device. Since the display device driver is a link between the GDI and the display device, the hardware supports the display driver, which is also valid for GDI. WINDOWS CE Display Device Driver Like other parts of Windows CE, a subset of the Driver Interface (DDI) Microsoft Windows NT? DDI is displayed. If you are not familiar with Windows NT DDI, you can first read the relevant chapters of the Windows NT Device Driver Kit (DDK) to read the Windows NT Device DRIVER KIT (DDK). Windows CE only uses basic graphics engine functions and driver functions from Windows NT DDI. Different from Windows CE and Windows NT, the following differences in the Windows CE display device driver: Windows CE display device drivers always provide a set of identical features, GDI does not need to query any information about driver capabilities. The Windows CE display device driver cannot refuse a very complex operation, which in turn calls the GDI to decompose complex operation into a simple step. Because Windows CE All display device drivers support the same function, the GDI first step can be decomposed into a simple operation before calling the display device driver. The Windows CE display device driver is compiled as a dynamic connection library (.dll file) instead of compiling the library file (.lib file). Windows CE All Display Device Drivers must implement a set of DDI functions, GDI calls this group function to initialize the display device driver and output the graphic to the display device. In addition to the DDI function, there is a group of Microsoft Visual C . Using the GPE class and its method to implement the acceleration of the hardware based on the S3TRIO64 display device, it is an example of implementing the speed of display device driver. If you display the hardware of the device uses a different chipset, you can change the implementation of the GPE method to accommodate your hardware features. Note Whether to use the GPE class is free. When writing a display device driver, you can not use them, but the cost is your DDI functionality will be more complicated. Note Microsoft's GPE class requires that the hardware you use must have a continuous frame buffer. If you display the hardware of the device is not this (for example, if it uses a fixed size mobile window to access the entire display memory), then it cannot use the GPE class.
To get more information, see the "Windows CE Display Device Hardware Recommended" section, especially the "driver" subtoping of the "dirty area". The drive of the Windows CE display device is different from the general device driver in many ways. The most important difference is that they have no obvious input / output flow interface, so they cannot be managed by device manager, and they cannot call RegisterDevice. As a result, there is no special device file or other file system pathway corresponds to the display device driver. When the application needs to use the display device driver, use the display device's .dll file name to call CREATEDC, the display device driver is loaded. At this time, Windows CE is loaded into the display device driver and performs corresponding initialization to facilitate returning the context of the device to the invoked application. Of course, the default display device driver is automatically loaded. The DDI function of the display device and the print device driver is listed in the following tables. The display device driver should implement all display device DDI functions listed here; the printing device driver should implement all listed print DDI functions. However, only DrvenableDriver must be shown in the DLL of the display device driver. Therefore, only DRVENABLEDRIVER must follow this name; and other functions can be called according to your needs because they are represented by the function pointer returned by DrVENABLEDRIVER. Regardless of who they are called, they must follow the prototypes defined in Winddi.h. Table 1 DDI function function DRVANYBLT DRVBitblt in a plurality of flexible or transparent manner to transfer DRVCONTRASTCONTROL to send DRVCONTRASTCONTROL Use software to send DRVCOPYBITS to the printing area to the printing device for the hardware to display the hardware for the display device. Drivers DRVCREATEVICEBITMAP Create and manage bitmap DRVDeleteDeviceBitmap Delete Device Bits DRVDISABLEDRIVER Alert Driver GDI no longer requires it and is ready to uninstall it DrvdisablePDEV reminder driver GDI no longer requires a specific print or display device. The Drvdisablesurface reminder driver GDI no longer requires a specific drawing plane DRVENABLEDRiver represents the initialization entry point by the driver, and returns other DDI function pointer to GDIDRVENABLEPDEV to return a PDEV (logical representation of the physical display device) to gdidrvenablesurface to create a drawing plane and will It is sent to a PDEV related DRVENDDOC to send the control information required for printing to a document DrvFillPath to fill a path DrvgetMasks Get the display device Current mode Color mask DrvgetModes Lists the display mode supported by the display device Dr. DRVMOVEPOINTER Make sure not being interfered with GDI Mobile pointer DrvpainT draws a specific area with a brush. DrvpowerHandler is called to handle energy and low energy, DRVQueryFont Get Font Metric Unit Information DrvRealizebrush Creates a Brush Drgu DRREALIZECOLOR to map a RGB color to the closest device to the closest device to set the display device. DRVSETPALETTE Palette DRVSETPOINTERSHAPE Sets to a new shape of the pointer and update the display drvStartDoc sends the control information required to start the print to a document DrvStartPage to start the print desired control information Send to a new page DRVSTROKEPATH Draw a path DRVTRANSPARENTBLT to transparent Methods Block Transfer DrvunRealizeColor Use a color to a RGB value with the GPE class sample display device driver using the GPE class. Although the GPE class is optional, it is easy to write to the display device driver using it. If you use the GPE class, then you only need to provide new code you need to make your display device hardware functionality and implementation.
The GPE class requires the introduction of your display device to use a continuous frame buffer. That is to say, the display device memory must be located within a neighboring memory. Modifying a GPE class to use a non-adjacent frame buffer requires you to pay great efforts. To create a GPE-based display device driver, follow these steps: Create a directory for your project. Copy files into your project directory from a sample driver directory, such as the S3trio64 directory. In these files, the specific device name is globally replaced, for example, replaced "S3TRIO64" with your device name. Change config.cpp to facilitate setting your display device to a linear frame buffer mode. Disable all specific hardware acceleration. Compile and test this driver that does not accelerate. GPE will generate output using software simulation. Add your own hardware acceleration code. Supported Display Device Services Windows CE GDI provides some services to support display devices, in a pre-defined structure, with functions on which they are on it, and some independent C functions. The pre-defined structure provides support for brush, clipping area, palette, stroke, filling method, and conversion. Independent Mode C functions provide support for device bitmaps and planes. Table 2 GDI Structure and Function Structure and Function Devo Brushobj Demand Brushobj_PVallocrbrush, BRUSHOBJ_PVALLOCRBRUSH, BRUSHOBJ_PVALLOCRBRUSH, Re-acquires Function of Memory Pointer to Directive CLIPOBJ_BENUM Enumered in Scrapbook The scrap rectangle of the area clipobj_cenumstart to the rectangular setting parameters of the rectangular setting parameters in the clip section are used to create the function of the GDI to create a handle for the device bitmap to make GDI creation a function of the device plane managed by the display device driver. ENGDELESURFACE is used to notify the GDI display device driver no longer need the function of the device. Its component line segment function Pathobj_vgetbounds Returns the rectangular function of the rectangle of the painting trajectory to resemble the structure XLateObj_cgetpalette to transfer color from one palette to another color to re-colors the color function display device. The Format of the Buffer Windows CE GDI supports a display device with a variety of color grayscale and color modes, from which only one represented color to the color of the palette until the true 32-bit RGB. Each format also supports several different pixel arrangements, depending on whether access to the display memory supports byte mode, double word mode, or four-byte DWORD mode. All display buffers format assume that the order of the pixels on the display device is from left to right, and from top to bottom. That is, the pixels (0, 0) are located on the upper left corner of the display device, the pixel (Width-1, HEIGHT-1) is located in the lower right corner of the display device. Each pixel uses a format one-bit-per-pixel format that each pixel uses a format for a simple black and white display device. 0 means black, 1 means white. By multiple pixels constitutive bytes, such as pixels (0, 0) are located on the highest bit of the first byte of the memory. The memory in this format can be arranged in the following: each pixel is used in the format of the two representation, although any 4 items of palette can be used, but each pixel is used in the format of the two-stage grayscale display devices. A typical usage. The content represented by each grayscale can be determined according to the following table: Bit 1 bit 0 Gray Level0 0 Black 0 1 Dark gray 1 0 Light gray 1 1 White This format can be arranged in the following manner: each pixel uses four The format of the bit represented by each pixel is a palette format that is commonly used.
The frame buffer itself can be implemented to block two pixels into one byte, or each byte represents two ways. The memory in this format can be arranged in the following: If you choose to use each byte to represent a pixel, the driver should indicate the display mode to use 8-bit 16-color palette per pixel. The corresponding bit in each byte should be a low-order semi-byte, while the high-order semi-byte should always be 0. Each pixel uses an eight-bit format Each pixel uses an eight-bit format that can be used to map 8 bits to a 24-bit color with a palette that changes the palette by a software. Because of the reason for execution, compatibility, and image quality, Microsoft recommends using the default Windows CE palette. Each pixel uses 15-bit or 16-bit format each pixel to represent a format of a mask, and is not toned. For each pixel, the format is represented by a 15-bit or 16-bit, the pixel is stored with two bytes; the format of each pixel is wasted to waste the highest bit of each word. Microsoft recommends using the following mask to extract red, green, blue value: color fifteen-bit (5-5-5 rgb) sixteen-bit (5-6-5 rgb) red 0x7c00 0xF800 green 0x3e00 0x07E0 blue 0x001F 0x001F is as each The pixel is displayed by a mask represented by 15 bits, and the lower 15 bits of each word contains data of the pixel. The unused bit should be 0. The memory of this format can be arranged in the following: each pixel is used 24-bit format, each pixel, 24-bit format, is a true color format, where each pixel is red, green, and blue. Bit is stored. This format has some advantages and disadvantages. The advantage is that the image quality of this approach is very good because each pixel is just 3 bytes, which can be placed together without waste memory. A disadvantage is that half of this method has a loss of performing efficiency when accessing and decoding. The memory of this format can be arranged in the following: each pixel uses 32-bit formats per pixel to 32-bit formats in another true color format. This format does not cause the pixel to generate a situation across the DWORD boundary, but the efficiency is low in memory usage. There are two ways to arrange color channels in this format. One way is to place blue in the least important byte of each pixel, and another way to put red in the least important byte. These options correspond to the PAL_BGR and PAL_RGB modes. You can use the following mask to extract red, green, blue, and alpha channels from each pixel: Color PAL_RGB Mask Pal_Bgr MaskRed 0x000000FF 0x00FF0000Green 0x0000FF00 0x0000FF00BLUE 0x00FF0000 0x000000FF This format can be arranged in the following manner: Windows CE Display device hardware It is recommended to have a display device for a Windows CE operating system, Microsoft has some recommended standards. These recommendations are beneficial to improve the development of performing efficiency and make it easy to display device drivers. Even if your hardware is inconsistent with these recommended standards, you can still write a full-functional display device driver. Or want to change its hardware design in your product design cycle, it takes an additional effort to implement the driver or reduce its performance. Memory layout Microsoft strongly recommends your display device hardware To use a linear frame buffer, you should be able to read and write buffers. Your all display memory should be continuous, better, should be a linear access window and can overwrite the entire frame buffer. For hardware that does not meet this recommended standard, if you choose to use GPE, you will need to make substantive modifications to the GPE class. See the "Using GPE CLASSES" section of this article, you can get more information. Your display device hardware should also use a combination of supported pixel format, compression, and arrangement. About this content more information, you can read this article section of the "Display Buffer Formats" section.
The frame buffer displaying the device hardware should have the following characteristics: the top-down format, pixels (0, 0) in the upper left corner, pixels (Width-1, HEIGHT-1) in the lower right corner. The step buffer, that is, the number of bytes that the display device is displayed in memory should be an integer multiple of the four-byte, even if this will mean that some useless use at the end of each scan line. byte. The CPU can access the entire frame buffer without "row" selection. The frame buffer should not use the plane, and the frame buffer in the plane is used for each color channel or intensity component. Dirty rectangular driver If you plan to use the GPE class to implement a display device driver, your display device hardware does not support GPE classes (for example, if the frame buffer is not linear), then you may consider writing a "dirty rectangle) "driver. In this mode, the GPE class maintains a bitmap (DIB) independent of the device in memory to represent the frame buffer. Once the DIB in memory is modified, GPE will notify the dirty rectangular driver. The dirty rectangular driver responds, copies any changes required to the display device in response to the partial part of the DIB or "dirty" to the display device. The dirty rectangular driver spends great costs on memory usage and execution speed. These should only be implemented as a last means of supporting hardware that cannot be compatible with GPE. Acceleration To reduce the cost, Microsoft recommends that you can use the display device for the following accelerated operations: solid color fill. In particular, its PBO-> ISOLIDCOLOR member is not a BLT operation of 0xFffffffFfffff. SRCCopy BLT operation. If your platform uses the cursor, then the display of the cursor. Draw a solid line with the accuracy within the single pixel. Shield Srccopy BLT operation. Other graphics operations that are often performed in your Windows CE device. Summarizing in the Windows CE version 2.0, the display device driver plays a key role in the visual display structure. The display device driver and display device hardware created in this article will make a Windows CE-based device can sufficiently utilize the enhanced graphic display capabilities of the new GDI. About this content About Microsoft Windows CE Embedded Toolkit For Visual C 5.0, you can see the Microsoft Windows CE Web site. This tool will be provided to MSDN Library ordinary subscribers. At the same time, remember to read the following articles, are included in MSDN Library: "Embedded Development with Microsoft Windows CE 2.0," written by Franklin Fite Jr. and Randy Kath. "Introducing the Windows CE Embedded Toolkit for Visual C 5.0," written by David Pellerin. "Microsoft Windows CE Graphics Features," is written by Jon Christiansen. "Microsoft Windows CE Memory Use," is written by John Murray. "The Microsoft Windows CE Communications Model," is written by Guy Smith. "Real-Time Systems With Microsoft Windows CE," is written by John Murray. "The win32 programing model: a primer for Embedded Software Developers," Writing by David Pellerin.
The information contained herein represents Microsoft's views on this issue in this article. Since Microsoft must respond promptly, please do not think it is the promise of some of the responsibility assumed by Microsoft, which will not ensure the accuracy of any information represented later. This article is only to provide some information. This white paper is for the purpose of providing some intelligence. In this article, Microsoft does not do any guarantee, representation or dignity. (Reprinted from MSDN) - ※ Source: · BBS Shuimu Tsinghua Station Smth.org · [From: 166.111.61.53] [Back to top] [Refresh] [Top Topics] [Ordinary mode] [Edition inquiry] Come this version Other layouts often go: [Circuit] [dsptech] [mcutech] [NetResources] [Commun] [linuxdev] [love]
[My Treasure Chest] [Back Home] [Home Catalog] [Root Directory] [Lunhu Chong Essence Search] [Back to Top] [Refresh] [Back]
