akbl
akbl copied to clipboard
rsm-gh
Add support to Dell G5 5590
System information
- Distribution name: Ubuntu
- Distribution version: 19.10
- Python3 version: Python 3.7.3
- akbl version: 2019.05.26
- Computer model:
- Daemon status: True
Bug description
USB Data
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 17e9:436c DisplayLink USB3.0 Hub
Bus 002 Device 003: ID 0424:5744 Standard Microsystems Corp. Hub
Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc. Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0c45:671f Microdia Integrated_Webcam_HD
Bus 001 Device 008: ID 045e:07b2 Microsoft Corp. 2.4GHz Transceiver v8.0 used by mouse Wireless Desktop 900
Bus 001 Device 007: ID 045e:07b2 Microsoft Corp. 2.4GHz Transceiver v8.0 used by mouse Wireless Desktop 900
Bus 001 Device 004: ID 0424:2744 Standard Microsystems Corp. Hub
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 006: ID 0cf3:e007 Qualcomm Atheros Communications
Bus 001 Device 005: ID 187c:0550 Alienware Corporation AW-ELC
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Info
Device: ID 187c:0550 Alienware Corporation
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x187c Alienware Corporation
idProduct 0x0550
bcdDevice 2.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0029
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 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 25
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 0x0021 1x 33 bytes
bInterval 10
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 100
Hello @marlesson,
Thanks for the details, I just added a configuration for your computer and there will probably some work to do before making it functional. Please take a look to this question and don't hesitate to ask if you have problems testing the software.
Regards, ~rsm
It is not working for me. Is there something else to do to make it works?
regards
I tried, but with no success.... when I clicked the TEST button it freezes and became unresponsive.
I had the same error when I clicked the TEST button it freezes and became unresponsive. how should I proceed? how to log the error?
Hi, @rsm-gh.
I have a Dell G5 5590 and I will try to investigate that. I searched for usb sniffers for windows and I gave busdog[1] a quick try while changing the backlight settings on the Alienware control software or using special key to toggle the backlight on and off.
I need to dive deeper into the results but it seems like this device is using a different packet format. It seems the start byte is different and maybe also de position of some values.
Please let me know if you have any tips of sniffers for windows or on how to reverse enginner the messages.
[1] https://github.com/djpnewton/busdog
hello @mhcerri,
that would be really useful ! Sadly I'm not a windows user and I can not help you with the windows sniffers but I'll try to make some doc about the current format of AKBL.
Also, it makes long time that I want to add into the block-testing window some sort of generic GUI for testing different formats. I'll try to implement it so you can test your discovers.
And by the way, if you're interested I invite you to join the AKBL Chat, which may improve the community and the fluidity of the communications.
rsm~
Thanks, @rsm-gh!
I just joined the chat. I assumed you had used the windows application as a reference to implement it. How did you find the correct packet format to use?
Same issue here, Dell R5 5590 with RGB keyboard. I'm gonna try and reverse-engineer the windows packets
In case anyone is working on this: You can use a virtualmachine to produce the proper packets and control your keyboard from a windows VM. I've used QEMU-KVM but other options, such as VirtualBox should work just as well (just be sure to install the extensions pack for USB 3 support).
Make a bare metal Windows installation and then install Alienware Command Tools (a VM won't work for this part, because the installer won't recognize your pc as being an Alienware unit). Afterwards, reboot into Linux and start that same windows installations through Qemu/libvirtd. (this can be achieved by several manners. I didn't want to take the time to mess with my SSDs, so I used a tool called Windows To Go, but it's only available for Windows 10 Enterprise. a much easier approach is just to install windows on your hard drive and point qemu to book from your physical partition. just be sure to select the EFI option (it's not a default) if your installation does not support legacy MBR booting (probably not, these newer Dell units come with legacy BIOS boot disabled).
After setting everything up, before starting the virtual machine, Add the proper USB device to the virtual machine. When you start it, you will be able to control the keyboard lights from the Windows machine. I did not use the "redirect USB option". There is no reason why it wouldn't work, but I just added it as a static USB device (add hardware option if you're using virt-manager)
In my case it was device 001:005 Alienware Corporation AW-ELC | 187c/0550
--
Now, if you want to intercept the packages, one of the most widely used options seem to be good old Wireshark. It's pre-packages for most distributions (in my case, I use Fedora, so I got it through dnf, but apt, pacman, yum, zipper and other mainstream packages should have it in their default repositories).
You should properly setup wireshark so you can run it as a a non-root user. I just went the lazy path and ran it as root.
Type lsusb to figure out what's your device's bus. You should have an entry like the following one: Bus 001 Device 005: ID 187c:0550 Alienware Corporation AW-ELC
In my case, I have BUS 1, so I will be using usbmon1. Usbmon0 is, as far as I'm aware, a catch-all bus which will show results from all USB buses.
Check that you have the usbmon module properly setup and producing results: sudo cat /dev/usbmon1 (replace 1 with the bus you got through lsusb, if appropriate) It should just print a lot of garbled text and it's enough to confirm everything is working fine. Okay, then you can just open wireshark. If you didn't perform the recommended instalation steps, then it will only work as root. As soon as you open it, it will have as an option usbmonX, with X being the correct USB bus. Just click on it and you'll have all the packets from that bus.
You will notice that there are lots of packets belonging to other devices. Now, we need the device ID to filter the output to better suit our needs. In my case I have device 1, bus 0. For the proper packets I had to use the following filter (just type/paste on the Wireshark display filter bar)
usb.dst == "1.5.0" or usb.dst == "1.5.1"
If everything is working as it should, you will mostly have packets only when you send specific commands through Windows. I will try to help decoding the packages once I have spare time, but if anyone wants to give it a shot, it should feasible to decode the meanings by comparing to what's already in this package.
Another approach which MIGHT be interesting, might be to reverse engineer the LightFX SDK or maybe even try to get it running through wine. The documentation does mention that applications can work without the presence of AlienWare command center if you like the application using explicit dynamic linking.
You can find the SDK after installing Alienware Command Center in: (instalation_drive)/Program Files/Alienware/Alienware Command Center
There's nothing authorizing the redistribution of the binaries (you can just download and extract them from alienware command center installation package I guess, not worth taking any risks). The API reference seems to be public, however, so I'm attaching the unmodified DOCX and pdf files if anyone wants to check them out.
AlienFX SDK 5.2 User Guide.pdf Alienware AlienFX API.docx
@etinin thanks for detailing the usb sniffing instructions, it seems really interesting ! Personally I'm not sure if I'll install windows, but it makes many years that try to motivate my self to reverse engineering the packages for this software.
Anyways I'll share it for the other users and if you manage to package some specific USB packages (lights on, off, reset, etc..) don't hesitate to share it ! it will really help me to improve the software !
You can easily find me into the akbl chat.
rsm~
hello,
couldn't get the block testing feature to work. I made use of a simpler tool called "hack-alienfx-experiment" which is basically a wrapper around libusb to make some tests.
this packet works for turning off: 03:26:64:00:04:00:01:02:03
this one works for turning on: 03:26:41:00:04:00:01:02:03
haven't got around to decoding more stuff yet. haven't yet studied enough the innards of akbl to make the changes. but it seems one of the main changes is that the packets start with 03 instead of 02. i'm attaching a sniffer session if anyone wants to help. it's commented and should be openable with wireshark.
this packet dump probably contains all information we need to fully decode the 5590 rgb keyboard. whenever I did something of notice, the package has a comment. (the zip should be better to read with wireshark, but attaching a TXT conversion also, if it is of use to anyone)
@etinin can you install the software as "Debug" and paste me the terminal output? to install the software as debug modify the DEBUG=True variable of the setup file.
@rsm-gh Here are some logs
Opening block testing and trying to test produces some kind of loop: log.txt
I'll try to do some more debugging later, to figure out the proper commands. The packets I figured out only work after "bootstraping" the device by sending commands it from Windows first. Otherwise, they don't work to turn on the lights.
[EDIT]
I think libusb/pyusb are having trouble setting the proper configuration. When you do make use of WIndows first, the configuration is already set, so you can actually get to send some packets.
[Device found]: Vendor ID: 6268 Product ID: 1360
Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/AKBL/Addons/BlockTesting/BlockTesting.py", line 347, in on_button_block_testing_lights_off_clicked self._testing_controller.add_reset_line(self._computer.RESET_ALL_LIGHTS_OFF) File "/usr/lib/python3.8/site-packages/AKBL/Engine/Controller.py", line 62, in add_reset_line while not self.__device_is_ready(): File "/usr/lib/python3.8/site-packages/AKBL/Engine/Controller.py", line 115, in __device_is_ready return msg[0] == self._driver.computer.STATE_READY TypeError: 'bool' object is not subscriptable
Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/AKBL/Addons/BlockTesting/BlockTesting.py", line 347, in on_button_block_testing_lights_off_clicked self._testing_controller.add_reset_line(self._computer.RESET_ALL_LIGHTS_OFF) File "/usr/lib/python3.8/site-packages/AKBL/Engine/Controller.py", line 62, in add_reset_line while not self.__device_is_ready(): File "/usr/lib/python3.8/site-packages/AKBL/Engine/Controller.py", line 115, in __device_is_ready return msg[0] == self._driver.computer.STATE_READY TypeError: 'bool' object is not subscriptable [TEST]: zone: 16 mode:fixed speed:100 color1:#204a87 color2: #cc0000
Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/AKBL/Addons/BlockTesting/BlockTesting.py", line 328, in on_button_block_make_test_clicked self._testing_controller.add_reset_line(self._computer.RESET_ALL_LIGHTS_ON) File "/usr/lib/python3.8/site-packages/AKBL/Engine/Controller.py", line 62, in add_reset_line while not self.__device_is_ready(): File "/usr/lib/python3.8/site-packages/AKBL/Engine/Controller.py", line 115, in __device_is_ready return msg[0] == self._driver.computer.STATE_READY TypeError: 'bool' object is not subscriptable
FWIW - this is the latest and greatest regarding the 0550 controllers (and alikes):
https://github.com/trackmastersteve/alienfx/issues/41#issuecomment-473565491
I'm writing a simpler Python abstraction as we speak, will keep both of you guys in touch.
Abstraction done, check it out here: https://gist.github.com/Cheaterman/accd912c6886f4055f45d0594b88553c
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 :-)
Hello @Cheaterman,
This seems very interesting I'm very curious to take a look, sadly I have not too much free time. Would you be interested in develop for akbl? It would be great to have another developer.
rsm~
Hi @rsm-gh !
I don't have that much time either to be honest, but I'd be happy to make some contributions :-)
I looked through the codebase quickly, I think it could benefit from a more "standard" layout, which would make packaging and distribution easier :-)
I also saw the nice list of ini files, that's very impressive, where did you get the data from? I've been told one can extract a list of JSON files from AlienFX for information about each device, I'm sure that could come in handy to make a one-size-fits-all tool!
Hi, so for anyone who wants to use the backlight of this keyboard and is fine with using a single script when needed:
First take this git and save it to a file in whichever folder you choose as elec_ng.py: https://gist.github.com/Cheaterman/accd912c6886f4055f45d0594b88553c
Then create your file based on this: https://gist.github.com/2d166b510adc5eb9d582eaa83282c410
The one I use to set all 4 zones to blue is:
#!/usr/bin/python3
from elc_ng import ELC, ColorCommand
elc = ELC(0x187c, 0x0550)
with elc:
elc.execute(ColorCommand([0], 0, 0, 255))
elc.execute(ColorCommand([1], 0, 0, 255))
elc.execute(ColorCommand([2], 0, 0, 255))
elc.execute(ColorCommand([3], 0, 0, 255))
Save it with whichever filename you want, for example custom.py. Then run it with sudo python3 custom.py
If you want to simply test the zone, use the test_zone files from above: https://gist.github.com/Cheaterman/6911515cb12bce63e5548989b513840a
And then just replace all places where it says for i in range(4, 16): with for i in range(0, 4):
I have mentioned how I managed to make the keyboard to lit up in the chat, but it should be nice to have it written here anyway.
Also, as a note, I haven't managed to use the DimCommand Command, not sure if it even works here. I tried it with elc.execute(DimCommand([0], 255)), elc.execute(DimCommand([0], 0)) and elc.execute(DimCommand([0], 128)) but no luck
Thanks for the info @MateusRodCosta , I’ll take a look to include the code into akbl once I get back my computer.
Regards, rsm~
Hi, so for anyone who wants to use the backlight of this keyboard and is fine with using a single script when needed:
First take this git and save it to a file in whichever folder you choose as
elec_ng.py: https://gist.github.com/Cheaterman/accd912c6886f4055f45d0594b88553cThen create your file based on this: https://gist.github.com/2d166b510adc5eb9d582eaa83282c410
The one I use to set all 4 zones to blue is:
#!/usr/bin/python3 from elc_ng import ELC, ColorCommand elc = ELC(0x187c, 0x0550) with elc: elc.execute(ColorCommand([0], 0, 0, 255)) elc.execute(ColorCommand([1], 0, 0, 255)) elc.execute(ColorCommand([2], 0, 0, 255)) elc.execute(ColorCommand([3], 0, 0, 255))Save it with whichever filename you want, for example
custom.py. Then run it withsudo python3 custom.pyIf you want to simply test the zone, use the test_zone files from above: https://gist.github.com/Cheaterman/6911515cb12bce63e5548989b513840a
And then just replace all places where it says
for i in range(4, 16):withfor i in range(0, 4):I have mentioned how I managed to make the keyboard to lit up in the chat, but it should be nice to have it written here anyway.
Also, as a note, I haven't managed to use the DimCommand Command, not sure if it even works here. I tried it with
elc.execute(DimCommand([0], 255)),elc.execute(DimCommand([0], 0))andelc.execute(DimCommand([0], 128))but no luck
Hi, so I tried this, and it only applies the color for a second then reverts to what I had.
I suspect you might want to run an Animation instead, which should permanently force the colors to a given value - possibly you already have an animation running by default, saved in your ELC.
You can use the gist Mateus shared above to translate the simple 4 color commands script into a command using an Animation to light the LEDs. I'm a bit busy right now but I might help you with that later if you still need it.
I suspect you might want to run an Animation instead, which should permanently force the colors to a given value - possibly you already have an animation running by default, saved in your ELC. You can use the gist Mateus shared above to translate the simple 4 color commands script into a command using an Animation to light the LEDs. I'm a bit busy right now but I might help you with that later if you still need it.
yeah if you're able to help out with this, that would be great... I'm good with programming but not the greatest with Python.
Can confirm @Cheaterman 's gist works on my G7. 0-3 are the keyboard, and 4-16 are segments of the, uh, lap beam.
FWIW, the last segment of the lap beam continues to flicker after the python example exits.
I confirm @Cheaterman 's gist is working on Dell G5 too. Full RGB support tested. Zones 0-4 are the RGB backlight of the keyboard.
I've been working on documenting the behavior of this RGB controller for OpenRGB. It's still not done, but most of what I've written is in this document. There are a few typos and some things I'm testing and going to end up refining. On my own test code, I've been able to change colors, mode, speed, and tempo for my Dell G5 SE for each zone separately. I've also managed to erase the default animations (and figured out that re-installing the Alienware Command Center actually re-install the animations into the controller), and I'm currently trying to figure out if it's possible to program in colors without having to save them to the controller.
The controller is kind of finicky, in that if too many commands are sent too it too quickly, it'll seize up and require a full power cycle to fix. Also, some combination of parameters (at least on mine), lead it to also crash (say, setting the loop variables to 0 on the zone selection for some reason).
Hello @gemarcano ,
I was very happy to see that some one is finally writing a doc about the USB controller ! It makes make years that I want to start writing that document and I never do it because I spend my time coding...
So I hope that you can continue and add as much details as possible, I saw your doc and it was very good. As info, in the AKBL code I did added a delay for sending commands to avoid the problem that you are speaking about, and I never debugged why, but since pyAlienFX, some commands are sent twice. I first tough it was a bug, but actually it is necessary.
Also, once that you have explored all the basic points, I suggest you to take a look to the battery power modes. That's a part of the hardware that I haven't have the time to debug and make it work.
Best regards, rsm
My particular system doesn't appear to support power related animations, so I'm not sure how I'd get around to testing that. I can try to see if Alienware Command Control has a way to set animations based on power modes, since if it does, I can always capture the USB communications and figure out what's going on.
@gemarcano In windows, it is not possible to set different modes and themes depending on the battery power mode? Like 'on charge" or "on battery¨?
@rsm-gh, there is no such option on Windows for my laptop, it appears my controller doesn't support that. On the ACC menu, I am unable to select settings for any theme, which I'm guessing is where those parameters are kept.
Testing this as a part of looking into #96, the @Cheaterman gist works for the G7 15 7500 with behavior similar to what @idcmp reported.
Hi, so for anyone who wants to use the backlight of this keyboard and is fine with using a single script when needed:
First take this git and save it to a file in whichever folder you choose as
elec_ng.py: https://gist.github.com/Cheaterman/accd912c6886f4055f45d0594b88553cThen create your file based on this: https://gist.github.com/2d166b510adc5eb9d582eaa83282c410
The one I use to set all 4 zones to blue is:
#!/usr/bin/python3 from elc_ng import ELC, ColorCommand elc = ELC(0x187c, 0x0550) with elc: elc.execute(ColorCommand([0], 0, 0, 255)) elc.execute(ColorCommand([1], 0, 0, 255)) elc.execute(ColorCommand([2], 0, 0, 255)) elc.execute(ColorCommand([3], 0, 0, 255))Save it with whichever filename you want, for example
custom.py. Then run it withsudo python3 custom.pyIf you want to simply test the zone, use the test_zone files from above: https://gist.github.com/Cheaterman/6911515cb12bce63e5548989b513840a
And then just replace all places where it says
for i in range(4, 16):withfor i in range(0, 4):I have mentioned how I managed to make the keyboard to lit up in the chat, but it should be nice to have it written here anyway.
Also, as a note, I haven't managed to use the DimCommand Command, not sure if it even works here. I tried it with
elc.execute(DimCommand([0], 255)),elc.execute(DimCommand([0], 0))andelc.execute(DimCommand([0], 128))but no luck
Should I have the lights on when running the script?
Hi, the @Cheaterman gist works also for my G7 17 7700 but the light is always turning itself off after the amount of time set in /sys/class/leds/dell::kbd_backlight/stop_timeout. start_trigger or trigger in /sys/class/leds/dell::kbd_backlight just get ignored and the only way I get the RGB working again is to rerun the script. Any ideas or did I miss something?
You're not missing something, but you're certainly a hero for showing us the backlight timeout can be affected through sysfs (I certainly didn't know that!).
It is my understanding that the LED bar gets shut down when keyboard backlight is off on "our" style of laptops - the ones where the keyboard itself isn't an actual controllable zone of the LED bar.
You can do something along those lines:
$ cd /sys/class/leds/dell::kbd_backlight/ $ echo 60m | sudo tee stop_timeout $ cat stop_timeout 1h
@Cheaterman i'm using your python code... I even created a GUI based... https://github.com/enryson/AlienFX-DellG15-5515
It Worked for some time... But, for some bizarre reason, I'm having a issue, i can apply the color but rapidly the original windows set color restores it self.. it seems the controller resets him self to the original color (set previously on windows) i cant figure-out wy. on windows i can change normaly.. with the Alienware command center i can change normaly on windows...
@Cheaterman i'm using your python code... I even created a GUI based... https://github.com/enryson/AlienFX-DellG15-5515
It Worked for some time... But, for some bizarre reason, I'm having a issue, i can apply the color but rapidly the original windows set color restores it self.. it seems the controller resets him self to the original color (set previously on windows) i cant figure-out WY. on windows i can change normally.. with the Alienware command center i can change normally on windows...
for some bizarre reason i reboot to windows, run a c++ app to change the color(not using the command center) and i can change have no problem at all.. I think the keyboard have 2 or more layers of configurations.. When you change something with the command center software, the config is save on level 0.. but if you change with the SDK you make changes on a level 1..
so if for some reason the level 0 config is prioritized, you cant change anything without using the official software from dell. when you change something on the command center, the color stays even when the lid is open again.. with the library from @Cheaterman the keyboard doesn't light back dos on when the lid is closed and open again.
is my take for what i observed.
it's funny because I don't use this machine anymore, but the one I use (Alienware M15R6) seems to exhibit the exact same blinky behavior... as I mentioned in #105 I'd be very happy to add support for this device, if only I knew what exactly it expects :-) - I don't have tools or knowledge for RE-ing the Alienware control center like some people did in the past, but I could really use their assistance (or a guide on how to do what they do)!