Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Support for Kontrol S4 MK3 #110

Open
acolombier opened this issue Feb 19, 2023 · 4 comments
Open

Support for Kontrol S4 MK3 #110

acolombier opened this issue Feb 19, 2023 · 4 comments

Comments

@acolombier
Copy link

Hi,

I have recently acquired these gears and I am looking for a way to drive the screens on that device. I have performed a partial reverse engineering of the communication to the screen class (bulk endpoint). The controller also has an HID and an audio class, but I'm not expecting this part to be the troubling one.

I'd be happy to help with adding support for the device, but sadly I have no experience at all with libusb. I'd be happy to share some Wireshark traces tho, perhaps someone could give me guidelines on how to get something started?

@harryhaaren
Copy link
Member

Hi,

Cool yes, the screens on the S4 Mk3 are the same as the "mk2/mk3" generation of devices, so almost all of the existing code will work with them. There is a bit of "playing" with the USB device ID and descriptors required, and some adjustments to the screen-sizes in pixels (they're 480x272 from memory... I had them working before, as I also had access to this device for a while!)

No need for wire-shark traces, the info for supporting new (kind-of-related-to-existing-devices) hardware is typically all available in lsusb output. As i've worked with that device before (and have access to it..) there's no need here!

As next steps, the question is more about some C coding experience, and a bit of enthusiasm to try things out. (its very safe to play with USB devices, just stay away from writing to the DFU (Device Firmware Update) USB endpoint, and its ~ impossible to brick it!).

Regards, -Harry

@acolombier
Copy link
Author

Thanks for your input! I just needed to hear that there wasn't any risk on messing up the device!

From my USB sniffing, I had already figured out the screen was 320x240.

I just got something working, but that only includes the screens since I am not planning on using the HID capability of Ctlra.

I will try to clean up the implementation and submit a draft PR within the next few days :)

IMG20230220013825

@ronlaws86
Copy link

From my very limited understanding of Mixxx, I'm assuming that in order to put deck relevant info on the screens, something would need to run aside Mixxx to pull metadata out of mixxx and generate images (probably in software) to then bitmap and send to the screens? as Mixxx's codebase (old QT) doesn't have the provisions in place to render something off screen and 'snapshot' it to send over to the controller.

Please correct me if i'm wrong here, i'm very out of the loop in terms of what Mixxx's limitations are currently.

@acolombier
Copy link
Author

Hi @ronlaws86 , yes that's correct. I have already implemented an offscreen renderer, that will be released in Mixxx 2.6. I also have implemented screen support for the S4Mk3, but this is currently waiting on a consensus for cross mapping communication before it can make it to the stable release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants