Drivers Guru

If you’re using an older machine, you might have come across the label AC ’97 while going through the Sound and Audio Device Properties or the items listed in Device Manager. In case you’re wondering what it means, the term AC ’97 stands for Audio Codec ’97, a codec standard made by Intel Architecture Labs back in 1997.

In terms of software, audio codecs are programs that compress and decompress digital information found on audio files, e.g. turn data on an MP3 file into music. The term codec actually stands for Compress/Decompress. However, Intel uses the term audio codec somewhat differently for AC ‘97: instead of handling purely digital information, the term refers to a device that encodes analog audio into digital audio, and vice versa. In other words, an AD/DA converter.

Capabilities

AC ’97 is a specification for high-quality, 16- or 20- bit audio architecture for many desktop personal computers. It’s used mainly for motherboards, modems, sound cards, and chassis front panel audio solutions. It’s capable of supporting surround sound for PCs, with 96 kHz in 20-bit stereo resolution and 48 kHz in 20-bit stereo for multi-channel recording and playback.

You can get integrated audio on your PC by having the AC’97 Codec on the motherboard, or having either a Communications and Networking Riser (CNR) card or an audio/modem riser (AMR) card installed.

The latest version, AC 2.3, enables Plug and Play for its users and allows audio codecs to provide information about its analog interface, similar to Intel High Definition Audio.

Specifications

The kinds of AC ’97 devices include:

• Audio Codec – referred to as AC ’97 or just AC; forms the analog component of the AC architecture.
• Modem Codec – referred to as MC; also part of the analog component.
• Combined Audio/Modem Codec – referred to as AMC ’97 or just AMC.
• Digital controller – referred to as DC ’97; built into the I/O Controller Hub (ICH) of the chipset.

AC ’97 codec chips have an AC97 interface on one side and analog audio interface on the other. They are small square chips with 48 pins, and can be Digital/Analog and Analog/Digital or only Digital/Analog.

To see the full specifications of AC ’97, you can download the manual from Intel’s webpage.

Note that in 2004, AC’97 was replaced by Intel High Definition Audio (HD Audio) as the standard for next generation integrated audio. HD Audio can support 192-kHz 32-bit quality for two channels and 96-kHz 32-bit for up to eight channels

Upgrading AC ’97 drivers

If you have an AC ’97 chipset in your computer, you can choose to upgrade its driver to the latest version by downloading the updates from the manufacturer’s website. For example, if you have Realtek AC ’97, go to the Realtek webpage download section. Run the installer and it will detect the AC ’97 devices for you. Simply follow the instructions, then restart your computer to complete the installation.

LED technology

OKI Electric developed its LED printhead technology for electro-photographic printing for reliable printing in various applications.

Laser systems rely on elaborate combinations of rotating mirrors and lenses that must remain in alignment through use. The laser scans from one end of a line to another, then zig-zags down to the next line.

LED technology uses a Light Emitting Diode printhead as a light source within the imaging device. Unlike laser systems, the LED printhead is solid-state and has no moving parts. The LED bar pulse-flashes across the entire page width and creates the image on the print drum as it moves down.

OKI also has a straight-line paper path that’s less susceptible to jams when feeding heavy stock, envelopes or labels.

LED technology is the future. We’re so sure of this that we guarantee the printhead of every OKI page printer for five full years  by far the longest warranty in the industry!

Laser technology

Asus ready for launching N-Series that will be available for doing your daily multimedia tasks, Asus N61 and N71. Both of notebook comes with ASUS SonicMaster amplification system that will bring new experience in audio reproduction. For listening every sound quality detail(rhytm and beat), this new laptop also completed with utilizing a paper-foam cone design. This new laptop also equipped with Altec Lansing Speakers and SRS Premium Sound that will offer high definition audio when you’re travelling.

ASUS N61 Specification:
- Intel Core 2 Duo or Core 2 Quad Processor
- 1GB 0f DDR3 NVIDIA GeForce GT 240M or GT 220M
- upto 4GB of DDR3 RAM memory
- 500Gb of hard drive
- 16-inch HD LED Panel that support for 1366 by 768 pixel resolution
- Blu-ray DVD Combo
- Microsoft Windows 7

