I am using the GM-RM1 with vintage computers, where ‘relative’ mouse mode is required.
The mouse worked correctly on firmware 1.3.1 (glkvm-RM1-1.3.1-0703-1751530740)
with 1.4.x, relative mode no longer worked (I forget the specific version; 1.4.2 perhaps? it was advertised through the UI as the latest stable version ~last week)
with 1.5.0 (glkvm-RM1-1.5.0-0825-1756094794), mouse movement is back, but clicks do not register.
I also see that the stand-alone app does not support relative mode. Is there a timeline for relative mouse support in the app?
Could you please tell me what kind of computer is RM1 controling and try to disable virtual media to see if the click work. Typically, if movement work then clicking also does.
Did you using a MAC app. Mac app doesn't support relative mode in mose so that have to use in in browser.
with 1.5.0 (glkvm-RM1-1.5.0-0902-1756780733), disabling the virtual media has no effect. The mouse tracks, but clicking is not possible.
Again, with 1.3.1, the mouse tracks and clicks as expected.
This is all via the web interface. As I said in the initial post, I am aware that the stand-alone app on the Mac does not support relative mode; I am interested to know when that feature might be available.
Could you please try to change the device identity to see if the problem can be solved?
Sorry, currently we cannot add the relative mode, because the browser kernel on the Mac app does not support the requestPointerLock API. We will keep trying.
I assume you mean the “Device Identity” drop down in the System section of the Settings pane. Changing to various settings here had no effect (mouse still tracks, no clicks). Under 1.3.1, changing the EDID (there is no separate “Device Identity” setting in 1.3.1) also has no effect, mouse tracks and clicks correctly under all of the settings that I tried.
I think I understand the issue you're encountering. Before version 1.4.0, we only simulated one mouse, and switching between relative and absolute modes required directly changing the mouse type, which necessitated a device restart. After version 1.4.0, we default to creating two mice—one relative and one absolute—so switching between modes no longer requires re-simulating the mouse or restarting the device. However, it seems this isn’t working on your computer. If the controlled computer is running Windows, try updating the USB or HID device drivers in Device Manager. If that doesn’t resolve the issue, you may need to try disabling the default creation of two mice.
I've tested it, and it seems our frontend doesn't support older versions of mice.So disabled sencond mouse can’t make it work. If you want to use it, you might have to roll back to version 1.3.2.
This sounds very plausible, thanks for the explanation.
Can you explain what you mean by this? Is there some way to do that via command line config? (I see from your next post that it may not be relevant, but I am curious)
This is unfortunate - can you share any more detail? I see that source code is available for the latest build, but not the 1.3.x era builds. It would be a shame if I am unable to take advantage of future improvements just because of a regression in mouse support. I’ve also backed the Comet Pro project, now I’m guessing it may have the same issue.
Thank you for looking into it. I would love to find some kind of resolution.
We'll have fix in future versions to allow users to disable the second mouse via command. However, what puzzles me is :Theoretically, replacing the USB identity should resolve this issue. Unless your computer's os is very unique...
That sounds good; although from your comment above [I’ve tested it, and it seems our frontend doesn’t support older versions of mice], it sounds like that may not fix my issue? Can you elaborate on what you mean by “older versions of mice”? Maybe I’m misunderstanding.
Is the ‘two mice’ behavior coming from the underlying pikvm code? Would I be able to disable it locally with an yaml override such as
kvmd:
hid:
mouse_alt:
device: ""
?
To answer your question, my setup is unusual, in that the controlled computer does not have USB at all. I am relying on USB to ADB converters. I’ve ordered a different converter, to see if perhaps the one I am using does not handle multiple mice being connected gracefully.
You can disable second mouse by the command you find . but I not sure if frontend can recognized this change. Maybe you need to switch to PIKVM UI to make it work
Following up - disabling the second mouse by placing that directive in the override.yaml has restored the mouse functionality in 1.5.0. It would be great to see that functionality exposed somewhere in the UI in a future release.