github-starred/barrier

Fork 0

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

[GH-ISSUE #867] Flashing/Blanking on raspberrypi #689

New issue

Open

opened 2026-05-05 06:56:43 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 06:56:43 -06:00

Owner

Originally created by @joshuacox on GitHub (Sep 7, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/867

Describe the bug
As I move the cursor back and forth from my desktop to the pi the pi's screen will flash a blank (black) screen for a second. Eventually it will fail to recover from this and sit blankly forever. The odd thing is that if I ssh into the pi everything appears to be running normally, I can even restart gdm (systemctl restart gdm) but the screen stays blank. Eventually I will give up and reboot the pi, at this point it will eject me from the ssh session, but it will freeze for several minutes (enough that early on I would pull the power from the pi and plug it back in), but eventually it will reboot. Uncertain as to what it's doing at this point as I can't ssh in and the screen is still blank.

To Reproduce

Steps to reproduce the behavior:
This one is inconsisten so replicating is not guaranteed, move your mouse back and forth between desktops, doing a circle between the desktops and just continuously jumping back and forth does not seem to trigger this, there needs to be a delay between jumps.

Expected behavior
Normal no-flashes barrier usage.

Screenshots
Blank screenshot.

Desktop (please complete the following information):

OS: Arch Linux on both server and client
Barrier version 2.3.3-release

Originally created by @joshuacox on GitHub (Sep 7, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/867 **Describe the bug** As I move the cursor back and forth from my desktop to the pi the pi's screen will flash a blank (black) screen for a second. Eventually it will fail to recover from this and sit blankly forever. The odd thing is that if I ssh into the pi everything appears to be running normally, I can even restart gdm (systemctl restart gdm) but the screen stays blank. Eventually I will give up and reboot the pi, at this point it will eject me from the ssh session, but it will freeze for several minutes (enough that early on I would pull the power from the pi and plug it back in), but eventually it will reboot. Uncertain as to what it's doing at this point as I can't ssh in and the screen is still blank. **To Reproduce** Steps to reproduce the behavior: This one is inconsisten so replicating is not guaranteed, move your mouse back and forth between desktops, doing a circle between the desktops and just continuously jumping back and forth does not seem to trigger this, there needs to be a delay between jumps. **Expected behavior** Normal no-flashes barrier usage. **Screenshots** Blank screenshot. **Desktop (please complete the following information):** - OS: Arch Linux on both server and client - Barrier version 2.3.3-release

gitea-mirror commented

2026-05-05 06:56:46 -06:00

Author

Owner

@shymega commented on GitHub (Sep 7, 2020):

Can you check memory usage before the reboot? Wondering if its related to the oom killer.

@shymega commented on GitHub (Sep 7, 2020): Can you check memory usage before the reboot? Wondering if its related to the oom killer.

gitea-mirror commented

2026-05-05 06:56:48 -06:00

Author

Owner

@joshuacox commented on GitHub (Sep 7, 2020):

Of note this is an rpi4 with 4GB of ram, and at time of reboot over 2GB of ram available:

quattro :: ~ % free -m                                                                                                                                                                                                                       
              total        used        free      shared  buff/cache   available
Mem:           3647         389        2199         527        1058        2689
Swap:             0           0           0

EDIT: adding in /boot/config.txt in which I changed gpu_mem to 256 in my attempts to give the video driver some more memory:

# See /boot/overlays/README for all available options

gpu_mem=256

initramfs initramfs-linux.img followkernel

# uncomment to force a console size. By default it will be display's size minus
# overscan.
framebuffer_width=1920
framebuffer_height=1080
disable_overscan=1
dtoverlay=vc4-kms-v3d-pi4

barrier is being automatically started like so:

quattro :: ~ % cat .xprofile                                                                                                                                                                                                                 
#!/bin/sh
touch /tmp/xprofile_started
date -I > /tmp/xprofile_started
barrierc --log /tmp/barrierc.log --daemon --enable-crypto flux

Of note the log file is not ever created in /tmp, maybe this is because barrier has nothing to log? (adding the --debug flag to see if that helps)

@joshuacox commented on GitHub (Sep 7, 2020): Of note this is an rpi4 with 4GB of ram, and at time of reboot over 2GB of ram available: ``` quattro :: ~ % free -m total used free shared buff/cache available Mem: 3647 389 2199 527 1058 2689 Swap: 0 0 0 ``` EDIT: adding in `/boot/config.txt` in which I changed gpu_mem to 256 in my attempts to give the video driver some more memory: ``` # See /boot/overlays/README for all available options gpu_mem=256 initramfs initramfs-linux.img followkernel # uncomment to force a console size. By default it will be display's size minus # overscan. framebuffer_width=1920 framebuffer_height=1080 disable_overscan=1 dtoverlay=vc4-kms-v3d-pi4 ``` barrier is being automatically started like so: ``` quattro :: ~ % cat .xprofile #!/bin/sh touch /tmp/xprofile_started date -I > /tmp/xprofile_started barrierc --log /tmp/barrierc.log --daemon --enable-crypto flux ``` Of note the log file is not ever created in `/tmp`, maybe this is because barrier has nothing to log? (adding the --debug flag to see if that helps)

gitea-mirror commented

2026-05-05 06:56:50 -06:00

Author

Owner

@joshuacox commented on GitHub (Sep 7, 2020):

@shymega after not getting any results in my logs I changed the debug level to DEBUG2

barrierc --debug DEBUG2 --log /tmp/barrierc.log --daemon --enable-crypto flux 1>/tmp/barrierc1.log 2>/tmp/barrierc2.err

Here are what those files look like after triggering a frozen blank screen state:

~ » tail -f /tmp/barrierc*
==> /tmp/barrierc1.log <==
[2020-09-07T10:44:30] DEBUG1: logging to file (/tmp/barrierc.log) enabled

==> /tmp/barrierc2.err <==

==> /tmp/barrierc.log <==
[2020-09-07T10:44:30] DEBUG1: logging to file (/tmp/barrierc.log) enabled

still plenty of RAM available (and this was taken during one of the frozen to blank screen states)

free -m
              total        used        free      shared  buff/cache   available
Mem:           3647         298        2485         399         863        2908
Swap:             0           0           0

gdm appears to be fine:

sudo systemctl status gdm                                                                                                    1 ↵
● gdm.service - GNOME Display Manager
     Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2020-09-07 10:44:04 CDT; 5min ago
   Main PID: 311 (gdm)
      Tasks: 3 (limit: 4915)
     CGroup: /system.slice/gdm.service
             └─311 /usr/bin/gdm

Sep 07 10:44:04 quattro systemd[1]: Starting GNOME Display Manager...
Sep 07 10:44:04 quattro systemd[1]: Started GNOME Display Manager.
Sep 07 10:44:04 quattro gdm-autologin][335]: pam_systemd_home(gdm-autologin:account): systemd-homed is not available: Unit dbus-org.freedesktop.ho>
Sep 07 10:44:04 quattro gdm-autologin][335]: pam_unix(gdm-autologin:session): session opened for user thoth(uid=1001) by (uid=0)

And restarting gdm has no effect.

Looking around in htop gnome-shell is using 10.6% of ram which seems about right, and nothing else is taking up much CPU or memory. I have also tried this with other window managers, including i3 which is quite minimal, to the same results.

@joshuacox commented on GitHub (Sep 7, 2020): @shymega after not getting any results in my logs I changed the debug level to DEBUG2 ``` barrierc --debug DEBUG2 --log /tmp/barrierc.log --daemon --enable-crypto flux 1>/tmp/barrierc1.log 2>/tmp/barrierc2.err ``` Here are what those files look like after triggering a frozen blank screen state: ``` ~ » tail -f /tmp/barrierc* ==> /tmp/barrierc1.log <== [2020-09-07T10:44:30] DEBUG1: logging to file (/tmp/barrierc.log) enabled ==> /tmp/barrierc2.err <== ==> /tmp/barrierc.log <== [2020-09-07T10:44:30] DEBUG1: logging to file (/tmp/barrierc.log) enabled ``` still plenty of RAM available (and this was taken during one of the frozen to blank screen states) ``` free -m total used free shared buff/cache available Mem: 3647 298 2485 399 863 2908 Swap: 0 0 0 ``` gdm appears to be fine: ``` sudo systemctl status gdm 1 ↵ ● gdm.service - GNOME Display Manager Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2020-09-07 10:44:04 CDT; 5min ago Main PID: 311 (gdm) Tasks: 3 (limit: 4915) CGroup: /system.slice/gdm.service └─311 /usr/bin/gdm Sep 07 10:44:04 quattro systemd[1]: Starting GNOME Display Manager... Sep 07 10:44:04 quattro systemd[1]: Started GNOME Display Manager. Sep 07 10:44:04 quattro gdm-autologin][335]: pam_systemd_home(gdm-autologin:account): systemd-homed is not available: Unit dbus-org.freedesktop.ho> Sep 07 10:44:04 quattro gdm-autologin][335]: pam_unix(gdm-autologin:session): session opened for user thoth(uid=1001) by (uid=0) ``` And restarting gdm has no effect. Looking around in htop gnome-shell is using 10.6% of ram which seems about right, and nothing else is taking up much CPU or memory. I have also tried this with other window managers, including i3 which is quite minimal, to the same results.

gitea-mirror commented

2026-05-05 06:56:53 -06:00

Author

Owner

@tsanyqudsi commented on GitHub (Aug 4, 2021):

@joshuacox i don't know if you still having this problem. But I have this problem too.

I "fixed" it with overclocking my Raspberry Pi 4 8GB. You might want to read https://qengineering.eu/overclocking-the-raspberry-pi-4.html for the explanation.

I use arm_freq = 1750 and over_voltage = 2 for my Raspi but 1650 / 1700 seems tolerable.

Please keep in mind that the temperature would be increasing due to overclocking. My Raspi temp rose from 37-38 C to 42-43 C on idle using Argon case.

@tsanyqudsi commented on GitHub (Aug 4, 2021): @joshuacox i don't know if you still having this problem. But I have this problem too. I "fixed" it with overclocking my Raspberry Pi 4 8GB. You might want to read https://qengineering.eu/overclocking-the-raspberry-pi-4.html for the explanation. I use `arm_freq = 1750` and `over_voltage = 2` for my Raspi but 1650 / 1700 seems tolerable. Please keep in mind that the temperature would be increasing due to overclocking. My Raspi temp rose from` 37-38 C` to `42-43 C` on idle using Argon case.

gitea-mirror commented

2026-05-05 06:56:55 -06:00

Author

Owner

@pascal-fb-martin commented on GitHub (Dec 26, 2021):

I have a similar issue on Debian bookworm/sid (and AMD Ryzen 5 5600): when the cursor moves from a Windows 10 (acting as client) to a Linux screen (acting as server) then the Linux screen goes entirely black for 1-2 seconds.

@pascal-fb-martin commented on GitHub (Dec 26, 2021): I have a similar issue on Debian bookworm/sid (and AMD Ryzen 5 5600): when the cursor moves from a Windows 10 (acting as client) to a Linux screen (acting as server) then the Linux screen goes entirely black for 1-2 seconds.

No labels

Rows
Columns