ASUS N71 Specification:
- Intel Core 2 Duo or Core 2 Quad processor
- 1GB of DDR3 NVIDIA GeForce GT 240M or GT 220M
- up to 4GB of DDR3 RAM memory
- up to 500GB hard drive
- Blu-ray DVD Combo
- Microsoft Windows 7

Logitech unveiled the Logitech?

Notebook Kit MK605 — making it easy for you to use your laptop, your way. Around the house or at your desk, the Notebook Kit MK605 gives you everything you need for a comfortable, organized space. You’ll enjoy precise cursor control with the wireless laser mouse, and the pivoting riser lets you elevate your laptop to one of three angles for a height that’s just right for you. Plus, you can place the compact, wireless keyboard where it feels best — and connect both the mouse and keyboard through one tiny Logitech? Unifying receiver that stays in your notebook and can be paired with up to four more compatible mice and keyboards. The Logitech Notebook Kit MK605 is expected to be available in the U.S. and Europe in November for a suggested retail price of $99.99 (U.S.).

Windows Display Driver Model (WDDM, also WVDDM) is the graphic driver architecture for video card drivers running Microsoft Windows versions beginning with Windows Vista. WDDM provides the functionality required to render the desktop and applications using Desktop Window Manager, a compositing window manager running on top of Direct3D 9.0Ex. It also provides device driver interfaces required by Direct3D 10 runtime.

Overview

WDDM drivers enable new areas of functionality which were not uniformly provided by earlier display driver models. These include:

In the context of graphics, virtualization means that individual processes (in userland) cannot see the memory of adjacent processes even by means of insertion of forged commands in the command stream. WDDM drivers allow video memory to be virtualized, and video data to be paged out of video memory into system RAM. In case the video memory available turns out to be insufficient to store all the video data and textures, currently unused data is moved out to system RAM or to the disk. When the swapped out data is needed, it is fetched back. Virtualization could be supported on previous driver models (such as the XP Driver Model) to some extent, but was the responsibility of the driver, instead of being handled at the runtime level.

The runtime handles scheduling of concurrent graphics contexts. Each list of commands is put in a queue for execution by the GPU, and it can be preempted by the runtime if a more critical task arrives and if it has not begun execution. This differs from native threads on the CPU where one task cannot be interrupted and therefore can take longer than necessary and make the computer appear less responsive. A hybrid scheduling algorithm between native and light threads with cooperation between the threads would achieve seamless parallelism. It is important to note that scheduling is not a new concept but it was previously the responsibility of individual driver developers. WDDM attempts to unify the experience across different vendors by controlling the execution of GPU tasks.

A Direct3D graphics surface is the memory area that contains information about the textured meshes used for rendering a 2D or 3D scene. WDDM allows Direct3D surfaces to be shared across processes. Thus, an application can incorporate a mesh created by another application into the scene it is rendering. Sharing textures between processes before WDDM was difficult, as it would have required copying the data from video memory to system memory and then back to video memory for the new device.

If a WDDM driver hangs or encounters a fault, the graphics stack will restart the driver. A graphics hardware fault will be intercepted and if necessary the driver will be reset. Drivers under Windows XP were free to deal with hardware faults as they saw fit either by reporting it to the user or by attempting to recover silently. With a WDDM driver, all hardware faults cause the driver to be reset and the user will be notified by a popup; this unifies the behavior across vendors.

Previous drivers were fully implemented in kernel mode, whereas WDDM is implemented partly in user mode. If the user mode area fails with an unrecoverable error, it will, at the most, cause the application to quit unexpectedly instead of producing a blue screen error as it would in previous driver models.

WDDM also allows the graphic hardware to be reset or unplugged without a proper reboot. In practice, a driver update should not necessitate a reboot.

