eject button touched while tray locked

plavarre at lexar.com plavarre at lexar.com
Wed May 16 12:40:47 PDT 2007


Formatted message: <A HREF="r0705162_f.htm">HTML-formatted message</A>

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 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of David
Burg
Sent: Wednesday, May 16, 2007 11:42 AM
To: T10 Reflector; mtfuji5 at 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.



More information about the T10 mailing list