15R4 Support (0876) #41
Comments
|
Please try newest version and test if zonescanning might help you creating your own definition. If you could create a controller for your device, i bet a pull request would be appreciated. |
trackmastersteve
changed the title
|
This would be really useful for me as well. @derco0n if it helps, user @Gurjot95 commented in another github issue for the alienware 15 R4 with the following:
|
I have an 17R3 and experienced the same issue (12 vs 9 Bytes). Please sync to latest version and try to build a controller for your device using the zonescanner functionality. |
|
Thank you @derco0n. I tried running zonescanner for everything, but wasn't successful. I may have done something wrong, as it seems to get stuck every time it just says "Testing zone X". When I send CTRL-C, it sensibly says If it helps, this is the message that appears when I run Thank you. |
|
Thanks for your reply. The zonescanner is a very young function, which i could only test on my laptop, a 17R4.
I built it under Python3, so please test with Python3 instead of 2.7.
If that fails too, please read below:
The scanner is built to test the zones, which in my case seem to follow some pattern (Have a look at https://github.com/trackmastersteve/alienfx/blob/master/docs/Knowledgebase/reverse-engineering-knowledgebase.txt ). However, if your controller is recognized, i think your zonecodes and their pattern might be a liitle different. If that is the case, only someone having a device like yours could help determine the correct zone codes.You may try to find them manually.Am 21.11.2018 21:35 schrieb Alejandro Saucedo <[email protected]>:Thank you @derco0n. I tried running zonescanner for everything, but wasn't successful. I may have done something wrong, as it seems to get stuck every time it just says "Testing zone X". When I send CTRL-C, it sensibly says ERROR:root:Error while testing current zone... and then asks is anything blinking now? (y/n):, but the answer is no. This repeats throughout all the zones. I waited up to 5 minutes for one, so unless it would take longer to test each?
If it helps, this is the message that appears when I run sudo alienfx:
You are running alienfx under Python-Version: 2.7.15rc1 (default, Nov 12 2018, 14:31:15)
[GCC 7.3.0]
ERROR:root:No Alien FX controller, defined by a supported model, found!
would you like to perform a zonescan? (y/n):y
Performing zonescan...
Welcome. This will help you to scan for alienfx-controllers and their lightning zones.
Found device "0x187c / 0x0550". - Testing zones...
Testing zone "0x0001"
Thank you.
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I'm also having this issue. I also have an Alienware 15 R4 and it does the same exact thing. I can try to help if given instructions on what to do. |
|
same here (CTRL+C) |
|
Bus 001 Device 002: ID 187c:0550 Alienware Corporation |
|
I have done some debugging and found more light on this issue. It seems that the reason why it gets stuck every time it says The class I am still not 100% sure if this fixes the issue to a point where a proper zone-scan can be carried out, but it seems there may need to be modifications for a proper zone scan to be carried out. I have made available the changes I made through this branch in a fork https://github.com/axsauze/alienfx/tree/alienware_15_r4_fix. You can see the diff here PR https://github.com/trackmastersteve/alienfx/compare/master...axsauze:alienware_15_r4_fix?expand=1 A question for some of the core contributors (@derco0n, @trackmastersteve + @xenatisch), what do you think this may be due to, am I missing something or does the 15r4 has different hardware requirements for package files? If so happy to perform a zone search, but I need to understand a bit more of when it is working so the zonesearch can be carried out efficiently. |
|
@axsauze still not working |
|
i just got my fingers on a 17R5 which uses the same controller. Working on a solution. |
|
@derco0n i hope you will get things working! |
|
I'm not sure how far @derco0n has gotten at the moment, but I can tell you that the newer controller (0x0550) has a completely new protocol. The packet length is 33 bytes, and it requires multiple packets for many of the operations. For example, if you send the following two packets (hex): That will cause all the lights to go out (except the macro keys and power button) It appears that the command structure goes a bit like this: For the second line, the 0x64 is the light intensity, but it's backwards, as 0x64 refers to 0d100. Setting the intensity byte back to 0x00 will turn the lights back on. Maybe is a %Dimming value. The 0x0d is referring to the number of zones that will be affected (14). The zones are as follows (all in hex): We 'can' write the packets using hidapi (which is way easier), but for some stupid reason, none of the hid drivers (or hidapi itself, or the hidraw device) can issue a GET_REPORT control request to request an input report. So we can't read the status back. I have half a mind to rebuild hidapi against libusb myself and add that code. Sigh...Maybe I'll just write a kernel driver off of the hid core which CAN. Here's my (terrible) python3 code to send the two messages above: device=hidapi.Device(vendor_id=0x187c, product_id=0x0550) Much easier than messing with raw usb messages. I've captured packet dumps of most of the operations available in AWCC with one exception (RainbowWave on the Keyboard), and I only have the standard keyboard, so my protocol analysis is slightly incomplete. I can send what I know if anyone's interested. |
|
Good job!!! for the user who cannot get this script to work: sudo apt install python3-hidapi sudo chmod 775 alienfx.py DONE your leds are off... |
|
Thank you @kmescher and @DenDeze. I have tried running the command you provide @DenDeze but unfortunately I am getting the following exception: When I run the python3 prompt, it fails when running the first line: I am using Python 3.6.7 with the following details: Is there a requirement on the version of Python for hidapi to work correctly? What version of Python are you running? Thanks. |
try running sudo apt-get install python-dev libusb-1.0-0-dev libudev-dev (please report back if this works then i update my post) also i updated my script so can use it as sudo python3 alienfx.py (00-64) |
|
I've ran I have also tried installing the packages listed in the "hidapi package in Ubuntu" here https://launchpad.net/ubuntu/+source/hidapi Finally I tried installing cython3 using sudo apt install cython3. I am still getting the same error. It does seem to be an issue building the bindings with the C/C++ library. Have you seen this issue before? Perhaps I could try building hidapi from source. Alternatively, it seems that you are using Python 3.7.2, would that perhaps be a dependency of minimum Python version for HIDAPI? Thanks. |
|
l will update my script with dim levels and zones, again thank you @kmescher for the exampel code. |
else try this: i hope it works |
|
I had a look at the I tried calling it by adding my serial_number as The call is now providing the following traceback: Unfortunately it seems that for some reason my hidapi is not able to get access to the device. I also tried running it with For context, the code on hidapi.Device is the following: class Device(object):
def __init__(self, info=None, path=None, vendor_id=None, product_id=None,
serial_number=None, blocking=True):
""" Open a connection to a HID device.
This can be done either from a DeviceInfo object, a device path or
a combination of vendor id, product id and an optional serial number.
If no serial number is passed, the first matching device will be
selected.
By setting :param blocking: to True, all reads will be blocking by
default, otherwise they will return `None` if no data is available.
:param info: Information about the device to initialize
:type info: DeviceInfo
:param path: Platform-specific path to the device (e.g.
`/dev/hidraw0` on Linux)
:type path: str
:param vendor_id: Vendor ID
:type vendor_id: int
:param product_id: Product ID
:type product_id: int
:param serial_number: Device serial number
:type serial_number: str
:param blocking: Enable blocking reads by default
:type blocking: boolean
"""
if info is not None:
self._device = hidapi.hid_open_path(info.path)
elif path is not None:
self._device = hidapi.hid_open_path(path)
elif not (vendor_id is None or product_id is None):
self._device = hidapi.hid_open(vendor_id, product_id,serial_number)
else:
raise ValueError("Must provide either a DeviceInfo object, 'path' "
"or 'vendor_id' and 'product_id'.")
if self._device == ffi.NULL:
raise IOError("Could not open connection to device.")
if not blocking:
hidapi.hid_set_nonblocking(self._device, 1)
...Please let me know if you have any ideas on how this could be addressed. Otherwise I will update if I find a walk-around. |
Open a connection to a HID device. It either seems like your device is just not found / with or without serial... what does: |
|
@DenDeze thanks for the docstring, seems the device is indeed not found. I actually searched for the serial number based on my service tag and tried to add it manually as a string, but indeed it still didn't find the device. When running that command I get |
|
@axsauze the line that is shown is correct, your usb device is indeed found so the problem is not in your hardware. Do you run the python scripts with sudo? i get the exact same error when not running the commands with sudo... Serial is not shown with lsusb. please run commands with sudo and dump a complete shell output please. |
you can actualy run the same code with python2
make new file:
copy in alienfxp2.py: make the file executable:
run like:
|
|
@kmescher can you provide more codes please? |
|
TL;DR: I completed a much more comprehensive look at how the new communication works after I did my first post. This will be a VERY long post. You have been warned. Since the replies coming back from the controller are sometimes interesting, you may not want to use hidapi (since it doesn't send the GET_REPORT control transfer; neither does hidraw, and hiddev is a pain; Grr......). Thankfully, you can repeat the same idea with the following code using python and libusb (I saved as hidreport.py) import usb def hid_get_input_report(dev,length,report_id=0): Then here's my stupid test code: #!/usr/bin/python3 device=usb.core.find(idVendor=0x187c, idProduct=0x0550) Much easier.... you type the command you want, it automatically pads it, then prints out the reply. Also to avoid a ton of dmesg output when working w/ libusb, you need to keep the HID driver from capturing this device. Put this into /etc/modprobe.d/ignore-awelc.conf (as root): options usbhid quirks=0x187c:0x0550:0x0004 Then type 'depmod -a' as root, then type 'update-initramfs -u' as root. And...since you may want non-root users to mess w/ the LED's, you put the following into /etc/udev/rules.d/00-aw-elc.rules: Then make sure that your chosen users are in the 'plugdev' group. I created the symlink in case I needed it later. Modify as you like. Then reboot to make sure everything takes effect properly (or rmmod and modprobe, etc) The modprobe and udev lines should solve a number of the issues seen above (can't find device, can only work w/ sudo, etc) Now onto the API.... With previous API's, much of the control could be done with one command (command, zone, parameters). This is no longer true. There are a number of different command sequences, and the controller doesn't like it when things are done out of sequence. Thankfully, the lovely developers at Dell used an easily-decompilable (is that a word?) language (C# maybe?), so I was able to eek out most of the commands by staring at and meditating over the produced source code. That being said, terminology below will be copied from the analyzed code. To start, I'll list the structure of a single 33-byte packet (padded w/ 0x00 when needed): 0x20 - Get report (Status & info queries) For command 0x20, the first parameter is a single byte sub-command. There don't appear to be any additional parameters (with most), but you will get different replies. The reply echoes the command, and tacks on the extra information after that. Here are the subcommands: 0x00 - Get firmware version - Returns 0x 01 00 07 (corresponds to version 1.0.7 of the firmware, which seems to match what the AWCC tries to flash during install; more on that later) Are you confused yet? No? Moving on.... Major commands 0x21 and 0x22 deal with the animations. 0x21 deals with "user animations", where the user wants to set a particular action for a particular zone not dependent upon power states. Kind of like a "running" config for those who have messed with Cisco IOS. The format of the command is the same as 0x22, so we'll talk about the structure first. Like 0x20, there's a subcommand. But it's two bytes this time, followed by a two byte Animation ID, and a two byte duration. The subcommands are: The two byte animation ID's are as follows (power state animation ID's first) 0x0061 - Chassis & Keyboard zone running states (post-startup) Duration only seems to be set when setting the startup sequence state (set to 0d6000); my guess is how long the startup sequence runs before moving to the post-startup animation state (0x0061). 6 seconds seems right, so I'm guessing the value is milliseconds. When modifying power state animations, use major command 0x22. When modifying user animations, use major command 0x21. I'm not sure about setting the startup animation. I would expect use major command 0x21. NOTE: That's conjecture. I never saw a command to set the startup sequence in captured traffic. Major command 0x23 deals with zone selection. First you select the zones you want to apply the action on, then you specify the action. The command does not have subcommands. It has the following parameters: What are the zones? Here they are for the 17R5 w/ Std Keyboard: Not done yet... 0x00 - Color Two bytes for duration (in milliseconds; 09c4 is 2500 (long), 05dc is 1500 (medium), 01f3 is 1000 (short). You get the idea. For the color and pulse subcommands, you're done. For all the other effect types (Morph, Breathe, Spectrum, RainbowWave), you need more. But it's easy. For the next color in the sequence, you repeat the subcommand, another duration & tempo and then your next color. Here's what a few different effects will look like: Morph (fade from r1g1b1 to r2g2b2, then set color back): Breathe (fade from r1g1b1 to black): For spectrum, we have to fade across a whole bunch of different colors, and that won't fit into one command. So it's split in to multiple commands. Here's a long example: Next major command (0x26) is Set Dim. This one has been discussed a little bit, but this is the full breakout of the parameters: Major command 0x27 is Set Color. This appears to be only used for the macro keys; I haven't tried setting them with the other effects. This command also doesn't seem to work for any other zone; just the macro keys. As I said, major commands 0x25 (Set event), 0x28 (Reset), and 0xFF (Erase SPI Flash) don't seem to be used in the AWCC code, and at least 25 and 28 seem to reply with a bunch of FF's, so they may not be implemented. Though while playing, I was able to erase the default running config of the chassis and keyboard zones so they stayed in the startup animation (spectrum). So one of those may remove/erase animation code 0061 so that only the startup animation would play. It's really weird trying to type on a keyboard when it's running through the rainbow.... Knowing the definition of the commands is one thing. Using them is slightly different, but not hard. There is a definite sequence to the commands to make certain changes. Let's start with a running config change: For starters I'll only be affecting zone 01 (Alienware logo words inside the lid): If you want to set the same action for more than one zone, select more than one in the zone selection command. If you want to set different effects for different zones, you can do that too. Just select the zones, add the action, select different zones, add the action (and so on). The sequence only finishes when you use the Finish & Play animation command. When the service starts, it sets the values for each animation ID (I guess they were stored in the AWCC software and sent down just in case). For those it followed this sequence: It set up the power state animations first, then did the user default animation. So for each power state: Then for the user state (Animation ID 0061): I think that about covers it. I did capture the rainbow wave effect, but that is a mess of select one zone, spectrum effect, select another zone, spectrum effect (shift the color sequence slightly), and so on. Left as an exercise for the reader, because I don't feel like typing it here for now. If you're really interested, I suppose I could do it, but later (my hands are getting tired...) Edit: I forgot to mention flashing the firmware. The firmware is flashable on Linux, but not easy. In order to place the controller in update mode, you need to call some ACPI methods, which can really only be done by the kernel. So by adding some features to the alienware-wmi kernel driver I was able to place the controller into firmware update mode. At that point, the DFU utilities can prepare and upload the firmware to the device. Hopefully we don't have to do that very often, as at the moment it's VERY manual and icky. You can also brick your controller if you're not careful. |
|
WoW nice write up, still confusing ;( |
|
Happy St. Patrick's Day! Not being interested in writing a lot of raw hex, I wrote some python to take care of the hard stuff. Now it's a lot easier to explain how the protocol works. Bear with me for a moment: Each controller has supports a set number of "animations". I expect that all of them support the same number. Six of the animations are for power states, one for default (after the boot sequence), and one for either the non-default running, or the startup sequence. Each animation could be considered a memory "slot" that you can save to. Each animation can hold one or more "series" (not sure the maximum). Each series contains a list of zones and a flag for looping (which is almost always set to 1). Each series contains one or more actions (not sure of maximum), which is the sequential list of states that you want the LED's in that series' zones to change to. This opens up a large amount of versatility. Previous versions of the protocol (and the AWCC program in Windoze) have a limitation on what zones can be used to reflect the power state. This limitation doesn't actually exist on the controller. For example, my 17R5 shipped with only the power button changing when I changed power states. I have set the controller so now the power button and the outside Alien head show the current power state. So by doing the protocol manually, we have considerably more versatility than AWCC can offer us. Score! I'm not yet sure how to integrate this code into the alienfx source tree, as the controller is capable of more than the alienfx code can deliver as well. So for the moment, I've written a python class to make commanding the controller easier. Unfortunately, you still have to know the order of the individual commands. To change the config for a particular slot (animation), we do the following commands: Remove animation As stated in my previous post, each start series command contains: Each action inside an Add Action command contains: So if I wanted to change the config for the AC_SLEEP state (0x5B), I run the following commands: Since the write-up can still be a little daunting, I've attached the code I wrote to make my life easier. The files are as follows: elc.py - The classes for the ELC and an Action. These classes construct the individual commands and send them to the controller set_chassis_zones.py - A script which uses the ELC class to adjust the zones on my chassis (non-keyboard). Right now it's set to change the LED's from Green to White to Orange. Happy St. Patrick's Day! set_power_states.py - Similar, but sets up each of the six power states. Note that this one uses zones 0 (outside alien head) and 3 (power button) for the states. I can do this because I have removed zone 0 from the default_post_boot state (0x61). If you I didn't do that, zone 0 would be constantly fighting between the current power state and the default_post_boot state (not pretty). If you want to know the zone numbers and names for each of the individual models, you will need to know the platform ID of your controller (the python code has the ability to retrieve that for you). You will also need a json file with the zone definitions (which happened to be shipped with AWCC in the "DeviceFX" folder). Each json file has a 'jsondata' field which the base64 encoded JSON describing each platform. It includes the zone numbers, a textual description, as well as the VID and PID of the USB controller. Note for those of you with the advanced keyboard, that appears to have a separate VID and PID, and a large zone list. Have fun! :-D Share and Enjoy! |
|
@kmescher still a slightly confusing writeup(for me at least with no python experience) but after I studied and learned how the code worked I can fully control all of my lights! You're awesome man. :) |
|
@absythesince, could you provide your code |
|
@AbsyntheSyne I'd like to see the code you wrote up. I have the Alienware 15 R4 as well, and it would be really nice if my laptop wasn't a night light. |
|
@trackmastersteve if you could give me some help I might be able to create a working configuration file for this laptop. |
|
What would you need to make this configuration file? |
|
The zone codes for the lights. Which we haven't been able to grab because the zonescan thing hasn't been particularly helpful edit: never mind. I can't get anywhere, even if I had the correct zones. I've got it to recognise the correct hardware and see it in the GUI but changing the lights just maxes out my CPU.. @kmescher is there anyway you could make a GUI program for your code? It'd help a lot of people. |
What would you like to accomplish with the code? It's just edited from his, once you understand it by messing around with it, you can do anything with the controller. If only there was some way to make this into an application, but unfortunately I don't have the know-how to do it. |
|
@kmescher THANKS! perfect! @trackmastersteve any ideia if it is viable implementing this on the project? or would be better to just make a new one? Useful info: Hwinfo: My "custom.py" i created and execute on boot time as root: Keyboard is Blue while charging, lights are off on battery lights turn red if low on battery (theoretically, didn't test yet) |
|
@haroldLuiz how would one set the python script to launch on boot? |
I did add |
This is a lifesaver, thanks a lot! EDIT: And hard to find, too. "AlienFX Linux" wouldn't be enough - basically I've been lucky to get a match when looking for exact vid/pid... That 0x0550 device being so different from the previous versions really is a pain. The lack of documentation is also annoying! |
|
I have an Aurora R10 desktop with the same controller (zonescan says |
|
I did a bit of extra abstraction on top of @kmescher's work, check it out here: https://gist.github.com/Cheaterman/accd912c6886f4055f45d0594b88553c Basically used all of @kmescher's reverse-engineering work, and combined it with some USB tricks already present in AlienFX, all in a nice OOP package by yours truly. Here a (very) basic example file: https://gist.github.com/2d166b510adc5eb9d582eaa83282c410 Here a simple zone tester (for zones 4-16 - change inside file as needed): https://gist.github.com/6911515cb12bce63e5548989b513840a I hope y'all enjoy :-) EDIT: @ShimmerFairy The only real way to know is for you to try I suppose? I expect only AC_* to work for you, so you should have at least normal + suspend? |
|
The AlienFX package includes a big pile of json files which specify the zones for each machine type (and their numbers), and if they are used to reflect power status. In the case of the Aurora 10, I couldn't find a file for that machine type specifically, but I did find one for the Aurora R9 and R11. R9: The R11 is similar, but the "Upsell" version has these zones instead: Unfortunately, it appears (according to the json files) that none of the zones can reflect the power state. The power states may exist on the controller, but it appears that they won't do you any good. As of March 2020, Dell pushed out a new firmware version for this controller (1.0.11). I haven't loaded that on my system or seen if it has any new capabilities. EDIT: Additional note: If you have one of the fancy keyboards (where each key is a separate zone), the json files have all the zone numbers for those keys. At least for the 15R4 laptop, the vendor and device ID are WAY different than for the rest of the system, and there are 135 individual zones (one for each regular key), and 1 zone (ID 999) for the macro keys. If anyone wants to request the list for a particular machine type, let me know. @Cheaterman: There are some files for the Dell G5 5500 series. Looks like zones 0-3 are for the RGB keyboard (left, center, right, keypad), and zones 4-15 are listed as "Light bar 1" through "Light bar 12". |
|
@kmescher whoa, thanks for the info! Do you think you could publish the full list of JSON files? I don't think any of us have your reverse-engineering talent, haha! Thanks in advance :-) |
|
@kmescher, this is a long shot, but do you know (or still have a list of) what are the ACPI methods that need to be poked at to set the RGB microcontroller to DFU mode? I've been poking at this for kicks and giggles, and I've figured out that at least on my Dell G5 5505 SE the internal controller appears to be a STM32F070x6 or STM32F070xB, and I did find the Windows applications that the Alienware software uses to flash the firmware (ElcUpdate.exe and friends). From poking around the updater, I know that there are two GPIOs that are toggled (NRST and BOOT0) to change modes, but I'm having a hard time figuring out what the heck Windows does to toggle those GPIOs (I know it's ACPI related, but that's about it for now, can't narrow down the methods being used). If I can figure that out, I can easily whip up a kernel module in Linux. |
|
In case anyone stumbles upon this while searching online (as no one else talks about the DFU in some of these Dell systems), I haven't yet found a complete solution, but I unstuck myself, effectively bridging the gap between the updater and whatever Windows is doing. In Windows, one can probe the specific ACPI WMI object through Should save the returned WMI class into the Thing is, I wasn't able to find any mention of anything resembling AWCC in the DSDT ACPI table. Clearly, though, Windows was reading this from an ACPI table. After decompiling all of my ACPI tables using I still haven't completely figured out how to switch the MCU to DFU mode, but I think I now have enough information to get there. Although, if someone has Linux kernel code that works, that would be great! One advantage of figuring out how this works is being able to update the firmware on these chips, and if someone REs the firmware, that means custom firmware that doesn't suck as much as Dell's! Imagine being able to query which zones are turned on! |
|
This'll likely be the last time I post here, just since this issue is closed and not about my misadventures, but again, this is the only page that shows up when looking up alienfx DFU, or alienware DFU and the like. I succeeded in deciphering enough that I can also now switch the STM32F070xB (yes, I narrowed it down to have 128KB of flash) to its bootloader mode, and dump its internal flash using The gist of it is in the SSDT19 ACPI table, the I'll probably write up something about this somewhere else, and I may upload some Linux kernel code that can toggle these GPIO pins around through WMI commands. |
|
Yeah, so I had figured out the WMI GUID and Method for the Alienware 17R5
back when I decoded the USB protocol. I even modified the alienware-wmi
kernel driver to give me a file to poke at. Unfortunately, i lost the
source code, and it's been three years.
But on the plus side, I still remember (and have documented) some of the
information. Hope this helps:
The GUID that contains the method
is: A70591CE-A997-11DA-B012-B622A1EF5492. In the alienware-wmi kernel
module source code, it is already defined at the WMAX_CONTROL_GUID.
The method is (as stated above): 32 (or 0x20). The method has a single
argument: a long integer.
It appears that the default state (value) of that integer is 257. If you
toggle the high bit (set it to 1), the controller goes offline. If you set
it back to 257, the controller reboots. During the reboot process, it goes
into FlashDFU mode, but doesn't stay in it very long. Hard to access it
using the DFU update utilities during that time, but if you succeed, it
will stay in that state. If you are lucky enough to get into the state,
set it back to 1 and then 257 to reboot again.
However, if you take if offline (set it to 1), then set it to 256 (low bit
0, high bit 1), then set it to resume (257) it will go into the bootloader
(ROMDFU) state, and stay there. At that point, you can access it with the
DFU utilities at your leisure.
To get back out of bootloader, take it offline (set to 1), then set to 0 to
get out of bootloader, then resume (set to 257).
So theoretically, the alienware-wmi.c kernel driver is already pretty
close. You can add a method (like "WMAX_METHOD_FWUPDATE") in the top of
the source file, create some functions either to a) pass the integer
directly and do all the logic outside the kernel driver or b) a string with
the target state that you want (reboot, romdfu_enter, romdfu_exit), which
then calls the WMI method with the right numeric values.
I never got as far as RE'ing the firmware, but the Windoze code to mess w/
the LED's is decompilable C# code, which is how I was able to verify the
protocol in the above messages. Turns out the chip itself is more capable
than the Windoze program; I was able to use the protocol to have the led on
the lid (along with the power button) reflect the power state. Can't do
that with the windows program (at least in 2019 you couldn't)
…On Fri, Apr 8, 2022 at 8:52 PM Gabriel Marcano ***@***.***> wrote:
This'll likely be the last time I post here, just since this issue is
closed and not about my misadventures, but again, this is the only page
that shows up when looking up alienfx DFU, or alienware DFU and the like.
I succeeded in deciphering enough that I can also now switch the
STM32F070xB (yes, I narrowed it down to have 128KB of flash) to its
bootloader mode, and dump its internal flash using dfu-utils.
The gist of it is in the SSDT19 ACPI table, the _SB.AMWW.WMAX method.
Specifically, it has a switch case to do different functions. For toggling
the pins the method values is 32. There is a value for querying the state
of the pins, 34, but there's a bug in the DSDT WISC method that actually
handles the GPIO pin stuff, that makes it so querying the status will
always disable the pin output. I've patched my DSDT to fix that particular
bug.
I'll probably write up something about this somewhere else, and I may
upload some Linux kernel code that can toggle these GPIO pins around
through WMI commands.
—
Reply to this email directly, view it on GitHub
<#41 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALJ5MOT7OZRAEOD3LFEHRKTVEDIDXANCNFSM4FILXHGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Wow! I just found for this topic. I'm the guy who develop (AlienFX-Tools)[https://github.com/T-Troll/alienfx-tools/] In fact, all AWCC-based functions exposed into WMI via AWCCWmiMethodFunction class methods. But light control only available at older systems, latest m-series, x-series and g-series doesn't support it. Also, i't a lot of unclear points into your 0x550 chip description, especially about power block set (it's tricky), as well as some other stuff. In case you're still interested, let's share out research results. |
I have a 17r5 too. VID: 0x187c / DEV: 0x0550 |
Issue
The application does not support the FX interface for Alienware 15 R4.
Installed dependencies
libusb1.0libcairo2-devpython3.6.5 Anacondapython-giandpython-gi-cairoand all other Python dependencies.
1. Expected behavior:
Recognise the AlienFX.
2. Actual behavior:
Throws the following error:
3. Steps to reproduce the problem:
Run the application on Ubuntu 18.04 installed on an Alienware 15 R4 machine.
4. Specifications like the version of the project, install method, operating system, and hardware.
General info:
FX interface:
Please let me know if you need any additional info.
The text was updated successfully, but these errors were encountered: