On Wed, Aug 6, 2008 at 4:00 AM, Brian Cameron <[EMAIL PROTECTED]> wrote: > 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 whether it will be at all possible to run multiple Xorgs on each VT. Does the VT design incorporate this kind of a behavior ? This will be like providing multiple virtual display framebuffers. > > 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. This will kill the Xserver controlled by the given KDM process. > > 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? KDM first monitors the /var/adm/utmpx file for an entry indicating the user has logged into the Console after stopping Xserver. Subsequently it watches utmpx for an entry that the user has logged out of the Console session. At this point it restarts the Xserver. The user does not have to run any command. KDM is an enhanced version of the legacy Xdm. This behavior is directly derived from the Xdm code. Another thing I find nice in KDM is it's ability for a seamless login experience. The wallpaper set by a KDM theme is not removed by KDM. The desktop comes up and then plonks down it's own wallpaper. If the desktop wallpaper is same as the KDM wallpaper then the experience is completely seamless with zero flickering. You will notice this if you install and run BeleniX 0.7.1 from harddisk. GDM causes flickering by changing the background multiple times. Long back when I first built GNOME 2.10 for Solaris 10, I had put in a workaround using esetroot early in the session startup script to set the same wallpaper as the desktop which avoided a bit of the ugly flicker. Regards, Moinak. > > Brian > -- ================================ http://www.belenix.org/ http://moinakg.wordpress.com/ _______________________________________________ opensolaris-discuss mailing list [email protected]