A typical application that relies on the Windows Display Driver Model is the Desktop Window Manager. Since the desktop and application windows managed by DWM are Direct3D applications, the number of open windows directly affects the amount of video memory required. Because there is no limit on the number of open windows, the video memory available may prove insufficient, necessitating virtualization. As the window contents that DWM composes into the final desktop are generated by different processes, cross-process surface sharing is necessary. Also, because there can be other DirectX applications running alongside DWM on the DWM-managed desktop, they must be able to access the GPU in a shared manner, necessitating scheduling.

Though this is true for Microsoft’s implementation of a composited desktop under Windows Vista, on the other hand, a composited desktop need not theoretically require a new display driver model to work as expected. Successful implementations of composited desktops were done before Windows Vista on other platforms such as Quartz, Compiz, WindowFX). The approach Microsoft attempted was to try to make sure WDDM was a unified experience across different GPUs by standardizing their features and performance. The software features missing from other driver models could be made immaterial by extensions or if a less restrictive or simply different driver model was in place.

One of the current limitations of WDDM driver model version 1.0 is that it does not support multiple drivers in a multi-adapter, multi-monitor setup. If a multi-monitor system has more than one graphics adapter powering the monitors, both the adaptors must use the same WDDM driver. If more than one driver is used, Windows will disable one of them..

WDDM does not allow some modes that were previously handled by the driver such as spanning mode (same desktop view across two monitors). The new driver model also currently puts a limit on what hardware can support it, it needs to have Shader Model 2.0 support at least (fixed function pipeline is now translated to 2.0 shaders) and some other hardware features that were not previously enforced (causing, for example, SM 2.0-supporting hardware such as Intel GMA 900 to fail the WDDM certification ).

WDDM driver for Direct3D 10-level hardware needs to implement device driver interfaces for both Direct3D 10 runtime and Direct3D 9Ex runtime in order to run legacy Direct3D applications and DWM composition engine.

Windows 7 features WDDM v1.1; the details of this new version were unveiled at WinHEC 2008. New features include :

* Return of 2D GUI hardware acceleration in DXGI 1.1 for use by GDI  and Direct2D/DirectWrite
o BitBlt, StretchBlt, TransparentBlt
o AlphaBlend, ColorFill
o ClearType font support
* DXVA-HD DDI
* Hardware video overlay DDI
* Optional AES 128 encryption
* Optional decoding of encrypted video content
* Support multiple drivers in a multi-adapter, multi-monitor setup

Hardware acceleration of GDI and Direct2D/DirectWrite operations helps reduce memory footprint in Windows 7, because DWM compositing engine no longer needs to keep a system memory copy of all surfaces used by GDI/GDI+, as in Windows Vista.

Support for WDDM 1.1 drivers and 2D acceleration of Direct2D and DirectWrite will also be available with Windows Vista Platform Update; however GDI/GDI+ in Vista will continue to rely on software rendering.

At WinHEC 2006, Microsoft talked about how it was planning a major change to WDDM to allow for better multitasking on GPUs. According to Microsoft, WDDM 1.0 only allows rudimentary task scheduling with rendering “batch queue” granularity. The upcoming WDDM 2.0 and WDDM 2.1, which were expected post-Vista but on which Microsoft had not put an introduction date, would offer fine grain preemptive multitasking and would require a new generation of GPUs.

In computing, the Windows Driver Model (WDM) — also known at one point as the Win32 Driver Model — is a framework for device drivers that was introduced with Windows 98 and Windows 2000 to replace VxD, which was used on older versions of Windows such as Windows 95 and Windows 3.1, as well as the Windows NT Driver Model.

Overview

WDM drivers are layered in a complex hierarchy and communicate with each other via I/O request packets (IRPs). The Microsoft Windows Driver Model defined a unified driver model for the Windows 98 and Windows 2000 lines by standardizing requirements and reducing the amount of code that needed to be written. WDM drivers will not run on operating systems earlier than Windows 98 or Windows 2000, such as Windows 95, Windows NT 4.0 and Windows 3.1. By conforming to WDM, drivers can be binary compatible and source-compatible across Windows 98, Windows 98 Second Edition, Windows Me, Windows 2000, Windows XP, Windows Server 2003 and Windows Vista (for backwards compatibility) on x86-based computers. WDM drivers are designed to be forward-compatible so that a WDM driver can run on a version of Windows newer than what the driver was initially written for, but doing that would mean that the driver cannot take advantage of any new features introduced with the new version. WDM is generally not backward-compatible, that is, a WDM driver is not guaranteed to run on any older version of Windows. For example, Windows XP can use a driver written for Windows 2000 but will not make use of any of the new WDM features that were introduced in Windows XP. However, a driver written for Windows XP may or may not load on Windows 2000.

