cookiengineer/barrier-disable-dpms

:gun: Force barrierc via LD_PRELOAD to disable all DPMS and XSet calls

0

stars

1

commits

C

primary language

Mar 18, 2026

updated

README

How to Disable Barrier Client DPMS and XSetScreenSaver API calls

The problem with barrierc is that it messes up my DPMS config and my screensaver settings.

Motivation

I am using i3 and a separate autostart.conf file to use the exec --no-startup-id calls to have autostart functionality which starts all programs after I've been logged in. In order to prevent my monitors from blanking out or powering off when I'm not active or watching a video, I'm specifically disabling DPMS and the screensaver via xset.

# disable all dpms settings
exec --no-startup-id xset dpms 0 0 0
exec --no-startup-id xset -dpms

# screensaver after 15 minutes
exec --no-startup-id xset s 900 900

# disable screensaver
exec --no-startup-id xset s off

The Problem

However, Barrier as a program is too stupid to realize that when I move my mouse on my host system that I actually want to continue to use my other system's connected monitors without them flickering every couple minutes like a damn epilepsy inducing art installation.

Tracing xset calls

I was almost losing my mind trying to figure out where the xset calls come from. I've built a little helper program for that in the tracer folder.

Usage of that program is simple, for example to intercept xset binary execution calls:

  • Rename the original /usr/bin/xset to /usr/bin/xset.real
  • Copy the built /tracer/main to /usr/bin/xset
  • Use watch cat /tmp/xset.log to get parent and process info

Turns out, xset was not called from anywhere, and I uninstalled pretty much all other programs and packages. I even created dummy packages to not break dependencies for xscreensaver and all.

The culprit, however, was barrierc executing the calls directly via the X11 API instead of relying on xset for that:

> strings /usr/bin/barrierc | grep XSet
XSetIOErrorHandler
XSetErrorHandler
XSetInputFocus
XSetICFocus
XSetScreenSaver
XSetSelectionOwner

> strings /usr/bin/barrierc | grep DPMS
DPMSQueryExtension
DPMSCapable
DPMSInfo
DPMSForceLevel
DPMSEnable
DPMSDisable

Stubbing DPMS and XSet Function Calls

Remember the old CVE-2009-0641 that showed a technique to implement privilege escalation for binaries that don't drop their rights directly to nobody after they've done something via setuid(0)?

Well, that technique allows to override pretty much all shared library symbols. And that's what we're going to do, so that barrierc only does nothing when it tries to mess with our DPMS and Screen Saver settings.

x11hooks.so Function Call Blocker

So our little hook.c library does nothing more than to return the expected signature, and to do nothing, essentially stubbing the API.

For example, the XSetScreenSaver() method in there looks like this:

int XSetScreenSaver(Display *dpy, int timeout, int interval, int prefer_blanking, int allow_exposures) {
    log_call("XSetScreenSaver (BLOCKED)");
    return 0;
}

SystemD Usage

The install.sh shows how to install the x11hooks.so as /usr/lib/barrier/barrierc-disable-dpms.so. This way we have a global path to use that in our systemd service file for barrierc:

> cat ~/.config/systemd/user/default.target.wants/barrier-client.service
[Unit]
Description=Barrier Client
After=network.target

[Service]
# Override shitty program using shitty hacks
Environment=LD_PRELOAD=/usr/lib/barrier/barrierc-disable-dpms.so

# ExecStartPre=/usr/bin/sleep 5
ExecStart=/usr/bin/barrierc --no-daemon ryzzy
ExecStartPre=/usr/bin/echo "" > /dev/tcp/192.168.0.12/24800
Restart=always
RestartSec=10

[Install]
WantedBy=default.target

License

WTFPL

Contributors

cookiengineer

1 commits

cookiengineer/barrier-disable-dpms

:gun: Force barrierc via LD_PRELOAD to disable all DPMS and XSet calls

0

stars

1

commits

C

primary language

Mar 18, 2026

updated

README

How to Disable Barrier Client DPMS and XSetScreenSaver API calls

The problem with barrierc is that it messes up my DPMS config and my screensaver settings.

Motivation

I am using i3 and a separate autostart.conf file to use the exec --no-startup-id calls to have autostart functionality which starts all programs after I've been logged in. In order to prevent my monitors from blanking out or powering off when I'm not active or watching a video, I'm specifically disabling DPMS and the screensaver via xset.

# disable all dpms settings
exec --no-startup-id xset dpms 0 0 0
exec --no-startup-id xset -dpms

# screensaver after 15 minutes
exec --no-startup-id xset s 900 900

# disable screensaver
exec --no-startup-id xset s off

The Problem

However, Barrier as a program is too stupid to realize that when I move my mouse on my host system that I actually want to continue to use my other system's connected monitors without them flickering every couple minutes like a damn epilepsy inducing art installation.

Tracing xset calls

I was almost losing my mind trying to figure out where the xset calls come from. I've built a little helper program for that in the tracer folder.

Usage of that program is simple, for example to intercept xset binary execution calls:

  • Rename the original /usr/bin/xset to /usr/bin/xset.real
  • Copy the built /tracer/main to /usr/bin/xset
  • Use watch cat /tmp/xset.log to get parent and process info

Turns out, xset was not called from anywhere, and I uninstalled pretty much all other programs and packages. I even created dummy packages to not break dependencies for xscreensaver and all.

The culprit, however, was barrierc executing the calls directly via the X11 API instead of relying on xset for that:

> strings /usr/bin/barrierc | grep XSet
XSetIOErrorHandler
XSetErrorHandler
XSetInputFocus
XSetICFocus
XSetScreenSaver
XSetSelectionOwner

> strings /usr/bin/barrierc | grep DPMS
DPMSQueryExtension
DPMSCapable
DPMSInfo
DPMSForceLevel
DPMSEnable
DPMSDisable

Stubbing DPMS and XSet Function Calls

Remember the old CVE-2009-0641 that showed a technique to implement privilege escalation for binaries that don't drop their rights directly to nobody after they've done something via setuid(0)?

Well, that technique allows to override pretty much all shared library symbols. And that's what we're going to do, so that barrierc only does nothing when it tries to mess with our DPMS and Screen Saver settings.

x11hooks.so Function Call Blocker

So our little hook.c library does nothing more than to return the expected signature, and to do nothing, essentially stubbing the API.

For example, the XSetScreenSaver() method in there looks like this:

int XSetScreenSaver(Display *dpy, int timeout, int interval, int prefer_blanking, int allow_exposures) {
    log_call("XSetScreenSaver (BLOCKED)");
    return 0;
}

SystemD Usage

The install.sh shows how to install the x11hooks.so as /usr/lib/barrier/barrierc-disable-dpms.so. This way we have a global path to use that in our systemd service file for barrierc:

> cat ~/.config/systemd/user/default.target.wants/barrier-client.service
[Unit]
Description=Barrier Client
After=network.target

[Service]
# Override shitty program using shitty hacks
Environment=LD_PRELOAD=/usr/lib/barrier/barrierc-disable-dpms.so

# ExecStartPre=/usr/bin/sleep 5
ExecStart=/usr/bin/barrierc --no-daemon ryzzy
ExecStartPre=/usr/bin/echo "" > /dev/tcp/192.168.0.12/24800
Restart=always
RestartSec=10

[Install]
WantedBy=default.target

License

WTFPL

Contributors

cookiengineer

1 commits

Languages

C

55.6%

Go

30.4%

Shell

13.9%