summaryrefslogtreecommitdiffhomepage
path: root/src/Plugins/Locks.hs
AgeCommit message (Collapse)Author
2018-11-21Split Modules into Library & Executable StructurePavan Rikhi
Move the Main module to a new `app` directory. All other modules have been nested under the `Xmobar` name. Lots of module headers & imports were updated.
2014-09-16Locks: Implement event-driven locks indicatorAnton Vorontsov
This commit does more fundamental rework of the "Locks" plug-in: now the plug-in is fully event-driven and thus extremely power-efficient, effectively zero CPU consumption while idling.
2014-09-16Locks: Rework to avoid unnecessary display reopeningAnton Vorontsov
The extremely useful "Locks" plugin eats quite a lot of CPU (>2% here on a old-ish laptop), unfortunately. The plug-in unnecessary reopens the display, which is quite expensive operation. It results into 16 syscalls: socket(PF_LOCAL) -> connect(sun_path=@"/tmp/.X11-unix/X0"}) -> getpeername() -> uname() -> access(".Xauthority") -> open(".Xauthority") -> fstat() -> mmap() -> read() -> close() -> munmap() -> getsockname() -> fcntl(F_SETFD) -> fcntl(F_SETFL) -> shutdown() -> close() This is almost half of all the syscalls that we ought to execute for the plug-in to work. Now, considering the useful work and that "Locks" runs every 200 milliseconds, it gives us >300 syscalls (and a lot more wake-ups) per second. This commit fixes the reopening issue, effectively halving the CPU consumption (down to ~1%). The patch also makes it easier to implement event-driven indicators that will reduce the idle CPU consumption to 0.
2012-09-27WhitespaceJose Antonio Ortega Ruiz
2012-09-25Added keyboard lock status command.Patrick Chilton