Auxiliary Display Driver Interface for Windows Vista Command Translation

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Creating a driver for an auxiliary display device in Windows Vista-based systems is complex and time-consuming due to the need to decode data from the auxiliary display platform into logical operations and transmit them using a protocol specific to the device, varying by device type, making it error-prone and tedious for manufacturers.

Innovation Solution

An interface set is implemented to couple the auxiliary display device driver with the auxiliary display platform, allowing external code to handle commands and translate them into a format understood by the driver, simplifying the communication process and reducing the burden on driver implementers.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If manufacturers create custom drivers for each auxiliary display device type, then device-specific communication protocols can be optimized, but the development time and complexity increase significantly

Engineering Contradiction:

Improvedevice-specific communication optimizationVSAvoiddriver development time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The patent introduces an intermediary interface layer between the auxiliary display platform and device-specific drivers. This interface acts as a mediator that translates platform commands into device-specific protocols, allowing manufacturers to focus only on the transport layer while the interface handles the complex translation work.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The driver architecture is segmented into two distinct parts: a universal interface layer that handles platform communication, and device-specific transport layers that handle protocol conversion. This segmentation allows the interface to be reused across all device types while each device can have its own optimized transport implementation.

Inventive Principle:

Principle #1Segmentation

2Reliability

If manufacturers implement custom decoding and translation logic in drivers, then communication with specific device types is optimized, but the complexity and error-proneness of driver code increases

Engineering Contradiction:

Improvedevice communication optimizationVSAvoiddriver code complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The interface serves as an intermediary that centralizes the decoding and translation logic. Instead of embedding this complex logic within each device-specific driver, the interface handles it as a separate, reusable component, making the driver code simpler and easier to maintain.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The interface is designed to be universal, handling communication with multiple different device types through a single unified structure. This multi-functionality eliminates the need for manufacturers to implement custom decoding logic for each device type, reducing overall code complexity.

Inventive Principle:

Principle #6Universality (Multi-functionality)

3Adaptability or versatility

If manufacturers create drivers from scratch for each auxiliary display device, then device-specific functionality can be fully optimized, but the development process becomes tedious and error-prone

Engineering Contradiction:

Improvedevice-specific functionality optimizationVSAvoiddriver development ease

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The interface acts as a pre-built intermediary layer that handles the tedious tasks of command decoding and protocol translation. Manufacturers can leverage this existing infrastructure and focus only on implementing the device-specific transport portion, significantly ease the development process.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The interface and its translation logic are prepared in advance as a universal component. This preliminary action eliminates the need for manufacturers to perform time-consuming decoding and translation development from scratch, allowing them to focus on device-specific optimizations.

Inventive Principle:

Principle #10Preliminary action

Data Source

PatentUS8659505B2Auxiliary display device driver interface

Publication Date: 2014.02.25 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

In a main computer system coupled to an auxiliary display device, described is an interface set for implementation by an auxiliary display device driver, to couple the driver to an auxiliary display platform. Commands received from the auxiliary display platform may be handled by code external to the driver, such as a class extension object. For example, the class extension object may interpret and/or translate commands received from the auxiliary display platform into a format understood by the driver code. The auxiliary display device driver may then provide corresponding command information including data to the auxiliary display device via the transport. Event data may be returned from the auxiliary display device driver via the interface set to the class extension object, such that corresponding event information, e.g., received at the auxiliary display device, may be returned to the auxiliary display platform.