Gary Winiger wrote: >>> 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."
The PSARC case does not imply it will set the defaults on a freshly installed system. My comments above means exactly that the GPM GUI which is handled by the LSARC case will set the defaults. > > They are not specified there. Indeed IMO, that is backwards. > The LSARC case has no privilege to set anything. How can it > define defaults? The LSARC case need privileges to do something like "nothing" when the lid closes or do nothing for brightness? 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. > See above. > >>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? No. I was just answering your question for your information. These defaults are not handled by this case. > > 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. The GPM GUI does the calls into DPMS. It doesn't rely on 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. Screen locking is not required. What policy are you referencing that makes it a requirement? > > 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 meant concrete stuff, not talk. Phi > > >>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..
