Questions[kvm-switch](ubuntu)

I’m trying to share the same monitor between a desktop and a laptop. I got a KVM. Switching the shared monitor from the desktop to the laptop works fine; switching the other way, from the laptop to the desktop works randomly about 30% - 50% of the times.

I’ve found a few people with a similar issue but no clear solution to solving it.

Here are some more details.

The hardware:

• a Linux desktop (Ubuntu 20.04) with an Asus Z170-K motherboard with a graphics chipset Mesa Intel® HD Graphics 530 (SKL GT2)
• a DELL laptop running Windows 10, with a DP to DVI dongle.
• a DELL monitor 2001FP with a DVI and a VGA input, used in portrait mode.
• a TV connected via HDMI to the Linux desktop
• a Bowu EL-21UHB 2-port USB KVM switch, video is DVI, and it is powered only via the single USB link to each PC. The same product is sold under the same model name but different brand

When I switch the KVM from the laptop to the desktop, if the video doesn’t switch properly, the monitor goes dark, but it seems it detects a signal or power because the monitor’s power LED is green, not amber. It will eventually come on after a random delay, often several minutes, without any specific action on my part.

xrandr reports the monitor is connected even though it is dark:

% xrandr | grep -v '^ '
Screen 0: minimum 320 x 200, current 3120 x 1600, maximum 16384 x 16384
HDMI-1  connected primary 1200x1600+1920+0 left (normal left inverted right x axis y axis)  367mm x 275mm
HDMI-2  connected         1920x1080+0+0         (normal left inverted right x axis y axis) 1440mm x 810mm
DP-1 disconnected                               (normal left inverted right x axis y axis)

I’m not sure why the desktop’s DVI output is listed as HDMI-1, nor why it is reporting a DP output as it does not have one.

I’ve tried switching the DVI output (labeled “HDMI-1”) on and off via the xrandr command but that had no effect.

I’ve tried issuing commands to /sys/class/drm/card0-HDMI-A-1/status in a sudo’ed bash shell:

echo detect > /sys/class/drm/card0-HDMI-A-1/status
echo on > /sys/class/drm/card0-HDMI-A-1/status

Again no effect.

I’ve tried changing from a USB 2.1 to a USB 3 port on the desktop. Again, no effect.

Recently, sometimes switching the KVM to the desktop has come up with a working monitor but in the wrong mode (landscape instead of portrait) which then fixes itself in typically under a minute.

Oh, and obviously, the monitor never had any issues when connected directly to the desktop via a DVI cable.

And I checked my /var/log/syslog for any messages. I think the only relevant ones are these:

% egrep 'stride|EDID' /var/log/syslog* | sed -e 's;.*/gdm-x-session;;' | uniq -c
    735 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 2944x1080 stride
    117 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3520x1200 stride
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3120x1600 stride
     27 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 2944x1080 stride
      4 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3520x1200 stride
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3120x1600 stride
      3 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 2944x1080 stride
      7 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3520x1200 stride
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3120x1600 stride
     11 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 2944x1080 stride
     15 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3520x1200 stride
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3120x1600 stride
      9 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 2944x1080 stride
    105 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3520x1200 stride
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3120x1600 stride
     86 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 2944x1080 stride
      2 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3520x1200 stride
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3120x1600 stride
   1206 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 2944x1080 stride
      2 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3520x1200 stride
      1 [77767]: (II) modeset(0): Allocate new frame buffer 3120x1600 stride
    289 [77767]: (II) modeset(0): EDID vendor "DEL", prod id 40968

The additional EDID lines are from a script I wrote that monitors xrandr every minute.

The 3 frame buffer sizes listed in syslog are supposedly for different arrangements of the 2 displays on the desktop, the 1920x1080 TV and the 1200x1600 DELL monitor:

• Allocate new frame buffer 3120x1600 stride = this is the correct side by side
• Allocate new frame buffer 3520x1200 stride = this is side by side, with the monitor in landscape mode
• Allocate new frame buffer 2944x1080 stride = this is side by side, with the monitor in landscape mode at lower res

At this point, yes, I’m aware that using the monitor’s DVI input for one PC and VGA for the other should work. And it sounds like the best solution to share the mouse and keyboard would then be Barrier.

[EDIT: the same thing happens when the KVM is set to the desktop with the monitor working fine and, after the predetermined time of inactivity, the screen is blanked by Ubuntu. Mouse or keyboard activity may not wake the monitor beyond turning its LED from amber to green.]

