dhubbell@june.cs.washington.edu (David Hubbell) (09/20/90)
xlock doesn't work on my NCD 16 and 17c X terminals. Is this because 1) I need to give some arguments to xlock. 2) The server software from NCD doesn't support locking the screen. 3) I need something other than xlock. 4) It's infeasible with X11R4. 5) You tell me. Thanks in advance, Dave Hubbell
dimick@ncd.COM (Kim Dimick) (09/20/90)
>xlock doesn't work on my NCD 16 and 17c X terminals. Is this because > 1) I need to give some arguments to xlock. > 2) The server software from NCD doesn't support locking the screen. > 3) I need something other than xlock. > 4) It's infeasible with X11R4. > 5) You tell me. > I think you are running in to a difference between running xlock on a work station where a xhost list is save locally and running it on a X Display Station that obtains its xhost list from a remote host via a remote configuration file. The main problem is xlock does the equivalent to a xhost - and once the xhost - is performed the X Display Station that does not keep it xhost list locally will not be able to perform the xhost + when the user tries to return to their work. So the X Display Station will not accept any more connections and the user will get a error similar to this 'Client is not authorized to connect to Server'. I have made some changes to the X11R4 xlock source so it will work correctly on the NCDs and other X Display Station. I have attached the diffs'. ------------------Imakefile differences---------------------- 19c19 < CDEBUGFLAGS = -O -DNDS --- > CDEBUGFLAGS = -g ----------------------xlock.c differences--------------------- 179,180c179 < /* #define DEFAULT_FONTNAME "LucidaSans-24" */ < #define DEFAULT_FONTNAME "*-courier-bold-r-normal--14-*" --- > #define DEFAULT_FONTNAME "LucidaSans-24" 228c227 < /*void*/ --- > void 232d230 < #ifndef NDS 234,236c232,233 < /* XRemoveHosts(dsp, XHosts, HostAccessCount);*/ < /* XEnableAccessControl(dsp);*/ < #endif --- > XRemoveHosts(dsp, XHosts, HostAccessCount); > XEnableAccessControl(dsp); 239c236 < /*void*/ --- > void 243d239 < #ifndef NDS 248d243 < #endif 252c247 < /*void*/ --- > void 285d279 < XSetScreenSaver(dsp, timeout, interval, blanking, exposures); 613d606 < #ifndef NDS 622d614 < #endif 753c745 < /* XSetScreenSaver(dsp, 0, 0, 0, 0);*/ /* disable screen saver */ --- > XSetScreenSaver(dsp, 0, 0, 0, 0); /* disable screen saver */ 757c749 < /* XGrabHosts(dsp);*/ --- > XGrabHosts(dsp); --------------------life.c differences--------------------- 433d432 < /* 435,436d433 < */ < sleep(delay * 1000);
naughton@wind.Eng.Sun.COM (Patrick Naughton) (09/21/90)
In article <13077@june.cs.washington.edu>, dhubbell@june.cs.washington.edu (David Hubbell) writes: |> xlock doesn't work on my NCD 16 and 17c X terminals. Is this |> because |> 1) I need to give some arguments to xlock. |> 2) The server software from NCD doesn't support locking the screen. |> 3) I need something other than xlock. |> 4) It's infeasible with X11R4. |> 5) You tell me. |> |> Thanks in advance, |> Dave Hubbell -- Ok folks, I'm putting the last few portability changes into the new xlock before shipping and have time for one more feature... Do people want to be able to lock machines other than the one they are currently running on? Before all you NCD folks jump up and say "YES.. in fact we've already hacked xlock.c to do it!" lets remember that it will be a real pain if people are able to lock *your* screen which can only be unlocked with *their* password. This is a trivial change and I could controlled by the resource file, or the command line, but I want to make sure that people *really* want it. (Silence is not consent... send mail if you want it.) -Patrick ______________________________________________________________________ Patrick J. Naughton ARPA: naughton@sun.com Window Systems Group UUCP: ...!sun!naughton Sun Microsystems, Inc. AT&T: (415) 336 - 1080
mb@ttidca.TTI.COM (Michael Bloom) (09/25/90)
In article <1990Sep20.100335@wind.Eng.Sun.COM> Patrick Naughton writes: >I'm putting the last few portability changes into the new xlock before >shipping and have time for one more feature... Do people want to be >able to lock machines other than the one they are currently running >on? Before all you NCD folks jump up and say "YES.. in fact we've Well, I think it certainly should be configurable. Also consider that if someone really wants to lock someone else's machine, he does not need the program "xlock". He just needs to write a few lines (:-) of code. What I find interesting is that while the existing xlock program does not work on NCD X terminal displays, it does in fact function properly on Visual X terminal displays. Would anyone care to explain why?
santiago@lerad.pa.dec.com (Eduardo Santiago) (09/28/90)
naughton@wind.Eng.Sun.COM (Patrick Naughton) writes: >I'm putting the last few portability changes into the new xlock before >shipping and have time for one more feature... Do people want to be >able to lock machines other than the one they are currently running >on? One thing that might be nice, even if it's too late to ask for in this release, is the ability to lock multiple screens from one command line, or some other way of handling multi-screen systems. ^E Ed Santiago santiago@decwrl.dec.com DEC Workstations Systems Engineering ..decwrl!santiago