Moinak: > Yes VT will help but may not solve this problem I think since there > will be an > Xorg already running and another Xorg will refuse to run with -configure. > Not > entirely sure though.
You are right, you may still need to disable the gdm service, but you can do it from the console VT. > IMHO in a few small respects GDM is a step backwards from Xdm/Dtlogin. > I do not understand why a few of the basic features of Dtlogin are still > not provided by GDM today. The problem is that the interface that CDE login uses has been deemed poorly designed, and ARC has recommended we not use it for GDM. So we will need to consider a new approach if we want this feature going forward. An additional problem with the old CDE approach is that it assumes you only have one login manager running on the console. Having a feature to "drop to console" in a VT environment would be a bit weird. If the user has many display managers running on different VT's, would they need to "drop to console" in them all in order to stop all Xservers so that the Xorg file can be generated? I am not sure how you would make this work. If GDM had a button that disabled the GDM service, for example, then this would drop you to console as desired, but how would users know how to start it back up? Some users would probably not be aware of how to run svcadm to restart it. > KDM (K Display manager) on the other hand, that we use on BeleniX > provides a drop down to Console Login just like Dtlogin. It does this by > watching /var/adm/utmpx and works nicely. Does this kill all Xservers so the user can edit their Xorg file, or does the user have to "drop to console" in each VT separately? Most users probably aren't using VT's when they want to "drop to console" so perhaps not a big problem. How does KDE restart when the user is done on the console? Do they have to run a command, or does KDM just nicely restart when they exit the console session? If the later, what mechanism are you using to make this work? Brian _______________________________________________ opensolaris-discuss mailing list [email protected]