But still, are there any ideas of what the problem might be with the KVM switching?

And by the way, I found that if I only wanted to use the DVI input of the monitor, I would have an issue in adding a second virtual or ghost monitor to the Windows 10 laptop. And that the solution there might be adding a DP to VGA dongle to it, without any VGA cable beyond that, to trick Windows 10 into allowing a ghost monitor.

Barrier is a free popular KVM software that enables mouse/keyboard sharing across several devices.

I've been fiddling with it for a few hours and I can't seem to get it right.

I have a barrier server running on my Windows machine. I've downloaded the git repository and built the binaries. I've copied barrier, barrierc and barriers into /usr/bin.

If I run barrier GUI, specify the server IP and enable the server, it works. I can do it with and without SSL (as long as both the client and the server have the same setting set). I would prefer to use SSL though.

I've then tried running barrierc --enable-crypto <ip>. The server acknowledges the connection, but says it's not secure and it doesn't work. However, if I run the same command with the -f flag barrierc -f --enable-crypto <ip> which makes it run in the foreground, it all works dandy.

Since I'm on Ubuntu 18.04, I've setup a systemd service like so:

[Unit]
Description=Barrier mouse/keyboard share
Requires=display-manager.service
After=display-manager.service
StartLimitIntervalSec=0

[Service]
Type=simple
ExecStart=/usr/bin/barrierc -f --enable-crypto 192.168.12.96
Restart=always
RestartSec=1
User=karlovsky120

[Install]
WantedBy=multi-user.target

I've named it barrier.service and copied it into /etc/systemd/system/.

I've tried starting it manually, but it refuses to work. From what I can tell from systemctl status, it looks like systemd runs the client, but the client exits immediately and then it restarts it. I've tried with and without the -f flag, but the result is the same.

The server also complains that the client connection might not be secure, which is the same error you get when you try to connect with a non SSL client to an SSL server. It does so with and without the -f flag.

I know I have to enable the service to have it run on startup, but how do I get it to work at all?

I hope I am posting this to the correct area... I just purchased a StarTech SV211DPUA 2-port display port KVM switch. I'm using Ubuntu 18.04. I'm having an issue with the KVM where the mouse lags dramatically when using the KVM switch. When I mean lag, I mean I can move the mouse pointer and then the pointer pauses on its own for about 2 seconds and then it will allow me to use it again. The mouse I am using is a Logitech MX518. Is there a file somewhere (Xorg?) that I can try to tweak to see if I can fix this lag issue? Thanks ahead of time.

I'm using a wireless Logitech Keyboard with a Logitech Unifying Receiver plugged into a KVM switch. I created a systemd suspend shortcut to suspend the laptop, a Lenovo IdeaPad. The laptop's lid is always closed. I'm unable to wake the Lenovo from suspend unless I lift the laptop's lid. Once the lid is lifted, the laptop wakes. I want to be able to wake the laptop without having to lift the lid. I'm not sure how to do this.

I tried two things, neither worked. First, I enabled the wakeup file for the Logitech Unifying Receiver (proc/acpi/wakeup). It did indeed wake the laptop when I used the keyboard. The problem was that the laptop woke within about five minutes without any input from me. No activity from the keyboard or anything else. Second, I tried the fix described at How do I get a wireless USB keyboard to to wake Ubuntu 13.10 from suspend? Same problem as the first -- the laptop wakes at unpredictable times, seemingly on its own.

When I look at devices using lsinput, I can see the Logitech keyboard. It's given the physical address usb-0000:00:14.0-3.1.1:1. When I look at proc/acpi/wakeup, I see pci:0000:00:14.0. There is no 3.1.1 extension. If I look at /sys/bus/usb/devices/1-3.1.1, I see it's the Logitech Unifying Receiver.

Here is the result of cat syslog during a wake event:

How do I put all this together to wake with keyboard input, but to suppress other wake events?

It's several days later and I've discovered this -- "Interaction with the Embedded Controller This is where really difficult to diagnose issues occur. The Embedded Controller (EC) contains proprietary code to control peripherals." From https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips

Suffice it to say, this looks pretty difficult and is likely specific to my Lenovo.

I'm using 10.04 behind a KVM switch. The KVM is old and doesn't pass DDC through, so when the box boots up it just assumes I can't handle anything beyond 800x600. Apparently the xorg.conf is ignored, so I can't just hack monitor data directly into that. Is there a way to tell the box what my monitor is that will persist across reboots?