bitfocus / companion

Bitfocus Companion enables the reasonably priced Elgato Stream Deck and other controllers to be a professional shotbox surface for an increasing amount of different presentation switchers, video playback software and broadcast equipment.
http://bitfocus.io/companion
Other
1.62k stars 504 forks source link

[BUG] Loupedeck CT not recognized #2744

Closed aboutmedia closed 6 months ago

aboutmedia commented 9 months ago

Is this a bug in companion itself or a module?

Is there an existing issue for this?

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

Julusian commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

Could you try beta 6789? Hopefully that will resolve this

aboutmedia commented 9 months ago

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!

dherlein commented 8 months ago

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 commented 6 months ago

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 commented 6 months ago

@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 commented 6 months ago

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 commented 6 months ago

@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?

johnsudaar commented 6 months ago

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

aboutmedia commented 6 months ago

@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 commented 6 months ago

@aboutmedia there is one of 6951

aboutmedia commented 6 months ago

@Julusian Great! It works for me as well.