github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #182] Power management on Linux client is inhibited #147

New issue

Open

opened 2026-05-05 05:23:22 -06:00 by gitea-mirror · 10 comments

gitea-mirror commented

2026-05-05 05:23:22 -06:00

Owner

Originally created by @fagg on GitHub (Nov 26, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/182

Operating Systems

Server: Arch Linux

Client: Arch Linux

Barrier Version

2.1.0 RELEASE

Steps to reproduce bug

Power management on server works fine (screen goes to sleep when inactive). On the client, however, the screen does not turn off while Barrier is running.

Power settings (with Barrier running):

Keyboard Control:
  auto repeat:  on    key click percent:  0    LED mask:  00000000
  XKB indicators:
    00: Caps Lock:   off    01: Num Lock:    off    02: Scroll Lock: off
    03: Compose:     off    04: Kana:        off    05: Sleep:       off
    06: Suspend:     off    07: Mute:        off    08: Misc:        off
    09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
    12: Group 2:     off    13: Mouse Keys:  off
  auto repeat delay:  660    repeat rate:  25
  auto repeating keys:  00ffffffdffffbbf
                        fadfffefffedffff
                        9fffffffffffffff
                        fff7ffffffffffff
  bell percent:  50    bell pitch:  400    bell duration:  100
Pointer Control:
  acceleration:  2/1    threshold:  4
Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  0    cycle:  600
Colors:
  default colormap:  0x22    BlackPixel:  0x0    WhitePixel:  0xffffff
Font Path:
  /usr/share/fonts/misc,/usr/share/fonts/TTF,built-ins
DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Disabled

Without Barrier running:

Keyboard Control:
  auto repeat:  on    key click percent:  0    LED mask:  00000000
  XKB indicators:
    00: Caps Lock:   off    01: Num Lock:    off    02: Scroll Lock: off
    03: Compose:     off    04: Kana:        off    05: Sleep:       off
    06: Suspend:     off    07: Mute:        off    08: Misc:        off
    09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
    12: Group 2:     off    13: Mouse Keys:  off
  auto repeat delay:  660    repeat rate:  25
  auto repeating keys:  00ffffffdffffbbf
                        fadfffefffedffff
                        9fffffffffffffff
                        fff7ffffffffffff
  bell percent:  50    bell pitch:  400    bell duration:  100
Pointer Control:
  acceleration:  2/1    threshold:  4
Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  600    cycle:  600
Colors:
  default colormap:  0x22    BlackPixel:  0x0    WhitePixel:  0xffffff
Font Path:
  /usr/share/fonts/misc,/usr/share/fonts/TTF,built-ins
DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Enabled
  Monitor is On

If it helps, the client is a laptop (Thinkpad X270), server is a desktop. Closing the lid on the laptop with Barrier running still makes it go to sleep (ala systemctl suspend).

I'd expect that the screen power settings on the client obey the local settings, and be woken up when there is input from the server's keyboard/mouse.

Other info

When did the problem start to occur? Has always happened
Is there a way to work around it? Can't find one
Does this bug prevent you from using Barrier entirely? No

Originally created by @fagg on GitHub (Nov 26, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/182 ### Operating Systems ### Server: Arch Linux Client: Arch Linux ### Barrier Version ### 2.1.0 RELEASE ### Steps to reproduce bug ### Power management on server works fine (screen goes to sleep when inactive). On the client, however, the screen does not turn off while Barrier is running. Power settings (with Barrier running): ```[fagg@mercury][~][0] -> xset q Keyboard Control: auto repeat: on key click percent: 0 LED mask: 00000000 XKB indicators: 00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off 03: Compose: off 04: Kana: off 05: Sleep: off 06: Suspend: off 07: Mute: off 08: Misc: off 09: Mail: off 10: Charging: off 11: Shift Lock: off 12: Group 2: off 13: Mouse Keys: off auto repeat delay: 660 repeat rate: 25 auto repeating keys: 00ffffffdffffbbf fadfffefffedffff 9fffffffffffffff fff7ffffffffffff bell percent: 50 bell pitch: 400 bell duration: 100 Pointer Control: acceleration: 2/1 threshold: 4 Screen Saver: prefer blanking: yes allow exposures: yes timeout: 0 cycle: 600 Colors: default colormap: 0x22 BlackPixel: 0x0 WhitePixel: 0xffffff Font Path: /usr/share/fonts/misc,/usr/share/fonts/TTF,built-ins DPMS (Energy Star): Standby: 600 Suspend: 600 Off: 600 DPMS is Disabled ``` Without Barrier running: ```[fagg@mercury][~][0] -> xset q Keyboard Control: auto repeat: on key click percent: 0 LED mask: 00000000 XKB indicators: 00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off 03: Compose: off 04: Kana: off 05: Sleep: off 06: Suspend: off 07: Mute: off 08: Misc: off 09: Mail: off 10: Charging: off 11: Shift Lock: off 12: Group 2: off 13: Mouse Keys: off auto repeat delay: 660 repeat rate: 25 auto repeating keys: 00ffffffdffffbbf fadfffefffedffff 9fffffffffffffff fff7ffffffffffff bell percent: 50 bell pitch: 400 bell duration: 100 Pointer Control: acceleration: 2/1 threshold: 4 Screen Saver: prefer blanking: yes allow exposures: yes timeout: 600 cycle: 600 Colors: default colormap: 0x22 BlackPixel: 0x0 WhitePixel: 0xffffff Font Path: /usr/share/fonts/misc,/usr/share/fonts/TTF,built-ins DPMS (Energy Star): Standby: 600 Suspend: 600 Off: 600 DPMS is Enabled Monitor is On ``` If it helps, the client is a laptop (Thinkpad X270), server is a desktop. Closing the lid on the laptop with Barrier running still makes it go to sleep (ala systemctl suspend). I'd expect that the screen power settings on the client obey the local settings, and be woken up when there is input from the server's keyboard/mouse. ### Other info ### * When did the problem start to occur? Has always happened * Is there a way to work around it? Can't find one * Does this bug prevent you from using Barrier entirely? No

gitea-mirror added the

labels 2026-05-05 05:23:22 -06:00

gitea-mirror commented

2026-05-05 05:23:26 -06:00

Author

Owner

@a7hybnj2 commented on GitHub (Nov 28, 2018):

I am experiencing this same issue. Windows 8.1 as server and Arch Linux as client.

@a7hybnj2 commented on GitHub (Nov 28, 2018): I am experiencing this same issue. Windows 8.1 as server and Arch Linux as client.

gitea-mirror commented

2026-05-05 05:23:28 -06:00

Author

Owner

@edalongeville commented on GitHub (Dec 3, 2018):

Me too with a windows 10 server and an Ubuntu 18.04 client.

@edalongeville commented on GitHub (Dec 3, 2018): Me too with a windows 10 server and an Ubuntu 18.04 client.

gitea-mirror commented

2026-05-05 05:23:31 -06:00

Author

Owner

@patrickli commented on GitHub (Mar 16, 2019):

Same problem. MacOS server and Windows 10 client.

@patrickli commented on GitHub (Mar 16, 2019): Same problem. MacOS server and Windows 10 client.

gitea-mirror commented

2026-05-05 05:23:32 -06:00

Author

Owner

@patrickli commented on GitHub (May 22, 2019):

Some details.

C:\WINDOWS\system32>powercfg -requests
DISPLAY:
[PROCESS] \Device\HarddiskVolume9\Program Files\Barrier\barrierc.exe

SYSTEM:
[PROCESS] \Device\HarddiskVolume9\Program Files\Barrier\barrierc.exe

AWAYMODE:
None.

EXECUTION:
None.

PERFBOOST:
None.

ACTIVELOCKSCREEN:
None.

@patrickli commented on GitHub (May 22, 2019): Some details. ``` C:\WINDOWS\system32>powercfg -requests DISPLAY: [PROCESS] \Device\HarddiskVolume9\Program Files\Barrier\barrierc.exe SYSTEM: [PROCESS] \Device\HarddiskVolume9\Program Files\Barrier\barrierc.exe AWAYMODE: None. EXECUTION: None. PERFBOOST: None. ACTIVELOCKSCREEN: None. ```

gitea-mirror commented

2026-05-05 05:23:34 -06:00

Author

Owner

@noisyshape commented on GitHub (May 22, 2019):

The server has an option called 'Synchronize screen savers'. Does this happen with that option disabled?

@noisyshape commented on GitHub (May 22, 2019): The server has an option called 'Synchronize screen savers'. Does this happen with that option disabled?

gitea-mirror commented

2026-05-05 05:23:36 -06:00

Author

Owner

@patrickli commented on GitHub (May 22, 2019):

The server has an option called 'Synchronize screen savers'. Does this happen with that option disabled?

I tried that and it removed the DISPLAY requests. The SYSTEM still exists. I tried to disable drag and drop and clipboard sharing but these doesn't make any difference.

@patrickli commented on GitHub (May 22, 2019): > The server has an option called 'Synchronize screen savers'. Does this happen with that option disabled? I tried that and it removed the `DISPLAY` requests. The `SYSTEM` still exists. I tried to disable drag and drop and clipboard sharing but these doesn't make any difference.

gitea-mirror commented

2026-05-05 05:23:37 -06:00

Author

Owner

@xorander00 commented on GitHub (May 23, 2019):

Same here. I disabled the "Synchronize screen savers" option & restarted Barrier on both the server & client. Upon launch, it disabled DPMS again. However, after after re-enabling DPMS, the setting seems to be sticking this time around.

@xorander00 commented on GitHub (May 23, 2019): Same here. I disabled the "Synchronize screen savers" option & restarted Barrier on both the server & client. Upon launch, it disabled DPMS again. However, after after re-enabling DPMS, the setting seems to be sticking this time around.

gitea-mirror commented

2026-05-05 05:23:38 -06:00

Author

Owner

@zeorin commented on GitHub (Sep 15, 2020):

Still an issue for me. Linux server and client.

@zeorin commented on GitHub (Sep 15, 2020): Still an issue for me. Linux server and client.

gitea-mirror commented

2026-05-05 05:23:40 -06:00

Author

Owner

@zeorin commented on GitHub (Sep 17, 2020):

Scratch that, I didn't realize that "Synchronize screen savers" was ticked by default. When I unticked it, the client now has DPMS enabled when barrier is running.

@zeorin commented on GitHub (Sep 17, 2020): Scratch that, I didn't realize that "Synchronize screen savers" was ticked by default. When I unticked it, the client now has DPMS enabled when barrier is running.

gitea-mirror commented

2026-05-05 05:23:42 -06:00

Author

Owner

@moseschanx commented on GitHub (May 24, 2022):

My solution for this on windows is :
powercfg -requestsoverride process barrierc.exe system display
on Linux ( manually set timeout for screen saver ) :
xset +dpms s <yourtimeout> <cycles>
though DPMS will still be triggered off when barrier interacts with your desktop, this will make your monitor auto blank again.

@moseschanx commented on GitHub (May 24, 2022): My solution for this on windows is : `powercfg -requestsoverride process barrierc.exe system display` on Linux ( manually set timeout for screen saver ) : `xset +dpms s <yourtimeout> <cycles>` though DPMS will still be triggered off when barrier interacts with your desktop, this will make your monitor auto blank again.

gitea-mirror referenced this issue

2026-05-05 06:00:25 -06:00

[GH-ISSUE #395] High memory usage over time. - memory leak #312