#Xscreensaver android code#

The new one contains 12.5k lines across three different executables - a 14% reduction overall.

#Xscreensaver android code#

The old XScreenSaver daemon contained 14.5k lines of code in a single executable. Exit code indicates success or failure, so if it crashes, that has the same behavior as 'incorrect password'.Draws the unlock dialog, and talks to PAM.Launched by xscreensaver to authenticate the user.If it crashes, the desktop will momentarily be visible, but the keyboard and mouse will remain grabbed and the screen will remain locked.Handles monitor reconfiguration, fading, visuals, etc.Launches the screenhacks as sub-processes.Launched by xscreensaver to blank the screen.Handles grabs, idle detection, and client messages.Requires the XInput2 extension, standard since X11R7 in 2005.So I stepped back and took a fresh look at the whole thing from the perspective of, 'what needs to be here?' In addition, dropping support for X11 systems more than fifteen years old - an eminently reasonable thing to do - allowed me to simplify the flow of control a lot. Remember that XScreenSaver predates not only HDMI, but USB! I wrote the first version on a 1-bit monochrome display.

Especially as compared to its putative ' competition'.īut, it still contains quite a lot of code, and keeping up with new operating system features like hot-swapping of monitors, new ways of detecting user activity and so on, has caused more and more code to creep into it.

This approach has worked out very well XScreenSaver has had an excellent security track record over these last three decades. My approach with XScreenSaver, as I've written about extensively, has always been to minimize the amount of code in the critical section: to link with as few libraries as possible, and to sandbox as much of the rest as possible in separate processes. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.