Build Instructions
rogerxxxx opened this issue · 8 comments
How about listing some build instructions within the documentation? (Granted, I'll figure out the incantation quickly, but may stall others.)
Most cases, it should just be cd'ing to the folder and running make. If you see some folder that doesn't have a Makefile, feel free to add one and raise a pull request.
Looks like there's no top-level Makefile, and manually changing into each sub-folder is required. (Guess I wasn't awake and did not think to use find!)
Compiling seems to be broken with linux kernel 4.1.12-gentoo.
I'm presuming the issue is with the kernel module, I haven't really worked on that in a long time. Just so you know, the standard driver does work, at least as far as input goes. The lacking features are, to my knowledge, control of the LEDs & MFD (state & brightness) and the mode selection. I'm working on a userspace driver that should solve this - check the libx52 folder.
Be aware that this is still a work in progress, and this repo is in no way close to a final form.
libx52 compiles and works marvellously. (Obviously somewhat simple though.)
I have attempted to use USB Snoopy or Wireshark to capture USB traffic too and from the device, while modifying the button colors. I know I captured the specific packets, I just had problems reading the packet line due to my lack of knowledge with the USB transfer protocol. I guess the only method, is to study the USB protocol in order to attempt to decipher the traffic, but I constantly lack time and have other higher priority tasks.
I have Windows XP (several duplicate clones) within VirtualBox. And then I used WireShark to analyze USB traffic. Modifying the button colors within Windows XP just after starting WireShark, and then stopping WireShark just after is the easy part. And the traffic can be readily seen. But I also heard VirtualBox just transfers generic HID input recently.
Another stumbling block; although I understand hexadecimal (ie. HEX), trying to translate the hexadecimal data is very time consuming. Much much easier just to have the specifications (ie. spec sheet) or data sheet on hand! If I had the color codes, or something unique documented, I would be able to narrow my focus more so. As far as the date and time setting, I think something also may stand-out, but on the flip, I NEVER look at the MFD! About the only useful task with the joystick, aside from the joystick axis and buttons, are the button LED colors. But rarely does the user likely look at the button colors once they have memorized the buttons.
Ah, if all you need is the packet specification, take a look at this page. I've documented all the known packets there, mostly picked up from the original x52pro library, and I've tested the lot.
I'm making some additional changes to the library to make it somewhat simpler to control by the user. For example, the LED API right now is simply setting an index to on or off, but I'm making some changes to export a list of LEDs, and set the state to a known color or on/off, as shown in 
Oh, I'm dumb. Only one thing, why are the info/ folder files not grouped in within the docs/ folder?
Personally, I think the current X52 Pro joystick MFD is useless, until Saitek integrates a future lit display. But even then, the MFD may still remain useless in my opinion. The MFD would also have to display some useful information such as percentage of throttle, or a successful deploy report of one of the other buttons or axis. But reports of successful deployment usually requires other wiring or separate circuits within the real world, for which would likely require additional software programming, and integration with every game! Within Linux, we only really have FlightGear to work with, so this might be possible if it is feasible. ARMA 3 and maybe a few other games or simulators have native Linux code binaries, but still no export interfaces for such a feature.
why are the info/ folder files not grouped in within the docs/ folder?
Probably just because I wrote it that way 3 years ago and never bothered to change it 😄
The display is actually lit, but for some reason, the default setting when plugging it in is:
- Fire LED off
- All throttle LEDs off
- MFD backlight off
- No time or date display
The Windows drivers have a brightness setting for both the MFD backlight and the LEDs, which by default is set to 128 (the maximum), but the Windows driver is sending the necessary control packets when the joystick is plugged in.
One way to achieve this would be to program a udev rule to send the necessary control packets to the joystick on an add action.
For the rest, Saitek did actually write a DirectOutput driver which would control the MFD text, along with functionality to display multiple pages of information, which would be controlled using the PgUp and PgDn scroll wheel below the MFD. I suspect that games haven't actually utilized it.
Take a look at the latest commit (@5d0684a1), I've pushed some changes to the X52 library so that you should be able to control it using the x52cli command. You should be able to build it using ./configure && make && sudo make install. Just remember that you'll probably need superuser privileges to run the x52cli command, since that's needed by the USB subsystem.