🙏 Testers wanted 🙏

[hrvach]

I am working on extending support for some devices that had issues historically and would kindly ask for some help with testing the upcoming releases.

Even if your keyboard/mouse works perfectly, I'd still appreciate your input on an upcoming release to make sure nothing got accidentally broken for you.

If your keyboard/mouse wasn't working, your input is especially appreciated - despite the efforts, it's hard to fix issues without access to the hardware that doesn't work. Your help is much appreciated!

[Update] Newest version:

deskhop.zip

Thank you!

[chri2]

First item to test - testing-release.zip

I'll try as soon as I'll find time. But: could you upload the source as a branch so it'd be possible to compile it with my own settings? With the default settings the mouse for sure is not usable in my setup and testing is quite difficult.

[hrvach]

I'll try as soon as I'll find time. But: could you upload the source as a branch so it'd be possible to compile it with my own settings? With the default settings the mouse for sure is not usable in my setup and testing is quite difficult.

Of course I'll upload the source, just have to tidy it up a bit so it's not totally embarrassing :)

[raldnor]

Hi Hrvach,

I just tried this release and the rotary (volume) encoder works, including mute (a press on the encoder), but fn+esc does not work with this firmware. I mapped fn+esc to the power button in the QMK firmware.

Cheers!

[hrvach]

I just tried this release and the rotary (volume) encoder works, including mute (a press on the encoder), but fn+esc does not work with this firmware. I mapped fn+esc to the power button in the QMK firmware.

That's kind of expected, since system control section is next on my to-do list - I'll update here when I get it done. Thanks!

[jalmeroth]

Hi @hrvach ,

for me the device is constantly resetting or switching the active board back and forth.

This is what I saw when pressing an 'a' on the keyboard.

Here's the full pcap (Wireshark) file for this one session:
deskhop_testing_release.zip

Hope this helps,
Jan

[hrvach]

@jalmeroth apologies, I'm a dumbass and mistakenly uploaded debug version of the firmware. Updated, sorry! :)

[hrvach]

It's stable w/o adapter, even when the adapter gets connected, but once I hit a key it starts to go wild

I updated tinyusb in this release, maybe something changed? Or I just made a bug I can't find :)
testing-release-3.zip
This one is built with the previous (current prod) version of tinyusb. Same thing?

[hrvach]

It's stable w/o adapter, even when the adapter gets connected, but once I hit a key it starts to go wild

Also can you please describe your keyboard/receiver usb vid/pid? I need to get one :)

[jalmeroth]

Also can you please describe your keyboard/receiver usb vid/pid? I need to get one :)

All of this info has been collected here: #47.
I will test the new release later and report back

[hrvach]

Also can you please describe your keyboard/receiver usb vid/pid? I need to get one :)

All of this info has been collected here: #47. I will test the new release later and report back

Thank you so much! I've found at least one bug in the meantime (despite it working for me with no issues), please hold on while I fix it :)

[jalmeroth]

v4 is stable for me now 👍 But the parsed/sent keyboard values are not sensible yet.

[hrvach]

This one should be better.

testing-release-4.zip

[chris-010]

no problem so far

[Faisalalali]

Hello, new tester here.
I'm noticing that mouse movement is inconsistent on both Windows and Linux. Kinda like if the acceleration is skewed to the bottom right somehow. I tested a typical mouse and a Logetich MX mouse and they both show same behavior.
Has the mouse movements emulation changed in this version?

[hrvach]

Hello, new tester here. I'm noticing that mouse movement is inconsistent on both Windows and Linux. Kinda like if the acceleration is skewed to the bottom right somehow. I tested a typical mouse and a Logetich MX mouse and they both show same behavior. Has the mouse movements emulation changed in this version?

Well caught - respect, it's a regression of a previously fixed bug. And embarrassing enough, I've been using it without noticing :)

[hrvach]

New version with LOTS of changes is up for testing while I tidy and commit the code. Most keyboard shortcuts related to configuration have been removed in favor of a web GUI.

