Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[BUG] Loupedeck CT not recognized #2744

Closed
2 tasks done
aboutmedia opened this issue Feb 13, 2024 · 14 comments
Closed
2 tasks done

[BUG] Loupedeck CT not recognized #2744

aboutmedia opened this issue Feb 13, 2024 · 14 comments
Labels
area/surface Something to do with a control surface (eg Streamdeck) BUG Something isn't working
Milestone

Comments

@aboutmedia
Copy link

Is this a bug in companion itself or a module?

  • I believe this to be a bug in companion

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

Having an issue with the Loupedeck CT. Companion doesn't recognize the device. The software from Loupedeck is installed, but not running. Not even in the background. The checkboxes to activate support for the Loupedeck are checked.

The firmware of the Loupedeck CT is 0.2.8.

Steps To Reproduce

No response

Expected Behavior

No response

Environment (please complete the following information)

- OS: MacOS 14.2.1
- Browser: Chrome
- Companion Version: 3.2.1

Additional context

No response

@aboutmedia aboutmedia added the BUG Something isn't working label Feb 13, 2024
@Julusian
Copy link
Member

Julusian commented Feb 19, 2024

On your mac, with the loupedeck connected could you open 'System information', native to 'USB' select the loupedeck and send a screenshot.

It would also be interesting to know what firmware version the loupedeck software reports for it.

It should look something like this (but this is for a loupedeck live):
image

@Julusian Julusian added the area/surface Something to do with a control surface (eg Streamdeck) label Feb 19, 2024
@Julusian
Copy link
Member

From some googling, there are two revisions of the hardware of the CT, one with a product id of 0x0003, and one with 0x0007. It looks like we only support the 0x0007 one currently, I can't tell if it would be easy or need some reworking to support the other one

@aboutmedia
Copy link
Author

Thank you for your reply. After a quick research I found out that I’ve got the other revision. See the attached screenshot for more information.

I hope that you can offer support for this revision!
Foto 20-02-2024 om 11 49

Julusian added a commit that referenced this issue Feb 21, 2024
@Julusian
Copy link
Member

Julusian commented Feb 21, 2024

Could you try beta 6789? Hopefully that will resolve this

@aboutmedia
Copy link
Author

The beta works! The device was found directly after installing the beta.

Either, the touch buttons are working, but there is nothing shown on the touch buttons. All physical buttons are working as well, but the rotary knobs on the sides aren't working.

That being said, thank you for your help so far!

@Julusian Julusian added this to the v3.3 milestone Feb 25, 2024
@dherlein
Copy link

dherlein commented Mar 2, 2024

I am running beta 6818 and have a Loupedeck CT 0x0003. Firmware is 0.2.5, which Loupedeck software reports as up to date.

Companion recognizes the Loupedeck surface but always says "offline". It never allows me to set any settings for the surface and won't actually show any buttons on the surface.

@johnsudaar
Copy link

I took some time to debug this issue since I also really want to use my Loupedeck CT with companion. It sounds like such a perfect fit.

I think I found the 2 issues preventing this from fixing.

First issue: Incomplete data sent to the write queue

The first issue is that we send invalid data to the write queue.

The LoupeDeckCT write queue is expecting a full renderer as the second argument (https://github.com/bitfocus/companion/blob/main/companion/lib/Surface/USB/LoupedeckCt.js#L271C105-L271C111). This is needed to fetch the rendered image size (https://github.com/bitfocus/companion/blob/main/companion/lib/Surface/USB/LoupedeckCt.js#L286-L287).

However when sending an image to the write queue we do not send the full renderer but only the resulting buffer (here: https://github.com/bitfocus/companion/blob/main/companion/lib/Surface/USB/LoupedeckCt.js#L460 and here: https://github.com/bitfocus/companion/blob/main/companion/lib/Surface/USB/LoupedeckCt.js#L463). This results in a crash when fetching the render width and height.

This fix is quite straight forward: just remove the .buffer on line 460 and 463.

With this fix, the device is now showing up as online in the companion interface.

However the victory is short lived since even if all the buttons are now working fine, the display is staying black which lead us to the second issue.

Issue 2: Missing DRAW instruction in the @loupedeck/node library

To send an update to the screen, @loupedeck/node is sending a FRAMEBUFFER (0x10) instruction to the loupedeck (cf: https://github.com/Julusian/node-loupedeck/blob/main/packages/core/src/models/base.ts#L292-L295). However this just update the framebuffer of the loupedeck to update the display, the loupedeck need an instruction to move the framebuffer to the display. This is done via the DRAW command (0x0f). This instruction is missing in the lib. (I found a comment mentionning this command, but it looks unused: https://github.com/Julusian/node-loupedeck/blob/main/packages/core/src/models/base.ts#L26).

Adding the following lines after the drawBuffer (https://github.com/Julusian/node-loupedeck/blob/main/packages/core/src/models/base.ts#L292-L295) will make it work:

await this.#runInQueueIfEnabled(async () => {
	await this.#sendCommand(0x0f, Buffer.from('\x00A', true)
}, false)

(\x00A is the display ID of the central display, this need to be adapted to make all display work)

With those two modifications I was able to make the LoupeDeck CT work with Companion

@Julusian
Copy link
Member

@johnsudaar thanks for the detailed exploration and writeup.
The first part is a trivial fix and is pushed now.
The second part needs some thought on how to do, as those 0x0f commands are not needed for most other models.

What I think has happened here is that at some point in the firmware loupedeck changed how they addressed the top 3 screens. For the live, you can either treat it as 3 separate displays and issue 0x0f to flush the buffer, or you can treat it as one display and not have to do that.
Devices since then (and later hardware revisions) treat it as one display.
I believe the loupedeck-ct implementation was written against one of these newer revisions of the hardware (usb id 0x0007), and you are using the original revision (usb id 0x0003) which has been enabled with hope and no testing

So it probably is just a case of adding in the flushes at the appropriate places, and making it so that they are only done for the older revision of the ct.

@johnsudaar
Copy link

Thanks a lot @Julusian.
For my hardware version I do not have it handy here. But I'll check and come back to you on that.

IMHO it could be added in two places, either directly on the Loupedeck CT driver directly (add some logic to make sure that the code know when and when not sending those refresh packages) or in Companion, we could add an option so send those refresh states in companion.

I do not own any Loupedeck type hardware so I can try to make the PR on the driver repository but I wont be able to test it on other models (or more recent revision of my CT).

Julusian added a commit that referenced this issue May 2, 2024
@Julusian
Copy link
Member

Julusian commented May 2, 2024

@johnsudaar I've made the changes you proposed, could you retest this with beta 6949 or later and let me know if it works any better?

@Julusian Julusian moved this to In Progress in Companion Plan May 2, 2024
@johnsudaar
Copy link

You're way too fast for me !
Indeed it works perfectly! You're awesome!

@Julusian Julusian closed this as completed May 2, 2024
@github-project-automation github-project-automation bot moved this from In Progress to Done in Companion Plan May 2, 2024
@aboutmedia
Copy link
Author

@Julusian Can you compile a Mac ARM version of beta #6949 for me, so I can test it in my environment? Thanks a lot!

@Julusian
Copy link
Member

Julusian commented May 3, 2024

@aboutmedia there is one of 6951

@aboutmedia
Copy link
Author

@Julusian Great! It works for me as well.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
area/surface Something to do with a control surface (eg Streamdeck) BUG Something isn't working
Projects
Status: Done
Development

No branches or pull requests

4 participants