Menu
▾
▴
Re: [Flightgear-devel] Solution approach Saitek/Logitech Panels in Windows Registry
|
From: Pfeffer <pr...@ro...> - 2021-05-05 23:50:33
|
Am 05.05.2021 um 13:38 schrieb James Turner: > >> On 5 May 2021, at 12:05, Pfeffer <pr...@ro... >> <mailto:pr...@ro...>> wrote: >> >> finally the Saitek/Logitech radio and multi panels work reliable in >> Windows :-) >> >> The problem is "Enhanced Power Management" - when disabled in the >> Windows registry the displays of the panels work reliable. >> >> There is a Windows PowerShell skript that does it: >> >> https://github.com/FKLaben/SaitekLogitechPanelFixer >> >> It sets "EnhancedPowerManagementEnabled" >> in"HKLM:\SYSTEM\CurrentControlSet\Enum\USB\"+$device+"\*\Device >> Parameters" to zero. $device is "VID_06A3&PID_0D06" for the multi >> panel and "VID_06A3&PID_0D05" for the radio panel. >> >> >> Is there a way that FlightGear sets this registry value? - Or a way >> to disable "enhanced power management" for certain USB-devices when >> FlightGear is running? >> >> > > I’m kind of clueless about Windows: what does Enhanced Power > Management do? everything I know about USB and HID is, what I learned while programming the Saitek panel's xmls and nasal for FlightGear. I searched on the net: It seems that there is a protocol to send devices into a power saving mode. It seems that this is usually handled by the OS: in linux, there is /sys/bus/usb/devices/.../power/control, see: https://www.kernel.org/doc/html/v4.16/driver-api/usb/power-management.html > Writing to a registry is possible but kind of bad for us to be doing > it: if it’s needed for the devices to work, why doesn’t the Saitek > installer do it? Another way to ask the same question: what are > X-Plane and MSFS doing for this? Since we don’t want to get into a > Registry fight with them. X-Plane and MSFS2020 still work fine and they do not change the registry entry back. If we do that - it should be done at installation time. But this has the disadvantage that - if the saitek panels are not connected at installation time - it cannot be done then. hm. > If the issue is the devices going into a power-save mode, I’d guess we > are missing sending some custom ‘wake up’ command (which would make > sense), so would be best to discover how we request a wake up for the > duration of the session. Since presumably when you exit FG you want > the devices to sleep again, and we don’t want to be modifying the > registry each time you launch+quit FG, that feels …. unwise. It seems to me that Linux defaults to not sending USB-devices (except hubs) into power saving mode (see the kernel.org link above). Windows (starting with Vista) defaults to sending USB devices into power saving mode, see: https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-selective-suspend Hmmm... according to the diagram in https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/selective-suspend-in-usb-drivers-wdf the device should automatically get unsuspended. Further reading lets me guessing that the panels in fact get unsuspended, but only for some milliseconds on order to receive the data (and this might be the reason why the LEDs work without messing with the windoes registry). It seems to me that the WinUsb_SetPowerPolicy function (winusb.h) could solve the problem the right way, see https://docs.microsoft.com/en-us/windows/win32/api/winusb/nf-winusb-winusb_setpowerpolicy This way, the automatic power policy can be set at run time to off (false), and can be reestablished (when the previous stat was read before hand by WinUsb_GetPowerPolicy) on FlightGear's exit. What do you think? - Will this solve the problem? - Can it be done? Best regards, Pfeffer. |