Changes and updates:

1. UART reworked to use DMA without the need for CPU to worry about serial comms.

2. Single unified firmware, just one .uf2 which should hopefully autodetect where it's running.

3. One box should be able to update the other if there is a higher version detected running. You will need to only update one of. them, the other will copy its firmware and update itself.

4. Firmware upgrade can now be done easier, with board presenting itself as a usb stick while still running, so you can use mouse/keyboard and not have to plug them directly - everyone hates tracking cables.

5. There is a new GUI "configuration mode" activated by "left shift + right shift + C + O". This causes the box on the kbd side to reboot and present itself with additional configuration HID endpoint and a mass storage device (like a USB drive). On that drive, you'll find a "config.htm" file you can open using Chromium/Chrome - sadly Firefox has no webhid :-(( This presents a web form to configure the device in an easy way, without having to remember 400 weird shortcuts. Hit connect first, device should be listed (but only if it's in configuration mode).

6. Linker script changed, build will have a new script that calculates crc32 and updates the binary so the box can verify flashing process validity.

7. HID parser reworked, some nkro keyboards should be supported.

I probably forgot something. Thanks for any feedback and testing...

[hrvach]

* user uses a programmable keyboard and there is a way to program it even with deskhop inbetween (no idea if that is the truth or will be possible in the future)

Programming or configuring QMK-like keyboards isn't supported on purpose, for exactly this reason - however impractical at times.

* attacker programs the keyboard to send the key combination to enable programming mode of deskhop

If the attacker is able to program your keyboard, it's already game over. Would it make sense to have an "extra safe" option you could enable to enforce options like "press button to allow upgrade" or even "permanently disable config mode"?

[chri2]

If the attacker is able to program your keyboard, it's already game over.

In my example on Computer A - the one that is not trustworthy. But how to get to Computer B if deskhop cannot be compromised?

In my opinion this is all about separating the two computers sharing keyboard/mouse as much as possible and I would enable every layer of security I could get to ensure this.

[chris-010]

I follow this discussion about the consideration between security and usability with interests. The main topic is an assumed security issue that could make it possible to modify firmware without physical user interaction to take over an isolated system. I consider viewpoints from both sides. Therefore i suggest an idea to allow firmware updates only with physical user interaction (to keep security), but without opening the case (to keep usability).

What about to make a two-stage firmware update process.

• Step1 (w/o physical user interaction): to select firmware file and prepare board for Step2
• Step2 (with physical user interaction): to flash an finalyze firmware update. But physical interaction is not activated by pressing a button of rpi pico which is inside a case. Step2 can only be actived by unplug/replug or similar procedure of connected hid device(s).

In short, using the usb plug for physical user interaction to release firmware update process.

[chri2]

using the usb plug for physical user interaction to release firmware update process

Nice 👍. A quite simple way has been used by eletronic devices with upgradeable firmware for a long time: put firmware on usb memory with a certain name, put usb memory into device and wait.

This would make all of this a already known and simple procedure for the user. If it is possible in hardware/software I can't say.

[chris-010]

great input, maybe i was thinking too complicated.

[alankeny]

I'm running the test firmware from this thread that was built on June 16th. I have a Logitech Unifying receiver, MX keys keyboard, and M525 mouse. The Unifying receiver is connected to the keyboard port.

For the most part everything with the mouse and keyboard works as expected except the media keys on the keyboard including mute, volume up, and volume down. Let me know if there's any data I can collect or troubleshooting steps I should take. Thanks!

[hrvach]

I'm running the test firmware from this thread that was built on June 16th. I have a Logitech Unifying receiver, MX keys keyboard, and M525 mouse. The Unifying receiver is connected to the keyboard port.

For the most part everything with the mouse and keyboard works as expected except the media keys on the keyboard including mute, volume up, and volume down. Let me know if there's any data I can collect or troubleshooting steps I should take. Thanks!