WDM exists in the intermediary layer of Windows 2000 kernel-mode drivers and was introduced to increase the functionality and ease of writing drivers for Windows. Although WDM was mainly designed to be binary and source compatible between Windows 98 and Windows 2000, this may not always be desired and so specific drivers can be developed for either operating system. WDM drivers can be classified into the following types and sub-types:

A function driver is the main driver for a device. A function driver is typically written by the device vendor and is required (unless the device is being used in raw mode). A function driver can service one or more devices.

* Class drivers: These are a type of function drivers and can be thought of as built-in framework drivers that miniport and other class drivers can be built on top of. The class drivers provide interfaces between different levels of the WDM architecture. Common functionality between different classes of drivers can be written into the class driver and used by other class and miniport drivers. The lower edge of the class driver will have its interface exposed to the miniport driver, while the upper edge of top level class drivers is operating system specific. Class drivers can be dynamically loaded and unloaded at will. They can do class specific functions that are not hardware or bus-specific (with the exception of bus-type class drivers) and in fact sometimes only do class specific functions like enumeration.
* Miniport drivers: These are also function drivers for USB, Audio, SCSI and network adapters. They should usually be source and binary compatible between Windows 98 and Windows 2000 and are hardware specific but control access to the hardware through a specific bus class driver.

A bus driver services a bus controller, adapter, or bridge. Microsoft provides bus drivers for most common buses, such as PCI, PnPISA, SCSI, USB and FireWire. Each software vendor can create their own bus drivers if needed. A bus driver can service more than one bus if there is more than one bus of the same type on the machine.

Filter drivers are optional drivers that add value to or modify the behavior of a device and may be non-device drivers. A filter driver can also service one or more devices. Upper level filter drivers sit above the primary driver for the device (the function driver), while lower level filter drivers sit below the function driver and above the bus driver.

* Driver service: This is a type of kernel-level filter driver implemented as a Windows service that enables applications to work with devices.

Windows 98 based operating systems (Windows 98, Windows 98 Second Edition, and Windows Me) are able to use both WDM and VxD (Virtual device driver) driver standards. Both drivers models can provide unique and different features for the same hardware. However, usually the newer WDM standard provides more features. For example, if a TV tuner card using a VxD driver is able to capture images at a resolution of 384 x 288 pixels, the same TV Tuner card with the WDM driver model may be able to capture at a resolution of 768 x 576 pixels. This can be attributed to the new Broadcast Driver Architecture model which is part of WDM.

The Windows Driver Model, while a significant improvement over the VxD and Windows NT driver model used before it, has been criticised by driver software developers [1], most significantly for the following:

* WDM has a very steep learning curve.
* Interactions with power management events and Plug-and-play are difficult. This leads to a variety of situations where Windows machines cannot go to sleep or wake up correctly due to bugs in driver code.
* I/O cancellation is almost impossible to get right.
* Thousands of lines of support code are required for every driver.
* No support for writing pure user-mode drivers.

There were also a number of concerns about the quality of documentation and samples that Microsoft provided.

Because of these issues, Microsoft has released a new framework to replace WDM, called the Windows Driver Foundation, which includes Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF). Windows Vista supports both WDM and the newer Windows Driver Foundation. KMDF is also available for download for Windows XP and even Windows 2000, while UMDF is available for Windows XP.

In computing, a device driver or software driver is a computer program allowing higher-level computer programs to interact with a hardware device.

A driver typically communicates with the device through the computer bus or communications subsystem to which the hardware connects. When a calling program invokes a routine in the driver, the driver issues commands to the device. Once the device sends data back to the driver, the driver may invoke routines in the original calling program. Drivers are hardware-dependent and operating-system-specific. They usually provide the interrupt handling required for any necessary asynchronous time-dependent hardware interface.

