General problems: o PAM get working on solaris o fix up -h o For security (Theo de Raadt and Yuri Bushmelev ) - in initpasswd() - create two pipes - fork a child - read a password from the pipe - do a check - write a 1 or a 0 loop - have the parent revoke it's uid's completely. - use one pipe to send passwords to the child - read for 0 or 1 - use SIGCHLD to detect child exit - look to checkpassword-pam (http://checkpasswd-pam.sourceforge.net/) for an example. o Switching consoles using XFree-4.0, the X server sends a fully-obscured event to all its clients, and when I switch back to the graphical terminal, it sends fully-visible or partially-obscured event to its clients. xlock doesn't handle these event, it still can consume 99% of CPU time in several lock-modes. It would be really good if xlock, when receiving an obscure-event, stopped doing anything CPU-consuming stuff. The three messages (fully visible, partially visible and fully obscured) exist in X11 for a long time. Launch the utility 'xev' and move another window over it, and see what it prints. This is useful so that applications (such as fractal animators or Spectrum/C64 emulators or really anything) know if its window is not visible and therefore can save a lot of cpu time if it doesn't even want to draw (update) its contents. For example there's a spectrum emulator at http://www.inf.bme.hu/~mszeredi/spectemu/spectemu.html, if you launch this and switch to full speed mode, you'll see that it runs much faster if its window is obscured by another window or windows. Using the XFree-3.3 servers if you switched back to the linux console, no events were sent to the applications, so they couldn't realize that thier contents is not visible to the user in this case. In XFree-4.0 the windows get the fully-obscured event when you switch to linux console, so for example a Spectrum emulator can save really a lot of cpu time, since it doesn't need to redraw its screen 50 times per second. o It would be nice to have an option -idletime time. Where xlock would run after a certain idle time. (Here xautolock may help you, see README). o Currently for multiple users to unlock the account one has to have UIDs to be the same. whoami, for example, always comes back with the first one in the list regardless of which of the users it really is. So they'll have to have special accounts for this app. That is okay, but it would be nice if xlock had some sort of command line or xlockrc option that allowed specifiying users who had unlocking privileges. o xscreensaver compatibility writable modes: mandelbrot, tube, (lyupanov?)-> get them to RUN (compile OK) o Add a way to get xlock to switch to "blank" mode after X minutes of (keyboard) inactivity, and to switch back to whatever mode list was being used when activity is detected. This would be good for users using DPMS to power down the monitor without using precious cpu when the modes are not visible. o Some xlock modes take a long time to start. In particular the 3d ones can take up about ten seconds for the necessary libraries to load (on a 400MHz Intel Celeron system). If one of these modes is chosen as the first one to run after xlock starts, then there will be a ten second delay between running xlock and the display actually being locked. If you start xlock from a window manager then it appears that nothing has happened, which can cause the user to click on 'lock screen' again and start a second xlock. The delay itself is probably unavoidable, but xlock could overcome the 'nothing is happening' problem by always choosing the 'blank' mode first. So if you say 'xlock -mode sproingies', first xlock starts and goes into blank mode to make sure the screen is locked, then starts loading and running the bouboules mode. This makes sure that the screen gets locked almost instantly after running xlock and the user doesn't have to wait. Possible further step: always go to 'blank' before even looking at what mode was chosen, in other words before doing command-line checking of the mode name. Suppose I set the 'lock screen' command in my window manager to 'xlock -mode sproingies'. This takes ten seconds or so to load the OpenGL libraries, but it works eventually. Then I use somebody else's machine, which doesn't have the sproingies mode included with xlock. I click on 'lock screen' and xlock prints an error message which goes to my .xsession-errors file. But to the user it looks like nothing has happened. Knowing that sproingies takes a while to start up, I leave the terminal, but in fact it was never locked. It would be better for xlock to go to mode blank first of all, and then try to load sproingies, and if that doesn't exist print an error message to stderr and on the screen. At least that way the display is guaranteed to get locked. o Imagine a crowded lab of workstations. Some have people sat at them but even those machines with nobody in front of them might be locked. If you are a user entering the lab looking for a free machine you look around for a login screen. The login screen is probably easy to spot (at my site, it has a blue background). Or maybe xlock draws some border around main xlock mode screen when logout button is available. Or use some kind of pseudo-transparency to draw such button. To avoid the problem of workstations being locked for too long, there is the 'click here to logout' button which is enabled by default and comes on after twenty minutes. The trouble is that while a with-button xlocked machine is just as usable as a machine showing the login screen, it doesn't _look_ any different to one which is ordinarily locked. If you see five machines showing an xlock display, there's no way to find out which of them you could use other than walking past and tapping a key to see whether the logout button appears. In a lab of 100 PCs this is awkward. I suggest that when the public logout button appears the xlock display should noticeably change. I don't know to what exactly, perhaps the 'type password to logout, select icon to lock' screen should be permanently displayed, with a big logout button in a nice bright colour. Then it would be obvious, even from a distance, whether a session is kick-off-able or really locked. o when a user runs "xlock -mode unknownmode", it should print a warning and default to blank mode or the default mode (random) instead of exiting with a usage error. This way, the screen is still locked as requested by the user if they ask for a mode that is not available. o some sort of command line or xlockrc option that allowed specifiying users who had unlocking privileges. o some sort of completion is used which may be confusing on UNIX Say if a ../bitmaps directory exists and ../bitmap does not xlock -mode random -modelist image -bitmap ../bitmap will try to load ../bitmaps as a file... o kill -HUP to change modes as well as middle mouse button. Needed when using -inroot . o -showfps option may give a Zero Page Read and SEGV error using Mesa and Sun o configure.in should be condensed. Its getting out of hand. o Look into any way of not clearing the screen if can not get control of it (2nd xlock running). o gentlerandom mode option. Switching to next mode when mode completed what it was working on. o On a PsuedoColor display xlock -mode life -install & sleep 5 ; xlock -mode life -install Colors will all be messed up after the second one tries to run. This can easily happen if you are using xautolock and decide to lock the display manually. o -wireframe should be a mode option (i.e. you should be able to turn it on and off for a particular mode). Also a linewidth mode option would be nice o I got an error with moebius running it on opengl on a 24 bit TrueColor like: xlock -mode moebius -visual PseudoColor (all the gl modes are messed up anyway... all mono) o some configurations of linux: swarm and flow has noise when bees go beyond screen (also may happen with forest). Sun Ultra5 PCI Bus 24 bit display: flow has some noise (usually red) This is especially true if you use -inwindow for swarm, flow, euler2d. I think these errors are limited to the graphics card. o A few uninitialized memory reads and memory leaks were detected in some of the code. grep for "PURIFY" in the source files to see where the remaining problems are. Also see docs/Purify for more details. o superquadrics does not work on some Linux boxes (not mine). o Text3d will dump core on some linux boxes (not mine) due to random font routine. Temporary solution: use arial.ttf directly. See "#if 0" in text3d.cc. o glplanet does not display stars clearly on Sun with OpenGL except when in password window (Sun with Mesa ok). o molecule logs me out on Sun Ultra 5 with OpenGL 1.2.1 and 1.2.2 (using gcc or cc) when the return key is held down. This has not been repeated on any other Sun. Tracing on this seems to indicate the release code but when commented out would still die (done with XSynchronize on). o -mono does not work for XPM (they just use XBM when mono), also cage and stairs. o Not all resources are listed in "xlock -resources", e.g. nolock. If xlock is renamed these resources are not picked up. o Without any programs stealing your colors, like netscape xlock -modelist all -sequential -install -verbose Hit the middle button a hundred times (not to bad on an ultra actually) or try -duration 1 and let it sit for a while. The second time it runs the GL modes they have all lost some colors. This was only noticed on Solaris with pseudocolor. Also noticed on an ancient HP9000/380 HPUX9.0 with 6 bit depth (without netscape). o On a German keyboard and Linux if the password contains special characters (`|' vertical bar, `@' at-sign) while in debug mode everything works fine. This probably has something to do with the X11-keymapping, as these characters are composed with the right Alt-key on a German keyboard. o OpenGL and DT may be incompatible on PseudoColor. (MesaGL should be OK.) OpenGL frequently causes xlock to error out on non-default visuals. o Errors in modes, if any, should not break lock. o Unstable mode "run" allows running of separate processes should be made to run on VMS (now just blanks the screen). The problem is a totally different concept of starting other programs from within a program. Also get "run" to run with -debug. o make -n install prefix=/foo/bar does not work. o "xlock -mode random -modelist image -bitmap ./bitmaps/" It should change images when middle mouse is pushed or when -duration time runs out. o jpeg/gif/animated gif support Fix ras for > 8 bit TrueColor o "-visual" commandline argument should accept "best" as well as PseudoColor, TrueColor, default, etc. o Is there any chance the "visual" selection code could be made mode-dependent? Most Xservers that support TrueColor, etc, visuals also support PseudoColor visuals and it would be nice to have color-cycling modes like "starfish" and "swirl" pick a PseudoColor visual if available, while xpm modes could prevent colormap flashing by picking a TrueColor visual. I heard that VisualDepthMask taken out of vis.c it seems to work better to get a PseudoColor visual one a root window of 24 bits. o % make install [...] make[1]: Entering directory `/vol/bitbucket/epa98/xlockmore-5.03/modes' ../mkinstalldirs /vol/linux/apps/bin /usr/bin/install -c -s -o root -m 4111 ../xlock/xlock /vol/linux/apps/bin /usr/bin/install: cannot change ownership of `/vol/linux/apps/bin/xlock': Operat ion not permitted make[1]: *** [install-program] Error 1 Make is trying to install xlock owned by root and suid, but I am not root. It might be more user-friendly to either: - - If the user running 'make install' is not root, assume that xlock should be installed non-suid, or - - If the user is not root, complain and give up. I looked for a configure option to tell the build process not to install suid or owned by root, but I didn't find one (or anything obvious in the README). But you can certainly use xlock if it's not root. o From Duncan Simpson Due to the introduction of Xinerama, and a couple of monitor displays, I would find a horizontal fivision option that runs two windows each half the width of the display (which corresponds to one window one each monitor). Let xlock detect Xinerama enabled and draws login display only on primary screen. I do not know the details of x2x, although I guess various sorts of multiple monitor technology might benefit from this sort of support (one could think of Xnest with re-direction to appropiate screens). Information on x2x is almost certainly somewhere on the web, but I do not have a URL on me (ask your favorite search engine, I guess). I think it involves using multiple boxes for display driving purposes---I hear someone in the lab has 4 screens across with x2x (the pointer moves off one screem onto another). Xnest is an xserver that asks a parent X server to do the work, and I think you can use it to present different display information and so forth. Xinemera is much easier, it basically just glues mutliple bits of hardware together into a single huge bit of virtual hardware. It does not appear in the extensions list. xlock just sees a single display with 2304x900 pixels on my system, which is actually 2 screens 1152x900 each. AFAIK there is no easy way to detect Xinemera modulo strange aspect ratios and the like (e.g. my display is suspicously wide, assuming I am using conventional display hardware). Recycled 1990 SUN monitors are conventional, albeit rather pickier about the video signal that one expects these days. I was thinking I could add -hdiv 2 and would xlock use half the display width, in my case 1152, as the width of an appropiate number of windows (2 for half width). One could think of a maximum window width, with the code generating an appropiate number of windows, for a similar effect. I image neither option would involve vast amounts of code or internal changes. Actually, on a more careful analysis Xinereama is listed in the extensions and in extensions/Xinerama.h I see the following functions Bool XineramaIsActive(Display *dpy); XineramaScreenInfo * XineramaQueryScreens( Display *dpy, int *number ); XinermaScreenInfo is a structure that contains screen number, x and y origin, width and height (one per head, judjing by the function prototype). The extension is not supported everywhere but feature test macros or autoconf should cope. Imake apparently includes #define XineramaDefines -DPANORAMIX if you have the support (and presumably this means you have the header too). My proposal would be less elegant. ~$ gcc -o xintest.^H ci^H^Hxintest.c -:^HL/usr/X11R6/lib -lX11 =^H-lXext -lXinerama ~$ ./xintest Xinerama supported: event base 0, error base 0 Xinerama active There are 2 heads Head 0: screen 0 size 1152x900 starting at 0,0 Head 1: screen 1 size 1152x900 starting at 1152,0 ~$ exit Script done on Sat Apr 15 19:25:46 2000 Which has interesting effects in ink blot mode (50% of the ink blot on each screen, not indeal). Modes dewsned for about 4x3 suffer quite badly from stretching pn 2304x900... hence my desire for a version aof xlockmore aware of the screen boundaries. #include #include #include int main(void) { Display *dpy; int xin, ev, err, i, nh; XineramaScreenInfo *scr; dpy=XOpenDisplay(""); xin=XineramaQueryExtension(dpy, &ev, &err); if (!xin) { printf("Xinerama not avialable\n"); XCloseDisplay(dpy); return 0; } printf ("Xinerama supported: event base %d, error base %d\n", ev, err); printf("Xinerama %sactive\n", XineramaIsActive(dpy) ? "" : "in"); if ((scr=XineramaQueryScreens(dpy, &nh))!=NULL) { printf("There are %d heads\n", nh); for (i=0; iscreen_number, (scr+i)->width, (scr+i)->height, (scr+i)->x_org, (scr+i)->y_org); } XFree(scr); } XCloseDisplay(dpy); return 0; } o modes from xscreensaver :) : bubbles, moire, LMorph, halo, ImsMap, BlitSpin Mode specific problems: ---------------------- Various modes need better refresh capability. Various modes need more mouse capability like worm. ant: round ants. This would involve masking and images to do efficiently. 3d version (up, down, left, right turns)? May be hard to see interior though. ball: can it be updated to use a pixmap instead of a slow circle fill? braid: should be made so that it can be interrupted quicker. bouboule: always starts at the bottom right bounce: sometimes a ball does not roll off another ball. momentum seems to be created. A -wall option, multiscreens should have balls bouncing between screens. -mode bounce -inroot may give BadWindow in X_GetWindowAttributes if run for a while, but the screen is not locked :) allow a background picture to be seen behind the bouncing football (soccer ball) in "bounce" mode. Thus a picture of your favorite team, etc. can be seen behind the bouncing balls. football version of "bounce" using a pigskin instead of a soccer ball for Americans/Canadians/etc. Different balls with different mass and size. bug: 3d version? Will triangular bugs evolve, if not, can they? flag: add an option for amplitude. ico: should have all the features of the original. triangular face objects do not look good when rotated. image: middle button should do something when called like "-bitmap ./bitmap/" hop: center and size many of the hops. life: -find option to find new lifeforms. (mail the results out :) also life3d). When the bitmap is big it is rejected. Probably could be handled better but if accepted then the screen could be blank because there are bitmaps that are off the screen. life3d: A densely packed spherical version on corners of a cuboctahedron (or rhombic dodecahedrons). lyapunov: needs to be speeded up marquee: "-messagefile filename" truncates a large file. "-message string" does not handle Control-H correctly. fallback font if screen is small... like bomb mountain: -size # for mountain should do something. noof: a cpu killer. Strip out OpenGL or increase the variablity like having the "flowers" skew with respect to the viewer. nose: should handle Control-H better for underlining and accents. fallback font if screen is small... like bomb pyro: needs XDrawSegments code similar to swarm to give it depth. slip: should be less jarring get rid of single color blotch. should be made so that it can be interrupted quicker. star: fractal cracks when hit by rocks (with sound?) user defined ships (user defined pixmaps like eyes and pacman). stars should look more star-like "*"'s combine space and star for a backwards and sideways motion swirl: needs to be refreshed quicker does not refresh well when colormap changes text3d: time stuff in text3d maybe dclock and marquee could be combined too? a separate -message3d for text3d voters and wator: neighbors option bug ... sometimes circles are not drawn in the correct spot. A -/+ wrap option would be nice also. wire: it needs a better circuit generator. xglock: Needs a lot of work. kscreensaver: port xlock to KDE. New mode ideas... (some may be very hard :) ): --------------------------------------------- o "bsdworm" BSD worm game with computer (and later mouse control), also have more than one worm o "dead" a Grateful Dead mode with dancing bears/skeletons/turtles. (Or maybe "nose" in a tie die?) o "floyd" a Pink Floyd mode from the cover of "Dark Side of the Moon" with a turning prism and rainbow effect. o "graph" a random planar graph drawn ... filled in by a 5 (or 4 :) ) coloring algorithm. o "mail" show that one has mail (can also be an option on flag, image, etc.) A spinning GL mailbox would be really cool. Note that the password screen can be setup to show if one has mail. o "minimal" a random minimal surface generator. o "pangea" a mode showing the changes to the earth's surface over millions of years. o "snow" mode with a nice Winter scene picture background and snowflakes falling o "soap" mode showing soap films o "squig" mode from squig/xsquig (xsquig is too slow) o "venus" mode showing the transformation of a Etruscan Venus to a Roman surface to a Boy surface to a Ida surface, back into a Etruscan Venus using GL. This is a 3D shadow of a 4D Klein Bottle (which in turn is a a 3D moebius strip). (Science News October 24, 1987 Vol 132, No 17.) o Simulations like sandpile avalanches or forest fires. (Science News July 15, 1989 Vol 136, No 3.) o A NT-like GL 3D Maze, where you are inside the maze o NT-like GL FlowerBox spring and Flying Objects o A GL 4D ico where the 6 4D "platonic" objects "roll" around in 3D space. o GL modes based on demos: isosurf, reflect, bounce, stex3d o KitCat (R) clock mode (based on X11 catclock, a version of xclock) where the cat clock floats around the screen like "dclock" mode does. Colors of cat clock could be picked like nose-guy in "nose" mode. o Lottery with bouncing numbered balls like PowerBall. o morph3d for rhombic dodecahedron and rhombic triacontahedron o A simple set of 2D geometric shapes that morph into one another whilst colour cycling. So say you start with a rectangle that morphs into a circle (leaving a small trail like Qix) that morphs into a triangle that morphs into a polygon that morphs into a rectangle, etc. All the while you have movement and colour cycling like Qix. If the trail is to large then things could become messy, but if too short then you loose the history element. o A simple bouncing ball on a chess board. The ball is a silver ray-traced/rendered globe. The chess board is a series of black and white squares. Each black square is gold veined marble with the gold glinting. Each white square is a textured surface (like little bumps, or ridges). The whole screen is lit from two light sources (either fixed or moving). As the ball bounces it reflects like a mirror what is around it. o A variant of the above would be to hold that ball still in the centre of the screen and move a randomly chosen bitmap around the ball. o The above could also have embossed on standout lettering added (say a single word like Linux). The lettering could either be stationary or float around the ball in orbit a bit like the the Universal studios logo where the Universal name revolves around a picture of the earth. o Take pipes and add the constantly moving view point that you get with rock so the mass of pipes seems to revolve and rotate around a moving point in space. o Make the little man in Nose seem to carve the letters of the message into rock, or paint them on the screen. o Make marquee use 3D extruded text that can be texture mapped and seem to zoom into and out of the screen with the zoom source point drifting around the screen at random o Make puzzle take the present desktop image, invert it and shuffle the pieces then put the whole things back. Once it has reassembled the desktop you could have the image flip top over bottom as it reseeds into the screen, only to have a new randomly shuffled version of the desktop flip back out. o Use the spheres generated in sphere to draw molecules on the screen, colour coding for the various types of atom present. A limit on the size of each sphere would be needed. The spheres could be joined by simple white lines. If you are feeling adventurous you could make it seem to rotate in space so all parts of the molecule could be seen. o In shape change things so that the shapes appear to be extruded from a random point on the screen. You could also have a number of shapes be extruded, each from its own origin, only to shrink back into the screen again. Each time a shape shrinks back into the screen the origin would move and a new shape would be chosen. o When the screensaver is started have curtains drawn across the desktop at a medium pace, a second or twos pause then the curtain a pulled open quickly to reveal a bitmaped image in place of the desktop. This cycles with a different image each time. o In pyro have the fireworks appear to zoom from a randomly choose point on the screen. This would give the effect of the display being seen from above. o In decay mode, have a Blue Screen of Death option. PLEASE NOTE: ----------- I _REALLY_ hate to turn down contributions... I will try to consider all submissions. Some things on new modes that bother me are: Did not black out the screen when they start. I do not like people to see what I am doing. :^| (This could be a non-default option... see decay mode). Did not work in the little window or buggy. (I usually try to clean it up). Is too similar mode to a mode that already exists. (Maybe an option could be added on an existing mode?). Many people complained about the mode. Just not enough randomness or is not interesting enough. No multiscreen support (I usually try to clean this up too). But I labor over them (in a haphazard fashion) and they usually are released eventually. (If they are in assembler I would definitely need a working example and all the binaries and libraries to get it to run.)