I've been trying to get better support for consumer control "variable" format and non-boot mode keyboards, any improvement with this one?

@chris-010 this one should also fix the windows connectivity issue for configuration mode.

Now for the code cleanup ... :-|

[alankeny]

This one and v0.60 appear to be the same version. Let me know if I got that wrong, and I'll manually upgrade both picos to v0.60.

The keyboard behavior is the same with this release as the one I started with built on June 16th. The media keys for mute, volume down, and volume up result in mouse movement and sometimes right-clicks rather than the media keys registering on the host. Let me know if you need me to do anything. Thanks!

[hrvach]

This one and v0.60 appear to be the same version. Let me know if I got that wrong, and I'll manually upgrade both picos to v0.60.

The keyboard behavior is the same with this release as the one I started with built on June 16th. The media keys for mute, volume down, and volume up result in mouse movement and sometimes right-clicks rather than the media keys registering on the host. Let me know if you need me to do anything. Thanks!

Yes, it's the same version. Oh man, if I knew how many variations this HID thing could have, I'd do a different kind of project :) Perhaps dumping the keyboard hid descriptor would be helpful to figure out what it's parsing and why is it misbehaving. Thanks for your patience :)

[alankeny]

First, thanks for creating this! It's already so much more useful than the Synergy / Barrier / Input Leap software-only solution, because it doesn't depend on the local network to function. I can use it with my work computer, even while I'm connected to the work VPN which blocks local network access.

Hopefully I've collected what you're asking for. I ran lsusb and got:

Bus 005 Device 038: ID 046d:c52b Logitech, Inc. Unifying Receiver

I ran usbhid-dump -a 5:38 and got:

005:038:002:DESCRIPTOR         1719166459.222426
 06 00 FF 09 01 A1 01 85 10 95 06 75 08 15 00 26
 FF 00 09 01 81 00 09 01 91 00 C0 06 00 FF 09 02
 A1 01 85 11 95 13 75 08 15 00 26 FF 00 09 02 81
 00 09 02 91 00 C0 06 00 FF 09 04 A1 01 85 20 95
 0E 75 08 15 00 26 FF 00 09 41 81 00 09 41 91 00
 85 21 95 1F 09 42 81 00 09 42 91 00 C0

005:038:001:DESCRIPTOR         1719166459.226667
 05 01 09 02 A1 01 85 02 09 01 A1 00 95 10 75 01
 15 00 25 01 05 09 19 01 29 10 81 02 95 02 75 0C
 16 01 F8 26 FF 07 05 01 09 30 09 31 81 06 95 01
 75 08 15 81 25 7F 09 38 81 06 95 01 05 0C 0A 38
 02 81 06 C0 C0 05 0C 09 01 A1 01 85 03 95 02 75
 10 15 01 26 FF 02 19 01 2A FF 02 81 00 C0 05 01
 09 80 A1 01 85 04 95 01 75 02 15 01 25 03 09 82
 09 81 09 83 81 00 75 06 81 03 C0 06 BC FF 09 88
 A1 01 85 08 95 01 75 08 15 01 26 FF 00 19 01 29
 FF 81 00 C0

005:038:000:DESCRIPTOR         1719166459.229314
 05 01 09 06 A1 01 95 08 75 01 15 00 25 01 05 07
 19 E0 29 E7 81 02 81 03 95 05 05 08 19 01 29 05
 91 02 95 01 75 03 91 01 95 06 75 08 15 00 26 FF
 00 05 07 19 00 2A FF 00 81 00 C0

[hrvach]

First, thanks for creating this! It's already so much more useful than the Synergy / Barrier / Input Leap software-only solution, because it doesn't depend on the local network to function. I can use it with my work computer, even while I'm connected to the work VPN which blocks local network access.

Hopefully I've collected what you're asking for. I ran lsusb and got:

Bus 005 Device 038: ID 046d:c52b Logitech, Inc. Unifying Receiver

I ran usbhid-dump -a 5:38 and got:

005:038:002:DESCRIPTOR         1719166459.222426
 06 00 FF 09 01 A1 01 85 10 95 06 75 08 15 00 26
 FF 00 09 01 81 00 09 01 91 00 C0 06 00 FF 09 02
 A1 01 85 11 95 13 75 08 15 00 26 FF 00 09 02 81
 00 09 02 91 00 C0 06 00 FF 09 04 A1 01 85 20 95
 0E 75 08 15 00 26 FF 00 09 41 81 00 09 41 91 00
 85 21 95 1F 09 42 81 00 09 42 91 00 C0

005:038:001:DESCRIPTOR         1719166459.226667
 05 01 09 02 A1 01 85 02 09 01 A1 00 95 10 75 01
 15 00 25 01 05 09 19 01 29 10 81 02 95 02 75 0C
 16 01 F8 26 FF 07 05 01 09 30 09 31 81 06 95 01
 75 08 15 81 25 7F 09 38 81 06 95 01 05 0C 0A 38
 02 81 06 C0 C0 05 0C 09 01 A1 01 85 03 95 02 75
 10 15 01 26 FF 02 19 01 2A FF 02 81 00 C0 05 01
 09 80 A1 01 85 04 95 01 75 02 15 01 25 03 09 82
 09 81 09 83 81 00 75 06 81 03 C0 06 BC FF 09 88
 A1 01 85 08 95 01 75 08 15 01 26 FF 00 19 01 29
 FF 81 00 C0

005:038:000:DESCRIPTOR         1719166459.229314
 05 01 09 06 A1 01 95 08 75 01 15 00 25 01 05 07
 19 E0 29 E7 81 02 81 03 95 05 05 08 19 01 29 05
 91 02 95 01 75 03 91 01 95 06 75 08 15 00 26 FF
 00 05 07 19 00 2A FF 00 81 00 C0

This looks more or less identical to my keyboard (the consumer control), but I need to get one of those unifying receivers, seems these are pretty popular and might behave differently. What's your keyboard/mouse model?

[alankeny]

What's your keyboard/mouse model?

My primary setup has a Logitech MX Keys Advanced Wireless Illuminated Keyboard and a Logitech Wireless Mouse M525.

I also tried a different Unifying receiver that's configured for a Logitech Wireless Touch Keyboard K400. The K400 includes a keyboard and a touchpad with some dedicated volume keys. I got similar results on both.

[hrvach]

What's your keyboard/mouse model?

My primary setup has a Logitech MX Keys Advanced Wireless Illuminated Keyboard and a Logitech Wireless Mouse M525.

I also tried a different Unifying receiver that's configured for a Logitech Wireless Touch Keyboard K400. The K400 includes a keyboard and a touchpad with some dedicated volume keys. I got similar results on both.

Could you please try deskhop-test2.zip and let me know if this fixes it? I have an idea what might be happening here.

[alankeny]

All of my media keys are working with deskhop-test2.zip 👍

Just to confirm I've tested show workspaces, show notifications, show desktop, previous track, play/pause, next track, mute, volume down, and volume up. They're all working with the Logitech MX Keys. Thanks so much!

[ak66666]

Thank you for this update - the mouse key and touchpad from the keyboard are recognized now.
I'm running the test firmware from this thread that was built on June 16th.

Mouse: Logitec M545 with unified receiver.
Keyboard: QMK-based ThumbsUp with NKRO and mouse keys enabled, and with Cirque Proglide touchpad.

Mouse works as expected.
Regular keys on the keyboard work as expected too.

Keyboard's mouse key and touchpad seem to be misread/mapped to different direction.
The QMK left and right mouse directional keys and the touchpad left and right gestures result in the mouse pointer movement up and down.
The up and down mouse key/touchpad seem to be treated as mouse scroll up/down,

[ak66666]

I managed to make it work, may be a crude solution, but it works for me.
Submitted a PR: ak66666:rc_ak66666

[hrvach]