Purpose

A device driver simplifies programming by acting as a translator between a hardware device and the applications or operating systems that use it. Programmers can write the higher-level application code independently of whatever specific hardware device it will ultimately control, because code and device can interface in a standard way, regardless of the software superstructure or of underlying hardware. Every version of a device, such as a printer, requires its own hardware-specific specialized commands. In contrast, most applications utilize devices (such as a file to a printer) by means of high-level device-generic commands such as PRINTLN (print a line). The device-driver accepts these generic high-level commands and breaks them into a series of low-level device-specific commands as required by the device being driven. Furthermore, drivers can provide a level of security as they can run in kernel-mode, thereby protecting the operating system from applications running in user-mode.

Device drivers can be abstracted into logical and physical layers. Logical layers process data for a class of devices such as Ethernet ports or disk drives. Physical layers communicate with specific device instances. For example, a serial port needs to handle standard communication protocols such as XON/XOFF that are common for all serial port hardware. This would be managed by a serial port logical layer. However, the logical layer needs to communicate with a particular serial port chip. 16550 UART hardware differs from PL-011. The physical layer addresses these chip-specific variations. Conventionally, OS requests go to the logical layer first. In turn, the logical layer calls upon the physical layer to implement OS requests in terms understandable by the hardware. Inversely, when a hardware device needs to respond to the OS, it uses the physical layer to speak to the logical layer.

In Linux environments, programmers can build device drivers either as parts of the kernel or separately as loadable modules. Makedev includes a list of the devices in Linux: ttyS (terminal), lp (parallel port), hd (disk), loop (loopback disk device), sound (these include mixer, sequencer, dsp, and audio)… [1]

The Microsoft Windows .sys files and Linux .ko modules contain loadable device drivers. The advantage of loadable device drivers is that they can be loaded only when necessary and then unloaded, thus saving kernel memory.

Writing a device driver requires an in-depth understanding of how the hardware and the software of a given platform function. Drivers operate in a highly privileged environment and can cause disaster if they get things wrong.[2] In contrast, most user-level software on modern operating systems can be stopped without greatly affecting the rest of the system. Even drivers executing in user mode can crash a system if the device is erroneously programmed. These factors make it more difficult and dangerous to diagnose problems.

Thus the task of writing drivers usually falls to software engineers who work for hardware-development companies. This is because they have better information than most outsiders about the design of their hardware. Moreover, it was traditionally considered in the hardware manufacturer’s interest to guarantee that their clients can use their hardware in an optimum way. Typically, the logical device driver (LDD) is written by the operating system vendor, while the physical device driver (PDD) is implemented by the device vendor. But in recent years non-vendors have written numerous device drivers, mainly for use with free and open source operating systems. In such cases, it is important that the hardware manufacturer provides information on how the device communicates. Although this information can instead be learned by reverse engineering, this is much more difficult with hardware than it is with software.

Microsoft has attempted to reduce system instability due to poorly written device drivers by creating a new framework for driver development, called Windows Driver Foundation (WDF). This includes User-Mode Driver Framework (UMDF) that encourages development of certain types of drivers — primarily those that implement a message-based protocol for communicating with their devices — as user mode drivers. If such drivers malfunction, they do not cause system instability. The Kernel-Mode Driver Framework (KMDF) model continues to allow development of kernel-mode device drivers, but attempts to provide standard implementations of functions that are well known to cause problems, including cancellation of I/O operations, power management, and plug and play device support.

Apple has an open-source framework for developing drivers on Mac OS X called the I/O Kit.
Kernel-mode vs user-mode

Device drivers, particularly on modern[update] Windows platforms, can run in kernel-mode (Ring 0) or in user-mode (Ring 3).[3] The primary benefit of running a driver in user mode is improved stability, since a poorly written user mode device driver cannot crash the system by overwriting kernel memory.[4] On the other hand, user/kernel-mode transitions usually impose a considerable performance overhead, thereby prohibiting user mode-drivers for low latency and high throughput requirements.

