Support for Alienware 17 R4

[mgruben]

Like #16, I'm trying to add support for a currently-unsupported Alienware model, and I'm encountering some difficulties.

After following the instructions in the Readme, I'm able to run sudo alienfx-gtk, however if I then click "apply", the following error results:

ERROR:root:read_packet: [Errno 75] Overflow
ERROR:root:write_packet: [Errno 32] Pipe error
ERROR:root:read_packet: [Errno 75] Overflow
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "build/bdist.linux-x86_64/egg/alienfx/ui/gtkui/gtkui.py", line 212, in set_theme
    self.controller.set_theme(self.themefile)
  File "build/bdist.linux-x86_64/egg/alienfx/core/controller.py", line 259, in set_theme
    self._wait_controller_ready()
  File "build/bdist.linux-x86_64/egg/alienfx/core/controller.py", line 143, in _wait_controller_ready
    ready = (resp[0] == self.cmd_packet.STATUS_READY)
TypeError: 'NoneType' object has no attribute '__getitem__'

[mgruben]

For that line mentioned, I think that the issue is that resp is None, and in Python2, attempting to index into a None type yields the TypeError: 'NoneType' object has no attribute '__getitem__'.

Now, if I change line 143 in controller.py to:

            if resp is not None:
                ready = (resp[0] == self.cmd_packet.STATUS_READY)

then recompile, I succeed only in giving myself an overflow:

ERROR:root:read_packet: [Errno 75] Overflow
ERROR:root:write_packet: [Errno 32] Pipe error
ERROR:root:read_packet: [Errno 75] Overflow
ERROR:root:write_packet: [Errno 32] Pipe error
...

^CTraceback (most recent call last):
  File "/usr/bin/alienfx", line 11, in <module>
    load_entry_point('alienfx==2.0.5', 'console_scripts', 'alienfx')()
  File "build/bdist.linux-x86_64/egg/alienfx/ui/console/main.py", line 78, in start
  File "build/bdist.linux-x86_64/egg/alienfx/core/controller.py", line 260, in set_theme
  File "build/bdist.linux-x86_64/egg/alienfx/core/controller.py", line 141, in _wait_controller_ready
  File "build/bdist.linux-x86_64/egg/alienfx/core/usbdriver.py", line 65, in write_packet
  File "build/bdist.linux-x86_64/egg/usb/core.py", line 1043, in ctrl_transfer
  File "build/bdist.linux-x86_64/egg/usb/backend/libusb1.py", line 883, in ctrl_transfer

[mgruben]

Using the logging function, the following is the relevant portion of the output:

DEBUG:root:USB device acquired, VID=0x187c, PID=0x530
DEBUG:root:SENDING: GET_STATUS
ERROR:root:read_packet: [Errno 75] Overflow
DEBUG:root:SENDING: RESET: all-lights-on
ERROR:root:write_packet: [Errno 32] Pipe error
DEBUG:root:SENDING: GET_STATUS
ERROR:root:read_packet: [Errno 75] Overflow

Note that, for me, lsusb | grep Alien yields Bus 001 Device 002: ID 187c:0530 Alienware Corporation

[Purg]

I just got one of these laptops also (I'm assuming we're both using the 2016 17R4).

If we are talking about the same laptop, did you base a new controller class on one of the existing controllers? I don't think the M17R3 is a good base for comparison due to lights being fairly different, partly due to that being a really old (e.g. there are no HDD lights on my 17R4). That could be one of possibly more issues.

[Purg]

Not being super good at this, where are the USB in/out request and AlienFX command codes specified?

[mgruben]

@Purg, you're correct that the M17R3 is likely not a good model for the 17R4, so I'm thinking that's where the compatibility issue lies here.

I think this is a 2017 model; it seems to match this product review from CES 2017.

[Purg]

That does look like what I have. Part of the problem compared to those older modes is that the lights are different (e.g. there are no HDD/cap/num lights section).

