Hacking the Dell SX2210T, part 2.

Tonight, i’ve tryed to analyse more the header part, and understand how data part work. And… found something !

Header part

After a long session of touching the screen, and dumping the first 32 bytes, here is the current header decomposition :


    Idx Name            Values(hex)
    0   Format          5b
    1   Format          5d
    2   Request ID      *
    3   Unknown         1
    4   Unknown         c1,c3
    5   Unknown         1
    6   Unknown         0
    7   Unknown         1
    8   Unknown         *
    9   Unknown         *
    10  BufferType FL   [01][012]   00, 01, 02, 10, 11, 12 < order when no touch ?
    11  Unknown         0
    12  Unknown         1d,2b
    13  Unknown         1
    15  Unknown         bc,b6
    16  Unknown         [08][cd]    0 when touching ?
    17  Unknown         *           17/18 seem a value who stay the same in time
    18  Unknown         *           when touching (except changing them every 2s)
    19  Unknown         4*

    Special cases

    When len is 845, we always get same frame (32 bits):
    5b 5d b6 03 45 02 02 01 01 bc 01 15 00 6e 10 12
    02 01 10 13 02 01 10 11 03 01 10 14 03 01 10 15

    When len is :
        * 463 - 4(c7) - 10(10)
        * 471 - 4(c7) - 10(11)
        * 467 - 4(c7) - 10(12)
        * 457 - 4(c1) - 10(00)
        * 465 - 4(c1) - 10(01) 19(4d 4e)
        * 467 - 4(c1) - 10(01) 19(4c 4d)
        * 463 - 4(c1) - 10(01) 19(4d)
        * 465 - 4(c1) - 10(02)
        * 469 - 4(c7) - 10(12)

You might not understand at all the header, cause everything is Unknown (i don’t understand too.) But i’ve understand that the data part is changing from the byte 10. The 6 differents values represent a data channel :

  • 0x00: Unknown (maybe a sync signal ?)
  • 0x01: Sensor 1 signal
  • 0x02: Sensor 1 signal (nearly the same as 0x01, but not :/)
  • 0x10: Unknown (maybe a sync signal ?)
  • 0x11: Sensor 2 signal
  • 0x12: Sensor 2 signal (nearly the same as 0x11)

Data part

And… to understand more the data part, i’ve tryed to draw the data part on a line (green = 0x01, blank = 0x02): X represent the index (starting from 20), Y value represent the byte at the index :

I’ve tryed to convert data to {unsigned|signed}{short,int,float}, without success.

And i’m stuck. I see thing changing fast, i see position of my finger on the data. Do i need signal analysis ?
So, i’ve write to nextwindow, and ask more information about protocol part, and analysis part. I hope they will respond to me 🙂

8 thoughts on “Hacking the Dell SX2210T, part 2.

  1. Antonio Petruzziello


    Did you ever have any luck figuring out the protocol for the nextwindow panel? I’m trying to get this panel to work on my linux system.


  2. tito

    Nope, as i said on my last post, i’m not good at signal analysis, and i found nobody to help me on this stage 🙂
    So, i’ve switch to Acer 230H, dual touch, and USB HID compliant. It just work out-of-the-box with kernel 2.6.34 !

  3. Eric

    Where might I find the “Acer 230H, dual touch”? I can find the Acer T230H and that looks only to be single touch.

    Any help would be great,

  4. Eric

    Is there a set of instructions you used to get multitouch working? Because I have the monitor now and can only get single touch working.

  5. tito

    If you are on Windows, nothing required, it work out of the box.
    If you are on Linux, you need at least 2.6.34 kernel. Then, you can use some multitouch app, but that’s a pain in the ass. I’m using PyMT (of course), and work with one line configuration for the screen.
    I’ll not explain how to make it work on linux, all the job is done by enac team, so read and follow all informations : http://lii-enac.fr/en/projects/shareit/linux.html
    Good luck 🙂

  6. Kresnik

    I recently bought one of these, and have been working on this too. You’re the top google hit, so I’m going to post here if that’s ok. Note that all u16s are big endian.

    Framer Header (8 bytes)
    u16 syncHeader Always 0x5b5d
    u8 packetID Packet ID
    u16 packetSize Not actually correct by bytes, based on pixel count (see below)
    U8 portNumber Always 1
    u8 command Always 0
    u8 protocolID Always 1

    Camera data (11 bytes)
    u16 timestamp Used for double clicks, held touches
    u4 Camera 0 or 1, one camera on either side of monitor
    u4 led 0, 1, or 2 – not quite sure what it means, but 0 is handled slightly differently
    u16 PixelStart Alternates between 0x32 and 0x16 for me. Possibly added to each pixel value in the waveform
    u16 PixelCount Number of pixels, one camera has slightly more pixels
    u8 FrameInfo I usually see 0x0c (12) or 0x0d (13) – If This is, the pixels in the waveform are in reverse order
    u8 unknown
    u8 unknown
    u8 BlackLevel Packet rejected if < 0x0d

    Waveform (remainder)
    Pixels are 1 byte each, with the exception of a special marker: 0x80. In this case, the following pixels 2 pixels are used. This is also used when the pixel value should be 0x80.
    5c = 0x5c
    80 0a 50 = 0xa50 – Note: values may not exceed 0x3ff for reasons I don't fully understand
    80 00 90 = 0x90 – This happens often, again for reasons I'm not sure of
    80 00 80 = 0x80

    One guess on is that the PixelStart value needs added to all or some of the pixel values. This could explain why 0x90 is often escaped when it doesn't need to be.

    The cameras are across from each other, so the waveforms are somewhat inverse. Each complete waveform consists of 6 samples (camera 0 and 1, led 0, 1, 2). These values are interpolated in a way I don't fully understand, but hopefully someone out there knows more than I do.

    Please feel free to contact me Kresnik7@gmail.com

  7. tito

    Very very interesting and a lot of progress ! Unfortunatly, i’ve give my screen to a friend, and buy an Acer T230H. Same technology, but HID compliant. So i can’t help anymore. Keep up your very good work 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.