GL860 driver code

More webcam hacking. I can get proper images now, minus colour. I’ve published my code: git:// (gitweb interface). Nightly snapshots will be generated here.

So far it just includes my experimental programs to try and make sense of the protocol and capture images. It works, sort of, but there’s a lot to be done. It also requires libusb-1.0 due to the isochronous endpoint. Only try it if you’re interested in development or are just very keen and curious.

17 Responses to “GL860 driver code”

  1. Sur3 Says:

    my images are not really proper on my medion laptop:
    this is the best i get with the capture_x11:

    but the picture always moves, so i also get something like this:

    capture_to_files only gives me this, just as capture_x11 when startet (i think the camera needs some time to capture):

    also i have the feeling, that i only see a small part (the left upper corner) of the viewport of the camera and it is upsidedown


  2. Jack Malmostoso Says:

    Hello Daniel,

    thank you for your effort. I have an Asus Z37E running Debian Sid AMD64 and I tried compiling this first version of the code, but I can’t seem to do it.
    libusb is version 0.1.12-9 and the includes were a bit different than (I’m guessing) Gentoo, so I had to tamper with symlinks to even start the make process.
    Anyway: if someone can provide 64bit binaries I’d like to try them out.

    Thanks, I’ll be glad to help with the testing.

  3. Daniel Drake Says:

    Sur3, thanks for the feedback. There is work to be done…
    Jack, you need libusb-1.0, not 0.1. libusb-1.0 is unreleased software, you have to get it from development repositories.

  4. Jack Malmostoso Says:

    @Daniel: Thanks for the heads up… I’d have never noticed that!

    I’ll do the testing right away!

  5. Jack Malmostoso Says:

    I installed libusb-1.0 from git and both capture_to_files and capture_x11 compiled.
    I have to invoke them as root (I’m guessing it is expected) and the results are:

    - capture_to_files: I left it running for a few minutes, but all I get is continuous scrolling of code, no images are saved anywhere (I am doing it wrong, obviously)
    - capture_x11: this gives me a nice black window (I am on Intel graphics, maybe it’s related?):

    In both cases though, the blue led on the camera turns on, so it does something.

    Any advice? Thanks again.

  6. Daniel Drake Says:

    If capture_to_files doesn’t get anything then the X version won’t either. I’m not sure why it isn’t working, but I’m not yet ready to start diagnosing problems from other people’s hardware. Thanks for trying it anyway. You aren’t really missing much at the moment.

  7. Jack Malmostoso Says:

    Of course, don’t worry, I was just curious to see if I could get something out of the cam.
    I’ll check back regularly for updates.


  8. Sur3 Says:

    @Jack Malmost:
    Well, I capture the pictures in usermode, that’s what libusb normaly was for (an usb usermode-interface), perhaps the files have the wrong permission or you need to be in the usb group, but i think you wont get a pic in usermode either.

    I’m right, I only see the upper left corner, and the picture is streched vertically, i think this is because of the bayer-filter, i’ll try different bayer-filters-patterns the week..
    …and i forgot to mention: great work!


  9. Sur3 Says:

    lol, i got some right colors very simple ( )
    i just changed the display_frame() i’m sorry, i know this code is ugly and i should nopaste it, but here it is XD :

    static void grey2realyuv (unsigned char *grey, unsigned char *YUV, int num) {
    int i, j;
    int y0, y1, u0, u1, v0, v1;
    int gval;

    for (i = 0, j = 0; i < num; i += 1, j += 4)
    //gval = grey[i];
    //GREY2YUV (gval, y0, u0 , v0);
    //gval = grey[i + 1];
    //GREY2YUV (gval, y1, u1 , v1);
    YUV[i] = grey[i];
    YUV[i + 1] = 0;
    YUV[i + 2] = 0;
    //YUV[j + 3] = (v0+v1)/2;

    static void display_frame(void)
    unsigned char rowbuf[IMG_WIDTH];
    int i;

    if (adaptor < 0)

    for (i = 0; i < IMG_HEIGHT / 2; i++) {
    int offset = i * IMG_WIDTH;
    int swap_offset = IMG_SIZE – (IMG_WIDTH * (i + 1));

    /* copy top row into buffer */
    // memcpy(rowbuf, imgbuf + offset, IMG_WIDTH);

    /* copy lower row over upper row */
    // memcpy(imgbuf + offset, imgbuf + swap_offset, IMG_WIDTH);

    /* copy buffer over lower row */
    // memcpy(imgbuf + swap_offset, rowbuf, IMG_WIDTH);

    //grey2yuy2(imgbuf, framebuffer, IMG_SIZE);
    grey2realyuv(imgbuf, framebuffer, IMG_SIZE);

    xv_image = XvCreateImage(display, info[adaptor].base_id, FORMAT,
    framebuffer, IMG_WIDTH, IMG_HEIGHT);
    XvPutImage(display, info[adaptor].base_id, window, gc, xv_image,

  10. Sur3 Says:

    lol, i’m to tired i think, cause as you see all the grey2realyuv(imgbuf, framebuffer, IMG_SIZE); does is memcpy(framebuffer, imgbuf, IMG_SIZE);
    so the picture from my camera seem already to be kind of yuv :-D
    sorry for the previous comment

  11. Daniel Drake Says:

    The windows software I used to capture sniff logs from said it was capturing in YUY2, so that makes some sense. But the data that comes back for me is not straight YUY2, the colours are all wrong if I just render imgbuf with YUY2 space. Last time I checked I did not have green skin.

    I added a sample image (rendered as greyscale) to the git repo if you want to play with the kind of data that I get…

  12. Sur3 Says:

    ok, it is a simple bayer-pattern:
    |green | red |
    |blue | green|
    i developed a simple assembler-algorithm to interpolate some color ( )
    here is a transkription to C:

    static void unbayer2RGB (unsigned char *bayer, unsigned char *RGB) {
    int x,y,z;

    for (z = 0,y = 0; y < IMG_HEIGHT; y+=2){
    for (x=0; x < IMG_WIDTH; x+=2,z+=3){
    RGB[z] = bayer[x+1]; //Rot
    RGB[z+1] = ((bayer[x]+bayer[x+1+IMG_WIDTH])/2); //Grün
    RGB[z+2] = bayer[x+IMG_WIDTH]; //Blau

    but the resulting picture is only half as with and half as height that could be better with an other interpolation algorithm…
    perhaps first of all you test it, i don’t know if you can output RGBs, or do you need YUY2?


  13. Daniel Drake Says:

    woohoo, that looks like me!
    Great work, thanks! I’ll try and merge it into the code soon.
    RGB is great, can write it to PPM like that, and I’ll figure out how to convert it to YUY2 so that we can display it with Xlib.

  14. Sur3 Says:

    oha, i see two off-by-one error in the two loops ;-)

  15. Sur3 Says:

    ok, improved interpolation-loops, image has size height-1 and width-1 now, and some ugly variable errors corrected, i hope its correect now ;-) :


  16. dsd’s weblog » Blog Archive » GL860: more devices, colour images Says:

    [...] got a seemingly different image format as well. He also took an image that came back from mine and decoded the Bayer colour space, so I can now get images back in [...]

  17. O Lorin Says:

    My last info on the 0503:F191,

    with the log I did and Daniel’s log/source, I succeeded in having a 640×480 color image. It is also Bayer.
    Quite amazingly, the first image produced by the cam is a 640×480 view of what is the bottom left quarter of the normal image, sometimes the next image is normal apart to be vertically flipped and the next ones are normal.

    @dsd : I made a C program to map the USBsnif log to a shorter log and a C code with some anotation. It can help to understand a log. I’ll send you the source code and a “copy_to_files” version for my webcam model. Today I
    tried to understand the syntek driver to integrate my work in however it seems to me quite difficult and the USB is differently managed…
    USBsniff and USBsnoop seems to be the same program, they’re was just on link to donwload it.
    Affichageb.exe comes from this link : .
    I forced the application to quit after it has connected the webcam.

Leave a Reply

You must be logged in to post a comment.