Is there anyone with multiple monitors on windows who could test something for me? I have an idea how to support multiple screens without it being shitty (as it currently is), but have nothing to test on. Any help appreciated. Thanks!

[ak66666]

Hi,
Sure, I can test it, got two Windows machines with 2 and 3 displays.

[Trekky12]

Hey,

I have two windows machines: the first one is a notebook with a external display connected and the second one has three displays.
I could do some tests.

[hrvach]

@ak66666 Can you check test-digitizer.zip ? It has (temporarily) absolute mouse replaced by a digitizer pen, expect it to be pretty broken for pretty much everything but I'm just curious how does the cursor behave on multi-screen windows (with number of screens set to 1 / settings factory reset). I've found a microsoft note that gives some clues about the possibility of an actual workaround..

[ak66666]

Mouse moves between the screens as expected.
Mouse buttons don't work though.

[hrvach]

Mouse moves between the screens as expected. Mouse buttons don't work though.

That's expected because buttons are not implemented (I know), it's just a test .... but, mouse moves across multiple desktops and it behaves normally? No shitty behaviour like the current prod/rc version have with multiple screen Windows?

[ak66666]

Yes, it moves as expected, even the QMK mouse keys are working.
My screens are located a bit weirdly, physically they are set like this:
_______________B3
B2__B1__A1
_______________A2

In Windows the B-side is like that:

_____B3
____________B1
___B2

Actually the dev version you published in this thread was working good too - after I set the number of screens and OS type through the new web interface. Without that config there were some issues, but I don't remember how it was behaving then.

This new test version works fine with that layout right off the box, no configuration was needed.

[hrvach]

Yes, it moves as expected, even the QMK mouse keys are working. My screens are located a bit weirdly, physically they are set like this: _______________B3 B2__B1__A1 _______________A2

In Windows the B-side is like that:

_____B3 ____________B1 ___B2

Actually the dev version you published in this thread was working good too - after I set the number of screens and OS type through the new web interface. Without that config there were some issues, but I don't remember how it was behaving then.

This new test version works fine with that layout right off the box, no configuration was needed.

This is extremely helpful, thank you. I think I'll be able to fix Windows and possibly Mac OS issues with multiple desktops in a way that's not super annoying like now.

[hrvach]

I'd appreciate some feedback on v0.72 (pre-release), particularly focusing on NKRO. Works for folks?

[ak66666]

Works good for me, no new issues in functionality.

The configuration shows version v.073 though, not 72.

[hrvach]

Works good for me, no new issues in functionality.

The configuration shows version v.073 though, not 72.

I might be dyslexic, that's probably why :) ... will fix :)

[alankeny]

I synced my fork with v.073 / 72 and rebuilt deskhop.uf2.

I configure my Deskhop from a laptop running Linux. After the update I had to change my udev rules from:
ATTRS{idVendor}=="1209", ATTRS{idProduct}=="c000"
to
ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="107c"

After that change, I could connect, read, and write the web configuration page from Chrome again. No other issues in functionality. Everything is still working great. Thanks!

[wences-dc-uba-ar]

Thanks for this awesome gadget, and sorry if this comment not belongs here:
Today doing update to 0.73 I realized my version was in 175 (don't know since when), but after copying the firmare -> entering_config_again... I noticed the version still showing 175.
After numerous try and error found that have to wipe firmware like the first time install on both picos (while the other was unplugged) to make the update.
(IdK, something about version compare, maybe).
I think a note on the release page could advice on how to ease the update in this numeration-change scenario.

[hrvach]

There is a pre-release of v0.77, testers more than welcome! :)

[ak66666]

Used it all day today, two windows machines with multiple screens each, no new issues.

My previous issue with mouse/trackball controllers on both input ports still there, yet seem be less frequent than before.
Cursor is still jumping when both side mice are actively used, switched from one to another.
Stops this behavior when one of the trackballs is inactive.
Yet I'd say it happens less often than before, and primarily after I switch to the other side mouse like every other minute.
Overall, an improvement.