MMC Get Event Status Notification and Windows

  • Article

This articles provides information about how to implement the GET EVENT STATUS NOTIFICATION commands for Multi-Media Command Set-5 (MMC) compliant devices in Microsoft Windows XP, Windows Server 2003, and future versions of Windows.

Purpose and Requirements

This article provides vendors with guidelines for implementing these commands to take advantage of the built-in support provided in Windows. It is expected that the reader of this article is familiar with the MMC specification as relates to GET EVENT STATUS NOTIFICATION.

Introduction

The Multi-Media Command Set-5 (MMC) and Mt. Fuji-7 specifications describe a command to help the operating system acquire information about device behavior changes. This GET EVENT STATUS NOTIFICATION command set applies to all Type 5 devices, including CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-R, DVD-RW, DVD+R, DVD+RW, HD DVD-ROM, HD DVD-R, HD DVD-RW, HD DVD-RAM, BD-ROM, BD-R, BD-RE and so on, which are referred to in this article as MMC-compliant storage devices.

The proper implementation of these commands, together with operating system support, can result in improved autorun time, better user interface results, better time estimates for long operations, and many other user benefits.

Historically, some incompatible or non-compliant methods of implementing this command resulted because of the lack of available tests and some ambiguity in the specification documents.

This article, together with the Windows Hardware Cerification Kit (HCK) optical device test, is provided to help clarify the specification and to improve implementations for efficiency within the Windows operating systems.

The following guidelines are based on these assumptions:

  • An MMC-compliant storage device supports N discrete Event Class types of events with N strictly higher than 0.

  • An event is considered NoChange if bits 0-3 (Event Code Field) of byte 0 of the returned Event Descriptor are zero.

Functional Behavior Guidelines

To ensure the best compatibility with Windows operating systems, the following functional behavior regarding the GET EVENT STATUS NOTIFICATION command is required.

  • Requests for a Notification Class of zero must return an event header with the NEA bit set, the Notification Class field set to 000b, and the Supported Event Classes byte set to reflect all N supported Event Classes.

  • Requests may arrive at the device from a host requesting any subset of events that the device supports. For example, if { OpChange, DeviceBusy, Media } events are supported, then any of the following events may be requested by the host by a single command block:

    { OpChange } { DeviceBusy }
    { Media } { OpChange, DeviceBusy }
    { OpChange, Media } { DeviceBusy, Media }
    { OpChange, DeviceBusy, Media }  

     

  • The data reported by the drive to the host must contain exactly one Event Class.

  • The data reported by the drive to the host must contain an Event Class that was requested by the host in the command block.

  • The data reported by the drive to the host must not report a higher priority Event Class if the Event Class was not requested by the host.

  • If multiple Event Classes are requested by the host in a single command block, the drive must follow the following procedure to determine the Event Class to report to the host:

    For each requested Event Class, in order of priority per the specification:

    • If an event other than a NoChange event exists, report it.

    • If only NoChange events exist, report highest priority NoChange event.

  • The drive must simultaneously support (or queue) at least one event of each Event Class which it supports. This prevents events of different Event Classes from interfering with each other.

    For example, if a Media Event and External Request event both occur at the same time, and the host is continuously requesting both event types, then the drive must:

    • Store both events.

    • Report the External Request event first (higher priority).

    • Clear the External Request event.

    • Not clear the Media Event upon reporting the External Request event.

    • Report the Media Event upon the next GET EVENT STATUS NOTIFICATION request.

To support such behavior early, the following high-level design of firmware to support GET EVENT STATUS NOTIFICATION should be considered. This does not preclude other implementations if the device behaves as expected by the operating system.

For each supported Event Class, have a queue of appropriate depth (typically 1) of events for that Event Class. For drives that support the Mt. Rainier format, the minimum appropriate queue depth is 2, and special handling should be given to both the BGFormatCompleted and BGFormatRestarted Media Events.

To implement this more simply, and to avoid queue depths greater than one, logically use a queue depth of 1 for the Media Events unless one of the BGFormat events is supported. When an event is generated by the device, the device looks to see if the new event is of greater priority (per the MMC specification) than the current event that is stored of that class. If it is, the new event replaces the existing event in the 1-deep queue for that Event Class. Otherwise, the new event is discarded.

In addition, in the case of the events { BGFormatCompleted, BGFormatRestarted }, these events must be placed into the "BGFormat," but never the "Media" queue. Similarly, other Media events must always go into the "Media," and never the "BGFormat" queue. When the device is searching for which event to report to the host, the "BGFormat" block may be logically considered an event of priority less than "Media." Any or all of the blocks mentioned may be removed if the related Event Class is not supported.

 

Windows Logo Program

Current "Designed for Windows" Logo Program requirements for GET EVENT STATUS NOTIFICATION support are defined in the Microsoft Storage Devices logo requirement from Winqual logopoint.

Resources and Call to Action

Call to Action:

  • For system manufacturers: Require that drives for your systems implement GET EVENT STATUS NOTIFICATION as described in this article.

  • For firmware engineers: Implement firmware that supports behavior that is compatible with Windows, as described in this article.

  • For device manufacturers: Require firmware which implements GET EVENT STATUS NOTIFICATION as described in this article.

Feedback:

Resources:

 

 

Send comments about this topic to Microsoft