Push 2 hardware hack

[thetechnobear]

doh, I appear to have been beaten to this... someone has hacked the Push2 display

https://vimeo.com/145661291
http://sigabort.co/p2d

funny thing was, I only sat down to do this, this evening and had just been going through the USB sniffs when I saw it.

anyway, given its out (well nearly) in the open, here is what I found so far... and I'll share more as I find it out... assuming someone else doesnt publish it first
(I think it should be public available info, so all developers can use it)

its a simple USB protcol, simply sending bulk transfers.
the midi is on one interface , but for the display we are interested in interface 3 (nicely labelled Push Display) and its output endpoint 1. (no data comes back on the input endpoint 81, as far as Ive seen)
(its 512 byte buffers on the endpoints)

display data is send as:
- a single 16 byte packets containing : ef cd ab 89 00 00 00 00 00 00 00 00 00 00 00 00
- followed by 20 x 16364 bytes messages for the graphics data

Ove not fathomed the graphics data format yet, but appears to be simple raw pixels... in which case I just ned to figure resolution, and colour depth. I can do this by simply sending test data, and see what it displays

or perhaps someone already knows the resolution/colour depths?

also have I missed something, I couldnt see anything else in the usb dump, seems as simple as that.

[thetechnobear]

ok, so I now have the full details.... and some example code

first, Id like to thank sigabort for giving me the details about the resolution and the colour depth.
he has also released a library which allows developers to access the push2 display from Max,
so check him out on: http://sigabort.co/p2d

ok, so the details
- the device is using vendor id 0x2982 and product id 0x1967
- the push display interface is on interface 0, (2 is used for midi)
- you need to send a full frame approx every second, if this is not received the Push with blank the display
for each frame:
- you first send a 16 byte header with contents 0xef, 0xcd, 0xab, 0x89, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
- next you send the data, 327680 bytes.
(ableton send this as 20 * 16364 packets, but you can send them as one large one if you wish)

the data packet is 16 bit color raw data, there are 160 lines of 2048 bytes,
colour is encoded as 3b(low) green 5b red, 5b blue, 3b (high) green e.g. gggRRRRR BBBBBGGG , see macro in code example.
note: the resolution is 960 by 160 @ 16bit , so there are 128 bytes of zeros at the end of of line of data sent.
(odd, perhaps Ableton changed their plans for the display?)

Limitation: only one application can have the display device open, so if Live is running, you will not be able to run another app, similarly if you start your own app using it, then Live will not be able to access the display.
(so for 'user' setups in Live we need a different solution, perhaps accessing the 'Push2DisplayProcess')

the following is demonstration code, using libusb (which is cross platform) and simply draws a border around the display. ( no error checking to keep it compact!)

Code: Select all

#include <libusb.h>
#include <unistd.h>

#define HDR_SZ  0x10
#define DATA_SZ (20 * 0x4000)

#define WIDTH   960
#define HEIGHT  160
#define LINEBUF (DATA_SZ / HEIGHT)

#define RGB_H(r,g,b) ( ((g & 0x07) << 5) | (r & 0x1F)) 
#define RGB_L(r,g,b) ( ((b & 0x1F) << 3) | (g & 0xE0))

#define RB 5

int main(int argc, char** argv) {
    libusb_device_handle *handle;
    libusb_init(NULL);
    handle = libusb_open_device_with_vid_pid(NULL, 0x2982,0x1967);

    static unsigned char headerPkt[HDR_SZ] = { 0xef, 0xcd, 0xab, 0x89, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
    static unsigned char dataPkt[DATA_SZ];

    int off_l=0,off_h=0;
    int on_l = RGB_L(0x0f,0x00,0x0);
    int on_h = RGB_H(0x0f,0x00,0x0);
    for(int x=0;x<sizeof(dataPkt);x+=2) {
        int col = (x % LINEBUF) / 2;
        int row = (x / LINEBUF);
        dataPkt[x]= (col <10 || col >= (WIDTH - 10)) ? on_h : ( row < 10 || row >= (HEIGHT - 10) ? on_h : off_h);
        dataPkt[x+1]= (col <10 || col >= (WIDTH - 10)) ? on_l : ( row < 10 || row >= (HEIGHT - 10) ? on_l : off_l);
    }

    libusb_claim_interface(handle, 0x00);

    int tfrsize = 0;

    for(int i=0;i<60;i++) {
        libusb_bulk_transfer(handle, 0x01, headerPkt, sizeof(headerPkt), &tfrsize, 1000);
        libusb_bulk_transfer(handle, 0x01, dataPkt, sizeof(dataPkt), &tfrsize, 1000);
        usleep(1000000);
    }

    libusb_release_interface(handle, 0x00);
    libusb_close(handle);
    libusb_exit(NULL);

    return 0;
}

of course its possibly Ableton could change this in future firmware versions (though they didnt change the Push1 protocol, so perhaps they wont).
someone asked how I got the original USB trace... well there are a few ways, but the way I do it, is to run Windows in a virtual machine using VMWare, VMware has a neat 'trace' usb feature which will log all USB packets to its log file. so fairly simple and easy to repeat if Ableton do change the protocol

[thetechnobear]

On another forum, someone has also posted another solution:
https://github.com/net147/Push2Qml

This will render QML to a Push 2 using the same usb approach.
its for windows, but given QT is cross platform should be easy enough to port
note: Ive only just come across this, so Ive not tried it out or looked at it closely, but could be good for open source projects.

[DJ Warmonger]

What is screen resolution of Push 2?

[thetechnobear]

960 x 160 with 16 bit colour, see above for colour encoding scheme

[psylevation]

Any idea how to grab the display from Ableton Live so that we can change the display and still use the normal push functionality. P2D does it so it’s definitely possible. Unfortunately P2D is closed source so we can’t learn how P2D does it directly.