#Xscreensaver how to#
#Xscreensaver android#
#Xscreensaver software#

In particular, it does not link against GUI frameworks like GTK or KDE, but uses only raw Xlib for rendering the unlock dialog box. In addition to sandboxing the display modes, the XScreenSaver daemon links with as few libraries as possible. And to allow the X11-based hacks to run natively on iOS and Android, XScreenSaver also contains an implementation of the X11 API in terms of OpenGL ES 1.0.

#Xscreensaver android#

To allow the OpenGL 1.3-based hacks to run natively on iOS and Android systems, which only support OpenGL ES, XScreenSaver contains an implementation of the OpenGL 1.3 API built in top of OpenGL ES 1.0 ('jwzgles').

To allow the X11-based hacks to run natively on macOS and iOS, XScreenSaver contains a complete implementation of the X11 API built on top of Cocoa ('jwxyz').

Rather than forking the code-base and re-writing the hacks to target different platforms, XScreenSaver contains a number of compatibility layers. About half of them use the X11 API, and about half use the OpenGL 1.3 API. It also means that a third-party screen saver can be written in any language or with any graphics library, so long as it is capable of rendering onto an externally provided window.įor historical and portability reasons, the included hacks are all written in ANSI C. This means that a programming error in one of the graphical display modes cannot compromise the screen locker itself (e.g., a crash in a display mode will not unlock the screen). This is an important security feature, in that the display modes are sandboxed into a separate process from the screen locking framework. The display modes (termed 'hacks' from the historical usage ' display hack') are each stand-alone programs. The XScreenSaver daemon is responsible for detecting idle-ness, blanking and locking the screen, and launching the display modes. The author considers Microsoft to be 'a company with vicious, predatory, anti-competitive business practices' Īnd says that, as one of the original authors of Netscape Navigator, he holds a 'personal grudge' against Microsoft because of its behavior during the First Browser War. There is no official version for Microsoft Windows, and the developer discourages anyone from porting it.

On Android systems, the XScreenSaver display modes work either as normal screen savers (which Android sometimes refers to as 'Daydreams') or as live wallpapers. On iOS systems, XScreenSaver is a stand-alone app that can run any of the hacks full-screen. On Macintosh systems, XScreenSaver works with the built-in macOS screen saver. On those systems, there are several packages: one for the screen-saving and locking framework, and two or more for the display modes, divided somewhat arbitrarily.

#Xscreensaver software#

maybe just delete the binary from /usr/lib/xscreensaver? Finally, why in the world does the server distribution ship with a screen saver that is well known to overload the CPU? Maybe everyone expects a server to never run a GUI.The free software and open-source Unix-like operating systems running the X Window System (such as Linux and FreeBSD) use XScreenSaver almost exclusively.

#Xscreensaver how to#

Also, none of the doc's talk about how to uninstall a screen saver. Some of the others also cause CPU load, but not nearly as bad as m6502. Individual users can still defy this and have their own preferences, but the default system behavior is the blank screen.Īs a side-note, m6502 is the absolute worst in causing CPU load of all the screen savers in the distro.

Now, XScreenSaver is set to produce a blank screen (meaning 0 CPU load). Then, restart the window server or reboot the system. After some research, I came across a simple solution that worked for me:Įdit this file: /etc/X11/Xresources/x11-common None addressed how to change this globally, which would be appropriate for a server setting. Previous posts resolved the issue by having the user manually change the screen saver preferences in the GUI. I also came across previous posts, noting that XScreenSaver has been causing high CPU loads for nearly a decade. So, sometimes you just get lucky and get the one that consumes your entire system. Apparently, the default behavior for XScreenSaver is to randomly pick from the installed screen savers and change every 10 min.

Researching on 'm6502,' I found it is part of the standard XScreenSaver distribution. some quick research pointed me to a process called 'm6502' that was running in multiple iterations (one per CPU core) and that was solely responsible for the excessive load. The new server I had just setup was nearly brought down to its knees with CPU utilization above 50% across all cores! But, I just barely installed lubuntu 16.04 server-I wasn't running anything yet.