In computers, a printer driver or a print processor is a piece of software that converts the data to be printed to the form specific to a printer. The purpose of printer drivers is to allow applications to do printing without being aware of the technical details of each printer model.

Printer drivers should not be confused with print spoolers, that queue print jobs and send them to printer one after the other.

Printer drivers in different operating systems

On UNIX systems and other systems which use the Common Unix Printing System, such as Mac OS X, printer drivers are typically implemented as filters. They are usually named the front end of the printing system, while the printer spoolers constitute the back end.

Backends are also used to determinate the available devices. On startup, each backend is asked for a list of devices it supports, and any information that is available.

On MS-DOS, there have been no system-wide printer drivers; each application was shipped with its own printer drivers, which were essentially descriptions of printer commands. Printers, too, have been supplied with drivers for the most popular applications. In addition, applications included tools for editing printer description, in case there was no ready driver. In the days when DOS was widely used, many printers had emulation modes for Epson FX80[1] and IBM Proprinter commands. It appears that these also worked with Windows 3.0[2].

On Microsoft Windows systems, printer drivers make use of GDI (Unidrv or PScript-based) or XPS (XPSDrv). Programs then use the same standard APIs to draw text and pictures both on screen and on paper. Printers which use GDI natively are commonly referred to as Winprinters and are considered incompatible with other operating systems.

Win32 APIs also allow applications to send data directly to the spooler, bypassing the printer driver; however, few applications actually use this option.

The original AmigaOS up to 1.3 supported printers through a standard series of drivers stored at the required path “Sys:Devs/Printers”. All printer drivers were stored in that directory, and covered the standard printers in 1985-1989 circa, included EpsonFX standard driver, XEROX 4020, HP, etcetera.

Any Amiga printer driver had to communicate though the standard Amiga Printer. Device (the default standard hardware device of Amiga dealing with printers), and the standard Parallel. Device (which controlled parallel port) and the driver would then control the printer on its own.

Amiga printers were an innovation for their time. The had the ability to print up to 4096 colors.

Through the use of the Printer Preferences program printers could be connected to the serial port as well.

Amiga also had support for a virtual device “PTR:” to refer to printer.device so, for example the command “COPY file TO PRT:” caused the file to be printed directly bypassing Parallel. Device and the default Printer Driver. Amiga used a standard ANSI “Esc sequences” list of ESC (Escape) Commands, not the special ones defined by the various printer manufacturers. This way every application on the Amiga could use the same standard set of control sequences and wouldn’t need to know which printer is actually connected. The printer driver then translated these standard sequences into the special sequences a certain printer understands.

Amiga internal function “PWrite” of Printer. Device writes ‘length’ bytes directly to the printer. This function is generally called on by printer drivers to send their buffer(s) to the printer. Number of buffers are decided by the persons who created the driver. Amiga lacked a standard Printer Spooler.

Since AmigaOS 2.0 a standard Printer. Device was changed to control various printers at same time. The Printer preferences were divided in three main panels: Prefs:Printer which selects main printer and other basic elements such as “Print Spacing” and “Paper Size”. PrinterGFX controlled features like Dithering and Scaling. PrinterPS controlled Postscript Printers. The printer drivers surprisingly remained almost same of Workbench 1.3, with 4096 limits.

This fact led Amiga users to prefer third party Printer Systems with their own drivers, like TurboPrint and PrintStudio, which introduced not only recent drivers, but also featured a functioning Printer Spooler into Amiga, and featured 16 millions colors printing. MorphOS Amiga clone Operating System uses a special version of TurboPrint to pilot recent printers.

Many Amiga programs like DTP programs as PageStream featured in the past its own printer drivers.

USB printers are automatically recognized by the Amiga USB Stack, which is called Poseidon. This stack is capable of detecting any USB device by its class, but printers still require a driver to be controlled.

Usually the operating system needs to know the characteristics of a printer. The PPD files are the normal way to supply this information. They have the advantage of being system independent, and there is a freely available large database of them, Foomatic.