Subject: eject button touched while tray locked Date: Wed, 16 May 2007 12:40:47 -0700 From: <plavarre@lexar.com> To: <daviburg@windows.microsoft.com> Cc: <t10@t10.org>, <p.lavarre@ieee.org> X-Message-Number: 7785 Formatted message: HTML-formatted message David, Hi. Whoa. Eject button touched while tray locked matters too. A usable host & device system owes a duty to the human operator: you hit me, I hit you back. That duty isn't actionable in the host unless the device admits to the host that the eject button was pressed or released while tray locked. Whether "everybody knows" that our de facto standard as it exists in practice only defines events while tray unlocked, I don't know. Whether eject button touched while tray locked matters enough to be an explicit part of our revised de jure standard, I don't know. As you can see, I've tweaked the Subject and Cc lines of this thread to leave you more free to discuss Mt Fuji Dvd/cd Scsi encoding details without anyone having been asked to stop and enlighten ignorant me. Myself, I like devices that xor the eject button into the activity light of the device. Then the device blinks when the user presses the button, and blinks again when the user releases the button, mostly absolving the host from the system's duty to respond in some way to human input signals. I first shipped that design in 1995, I'm sorry to see no one copy that design since. Occasionally I threaten to write the app that pops up to say "please don't press that button", when a user does press the button while tray locked, but somehow I never got around to it. --- If some host someday made the eject button of the Dvd/cd device work like the Eject button on a Mac OS X keyboard, that would make much sense to me. An eject key is an eject key is an eject key, so far as I know. Plus the eject key on the device has the advantage of pointing emphatically to a particular media slot. --- Hope you enjoyed colliding with this vanishingly small yet eternal obsession of mine, ________________________________ From: owner-t10@t10.org [mailto:owner-t10@t10.org] On Behalf Of David Burg Sent: Wednesday, May 16, 2007 11:42 AM To: T10 Reflector; mtfuji5@avc-pioneer.com Subject: MMC/MtFuji: Clarification of media eject request event, external request events. Hello, I would like to discussion two clarifications of the events in MMC/MtFuji specifications. The following issues were found will prototyping logo test cases for device compliance validation. 1) The current description of the media eject request event is: "The Drive has received a request from the user (usually through a mechanical switch on the Drive) to eject the specified slot or media." I suspect that additionally this event is generated only if the tray is locked. That is, if the tray is not locked and the user press the eject button, the tray will be open but no media eject event will be generated by the device. Correct? If so, the description should be clarified to explicitly state that the event is generated only if the tray is locked with the prevent/allow medium removal. 2) External request events drive key down and drive key up have currently the following description: "A front, back, or remote button has been depressed / released" This sounds like two external request events will be generate each time the user press and release the front eject/load button of the device. However in experimentation, no such event was generated by devices we exercised. Is it correct that no external request event is generated for the load/eject button of the device? If so, we should clarify the description of the external request events. Or maybe this is related to the playback control button from legacy CD-audio devices? Then we should make the events legacy as well. Best regards, David Burg.