Edid problems

KVM
1

Hello,

I'm currently not happy with the ungoing state of the firmware.

Currently using release 1.7.0 release 2 on the comet pro with a ATX board.

When 3 screens or 2 screens are involved and a Edid change happened by me, it should be a new screen.

fine that works, but it unleashes something very nasty and I want this behaviour to stop.

what happens is that the GL kvm keeps looping and re-applying the same edid.

my mouse freeze ocassionally, in windows in the monitor view I see it refresh.... a different resolution will actually also show my screen being minimized and break.

absolutely nuts, this is not a loose cable btw.

it's worth to note that I only show screen on monitor 1 in Windows, which is my displayport monitor, basicly the comet pro has no screen but also don't have to reconnect loop or whatever it does now, maybe it isn't the Edid because when restarting the Comet it happens again.

edit:

it seems when I look to monitors in devmgmt.msc it goes on and out, and only when I replug hdmi on the comet it's fixed.

final conclusion:

the kvm breaks when it does not detect a screen, reapplies Edid and starts causing a driver loop on my Windows system, even though this is a perfectly valid use case, where a user threats the kvm as a second screen and wishes to turn it off in Windows, this means that it however still shows screen in bios and what not, it's purely a Windows targeted setting, as Windows has been booted there is no signal to the kvm, and only showing signal to monitor 1.

image
image1723×1276 103 KB

the constant loop is uneccesary and breaks.

Before the staff tells me this is normal, no it isn't, it should actually behave the same as a monitor nothing more or extra or forced, other kvms like the jetkvm don't show this, it might be added to solve a niece issue but then make this behaviour toggleable.

2

Hi, I wonder if you use the HDMI passthrough function?
It will result in the costomized EDID not work, the device will automatically choose the higher EDID it can support between resoluton of controlled device output and the external monitor connected to HDMI out.

4

Hdmi out is not used only hdmi in.

After extensive testing, if I toggle to only have view on screen 1 in windows, there will be no signal to the comet pro as what my intention is.

But the comet pro simply brute forces a monitor restart, bombarding driver events which causes huge lag.

This is my use case:

First I turn my main monitor off.

I use the kvm to start my pc via the atx board, after bios load I enter my credentials through the kvm for veracrypt.

if windows has been booted, i login as my user account through the kvm, I also open another drive for veracrypt with my games on it.

if done my system is ready for streaming moonlight.

As far as this configuration goes is:

I do use apollo instead of the standard moonlight server software, this allows me to create virtual screens where my games are on for the client.

So what I do within this virtual screen?

If this screen is precense, I disable monitor 1 which is the comet pro.

My expectation is: that comet pro respects being off rather than restarting its signal.

Windows has memory for when a monitor has been connected and then to turn other monitors off by user setting, but it destroys this function because the comet pro forces a monitor restart and starts bombarding on and off events which I can see in devmgmt.msc under monitors.

When this happen, the lag on the moonlight/artemis stream is unbearable.

--

if I don't want to use Moonlight streaming to play directly, I start pc again and enable my monitor, and when I'm on windows I only display on monitor 1 which is my main monitor and not the comet, the position is changed because I use display port which has a higher priority than hdmi, so hdmi becomes 2.

Then the comet should disconnect, but also bombards on and off events, this also indirectly causes input lag because it spikes cpu.

This is basicly the issue, no monitor behaves like this, and this kvm should also not behave like this.

5

Sincerely appreciate your detailed description.
I have communicated with our engineer and this situation will have improvement in future firmware update.

1 Like
6

Thank you, I leave this thread open if there is any news on this, for me this is a important improvement :+1:

1 Like
7

Hi, I send you a PM via this thread. Could you please check and try with the new firmware we temporary complied for this issue.

1 Like
8

Thank you, it works :+1:

9

Glad to hear that !

1 Like
10

Hi again,

I just tested the newer beta 1.7.1 but I don't see the hdmi patch there the old behaviour returned.

In which version is the fix expected ? :slight_smile:

1 Like
11

It's expected to be in version 1.7.2; we're currently working on it.

1 Like
12

Version 1.7.2 has been released. Please check if it fixes your issue.

1 Like
13

It works fine :+1:

1 Like