The initial problem before lights are even references the code is that the USB interface ping check fails (that first OVERFLOW we're seeing). So, it might be the case that the USB codes for the device are just outright different. I'm reformatting my computer to dual-boot windows in order to install wireshark and sniff out the USB messages (how these codes were introspected in the first place so long ago). Hopefully I can figure something out...

[mgruben]

Relatedly, here is a repo of packet captures between AlienFX and the Alienware 17 R4.

Unfortunately I'm not wizardly enough to know how to use them yet, but hopefully someone else finds them useful.

[trackmastersteve]

Sorry, I've been busy with a lot of other projects and haven't had time to respond until now. @mgruben have you already followed the 4 steps to add support for the m17xR4? By the info you posted, your id codes are "ID 187c:0530". You should be able to read those pcap files to get the correct zone locations for that Alienware model. If/when you get it working, please feel free to send in a pull request.

[Dutisto]

Hi guys, i'm currently working on this. The error occurs when the program tries to read the packet from the USB device during the _ping process. I'm trying to find a way to resolve this, but it's kinda hard :(

[trackmastersteve]

Thank you @Dutisto for helping with this issue!

[Grimish-ng]

Thanks Dutisto,

As for myself and being a huge Open Source fan I'm also going to take a crack at this and see if we can get this working for this model. Let me know if you have made any progress or have information to shed on this in the meantime. I'm beginning work on it immediately and will fork the project eventually for all the lights as well as functions.

[trackmastersteve]

Thank you @GrimBShrout! And pull requests would be greatly appreciated.

[derco0n]

any progress on this?

I have the same issue and have no idea where to look. ...furthermore i am not yet very familiar with python

USB communication sequence seems to differ between alienfx and originial windows software:

_left side shows live usb monitoring when using alienfx, right side is from the capture files posted by "mgruben"

But please let me know if i can help.

[derco0n]

found something about this in another alienfx-project.

Seems that the controller of the 17R4 (0x187c, 0x530) needs 12 bytes instead of 9 as in the previous models.

"[old models]...docs and provided light configs assume 4 bit color per channel, but the 0x0530 revision has 8 bits of color per channel..."

Have a look at this posting (section "lights"): http://lemnwezl.org/aw17_r4_debian9.html

[derco0n]

finally it seems to be possible.

created a new cmdpacket.py with modified colorsizes (12 instead of 9 bytes). some other modifications werd needed, but i am able to set the lightning-colors through this on my 17R4.

Still under heavy development, but you can have a look under: https://github.com/derco0n/alienfx @trackmastersteve if pull requests are still appreciated, i will do when work is done...

[Grimish-ng]

Sweet. This can't be anything BUT helpful! I am still working on this as time has been short in recent days. I won't give up though.

On Tue, Jul 3, 2018 at 1:48 PM, Dennis Marx notifications@github.com wrote:

found something about this in another alienfx-project.

Seems that the controller of the 17R4 (0x187c, 0x530) needs 12 bytes instead of 9 as in the previous models.

"[old models]...docs and provided light configs assume 4 bit color per channel, but the 0x0530 revision has 8 bits of color per channel..."

Have a look at this posting (section "lights"): http://lemnwezl.org/aw17_r4_debian9.html

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/trackmastersteve/alienfx/issues/19#issuecomment-402240224, or mute the thread https://github.com/notifications/unsubscribe-auth/AKAMN21O3H4BdinAuwloHBeLntfqzH3fks5uC65tgaJpZM4Nu_2R .

-- Jason B Shrout Email: Jason@Shrout.net

[derco0n]

While testing zone-codes it seems to me, that there are much more codes on the line than we know about.

Keyboardcodes seems to work, but i still have no idea about the Logo, alienhead, powerbutton, touchpad, and the light bars on the sides.

Some codes i tried produced strange behaviour like flashing powerbutton lightning, or activating multiple zones with one code (some of them in different colors...)

Any suggestions?

[Grimish-ng]

Looking at this from an engineering and features standpoint we know that not all of these functions are required or even needed for what we want to accomplish...

There were many added routines that were added to cycle during gameplay or for simple quick configuration that was most likely not to be saved.

Such as the flashing of "Red" are programmed in some games to call that function when you are critically low on health or near death.

What we should probably be looking at is what is required for quick, easy configuration of turning on/off lights in the zones and then next the ability to change colors building this with more and more added features as time moves forward.

derco0n, what you are testing is probably accurate and by design - calling those routines are most likely working as needed - that are just not necessarily all required for what we need them for (yet)

But hey - at least we know they work! Nice Nice!

[derco0n]

It seems that other models as the 13R3 have newer controllers too, as they have a similar issue which can be fixed by using 8bit per color...

May be we can fix all of them in one job...

[derco0n]

just wanted to tell: i'm still working on this. found some zone codes.

interesting fact: they seem to follow some kind of pattern (they are doubling...):

e.g. ...

0x0001 Keyboard right => *2 = 0x0002

# 0x0002 Keyboard middle-right => *2 = 0x0004
# 0x0004 Keyboard middle-left => *2 = 0x0008
# 0x0008 Keyboard left => *2 = 0x0010 ... and so on
# 0x000F Keyboard: all fields <= interesting: 0x1 + 0x2 + 0x4 + 0x8 = 0xF

...

[trackmastersteve]

Nice work @derco0n. Thank you so much for the research and the code you are working on. It will be greatly appreciated by many.

[derco0n]

@trackmastersteve you just got a pull request...

it is working on my Notebook now.

[trackmastersteve]

Pull request accepted. Thanks again @derco0n.

[trackmastersteve]

So far so good on the older m17x R1

[derco0n]

i think this issue could be closed...