Wrong packet size on Alienware 15 R3

[Celelibi]

I have an Alienware 15 R3. The USB device that controls the LEDs has ids 187c:0530 just like in the issue #8. After some tests, it looks like it takes 12 bytes blocks instead of 9, and the colors are indicated with 1 full byte per channel, instead of 4 bits. With, of course, the usual region ids that are not exactly right.

For various reeasons I will probably not make a PR to fix this. However, I would like to raise to your attention that if the current code is correct, there are at least two devices in the wild with the same vendorId:productId that uses a distinct protocol.

Is it true? Has someone with an M17X R4 tested AlienFxLite? Or has the product ID just been added to the list hoping the protocol would be close enough to produce something useful? I'm not blaming anyone, I would definitely prefer to learn that PR #11 was under-tested than learning that the manufacturer reused a product id for incompatible devices.

Best case scenario: PR #11 was buggy. And I would suggest moving the data length completely in java instead of having it both in C and in Java. And maybe even let the write function do the block padding. (Some calls to fill are currently missing.)

Worst case scenario: The product id has been reused. And I might suggest identifying the devices with a GET_STATUS in a data block of length 9 and check if it returned an OVERFLOW error.

[taoari]

@Celelibi Will you share your Controller file for Alienware 15 R3? And also any instruction for finding the mappings? My output of lsusb -v is the following:

Bus 001 Device 003: ID 187c:0530 Alienware Corporation 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               0.02
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x187c Alienware Corporation
  idProduct          0x0530 
  bcdDevice            0.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.01
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      56
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x000a  1x 10 bytes
        bInterval              10

[bchretien]

@Celelibi this issue is known, cf. this similar discussion. The problem is that without the hardware at my disposal, it is a bit difficult to test anything on my side. If we can test the data length at runtime, this would solve part of the problem. Still, if the mappings are different, we're going to have a problem.

[Celelibi]

@taoari The reasons I probably won't make a PR, is because I'm not interested in using AlienFxLite per se. I used it to test and understand the protocol. But in the end, I'm interested in making my own CLI tool so that I wouldn't have to start a X server to control the LEDs and could call it from scripts. And I'm not a big fan of Java. Loading the whole JVM and the JRE just to do something as simple as writing a few bytes to a USB device is really overkill.

Beside, it would also require modifying various parts of the code to make it work with 9 or 12 bytes packets. And I'm not really comfortable doing that.

But I will definitely provide all the informations needed to write a controller for AlienFxLite once I have them. And yes, my lsusb output is pretty much identical to yours.

@bchretien I guess you didn't write the class AlienFXEngine and wouldn't know why there are two runs of commands one with the saveNextInstruction and one without it? Right?

[bchretien]

I merely maintain the code base, I'm not the original developer. If I had to do things from scratch, I would do things very differently (C++ or Python lib with CLI client and optionally Qt client). There are some projects that attempt to do this (e.g. this for a CLI client), but I don't know if any of them is still active.

I'm not on my Alienware laptop much, and I rarely change the lighting setup, so AlienFxLite does the job, but if you're motivated, feel free to make a cleaner and more robust client, and I'll add it to the README as an existing alternative :)

[ghost]

I have a 17 R4 hardware if there is anything I can provide. Who cares what the software is written in, it's not something you'd use often. My hardware persists in the settings across reboots.

[Celelibi]

@bchretien Yes, I saw a few other projects to control the LEDs of Alienware laptops. They helped me understand the protocol a bit better, although it mostly looks like everybody copied on everybody.

@vowell Who cares? I care. It might not be something you would use often, but think about all the things you could do if the LED configuration was just one command line away. You could make a yellow flash every time you receive a mail. You could change the hue w.r.t the CPU temperature. You could change the blink/morph speed according to the current CPU load. You could change the intensity of the LEDs according to the brightness of the surrounding environment if you can catch it with the webcam or other sensors. Heck, you could even show your mood on the LEDs if you can interpret it from the webcam! You could even do something as simple as darkening the keyboard after a few seconds untouched (I can't believe this is not builtin).
BTW, what's the deviceid of your controller?