> > I don't see the default values discussed in the updated
> > spec. IMO, these seem important to the user experience
> > and relevant to the case. When Solaris first installed,
> > what will occur if the Lid is closed, what is the LCD brightness,
> > what action does the power button have?
>
> The LSARC GPM case handles the GUI which really sets the default action.
From my comments there: "the PSARC GPM case is implying that the
LSARC GPM [2007/702] case is to specify the the default values
for lid, brightness, power and by implication CPUFreq.
IMO, that is backwards, and still needs to be worked out."
They are not specified there. Indeed IMO, that is backwards.
The LSARC case has no privilege to set anything. How can it
define defaults? IMO, one of the things this case needs to
do is provide the defaults for a freshly installed system.
I'd expect it to be this case.
> Lid -- the default action on lid close is to do nothing.
> Power button -- the default action is to ask the user similiar to what
> happens now. It will display gnome-sys-suspend GUI when the power
> button is pressed.
> Brightness -- Nothing will happen, i.e. no change in brightness.
Are these the specified defaults for what this case will
supply?
Now on to a real question with Lid: The actions from the
LSARC GPM case says: "such as blank screen,suspend,hibernate,shutdown.
Suspend and hibernate depends on HAL interfaces, particularly
blanking screen relies on X11 extension DPMS."
I don't see blank screen in the spec of this case.
And most importantly, it would seem to me that entering
screen lock would be a required action in the set of selectable
actions -- and from a security perspective the default.
It certainly is a selectable option on MacOS:
"Require password to wake this computer from sleep or screen
saver" is what it is called.
How does this case provide for a screen lock on lid switching?
> > Perhaps parochically, I also don't see why the policy, which I
> > believe is implemented in HAL, should not just depend on PSARC/2008/034
> > Defining Workstation Owner Infrastructure. And thus this
> > case have a dependency to that one. Afterall, this/that is
> > exactly why 2008/034 was submitted. It seems to me implementing
> > your own /dev/console and authorization tests side step the
> > architecuture of allowing the Administrator to have control.
[relocated -- really not architectural]
> When this project was started, PSARC/2008/034 Defining Workstation Owner
> Infrastructure wasn't on the horizon at all.
I won't argue timing with you. It's been on the horizon for
quite some time (years infact) and under active discussion
including Randy and the x86power team in my mail log since 11 Dec.
Indeed this was one of the motivating cases for not delaying the
work any longer.
> I'll contact you separately about your case plans.
My plan is to do the work as it fits with the other things
I've been tasked to do. IMO, your plan needs to be dependent
on that work. As I said, if your management doesn't like the
pace at which I'm able to deliver, they can provide resources
and/or discuss other options with my management.
> > Finally perhaps a wording nit: "*Will consult with the audit
> > team to enable auditing." seems somewhat weak. Will meet
> > the Solaris Audit policy,
> > http://opensolaris.org/os/community/arc/policies/audit-policy
> > seem more appropriate.
>
> Ok, I will change the wording.
So you'll be meeting with the Audit project team sometime
soon ;-) and wanting input/resources from them (i.e., me).
Gary..
