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.