0.2.2. --- erratic behavior
Closed this issue · 16 comments
Describe the bug
After daemon is started and X52Pro connected, on display, mode status (1,2, 3) starts rapidly blinking. Also in game X52Pro is erratic ( it feels like it is repeating inputs, rather then holding constant value).
To Reproduce
Steps to reproduce the behavior:
- Just start x52d 0.2.2
- take a look at LCD display
- Blinking mode status number
- Soon as x52d is stopped, hotas is working normally.
Expected behavior
Normal behavior
Screenshots
If applicable, add screenshots to
x52evtest-output.txt
help explain your problem.
Environment (please complete the following information):
- OS: Debian Sid
- libusb version: libusb-1.0
- X52 type: Bus 001 Device 004: ID 06a3:0762 Saitek PLC Saitek X52 Pro Flight Control System
Additional context
In attachment x52evtest output,without touching hotas. It starts soon as hotas is connected.
As of version 0.2.2, the daemon doesn't do anything but control the brightness, clock and LED states. The mode status number is also controlled in hardware, not by the daemon. I'm not sure why you are seeing the problem only when running the daemon.
Can you also attach the x52d logs? If you are using the released .deb package (or if you've built from source with the default configuration), then you'll need to edit /lib/systemd/system/x52d.service
, and update the ExecStart
line from -v
to -vvvv
. Then you can capture the logs by running sudo journalctl -b -u x52d.service
.
If you're running the service manually, then you can append -vvvv -l /tmp/x52d.log
, and attach that file.
Also, without starting the daemon, can you capture x52evtest
output? Also, please run x52test led
- this is a program which will exercise the hardware (just the LEDs) and make sure that the device is working as expected. The output that you attached is showing flapping on the MODE_3 button, which leads me to think that either the button sensor is not working as expected, or (more likely), the PS/2 cable connecting the throttle and stick is bad. I had to replace the cable on my own joystick several years ago, and I suspect that this might be the more likely reason you are seeing issues.
Tnx for really quick reply
My first thought was also that switch or even cable might be faulty, but as you can see from evtest with daemon stopped, it is not.
Please let me know if I can do anything more to assist.
oh, I forgot, I've built it from source.
OK, unfortunately, the journalctl logs are getting cut off, can you please capture the output using sudo journalctl -b -u x52d.service > journalctl_log.txt
and attach that output please?
Huh... the journal logs are showing an error which was fixed before I released 0.2.2, what commit are you at?
I downloaded source from latest release. 0.2.2. I guess?
Also I tried with deb package as well. Same thing.
I think I may have found the issue. Can you try with the latest commit on branch check-device-attached
and see if you still see the problem?
You got it!
It works as expected now.
Thank you very very much!
Thank you for the confirmation. If you can provide the verbose daemon logs when unplugging and reinserting the X52, I'd appreciate that very much.
Of course!
Here it is.
journalctl_log.txt
Thank you. One last request - can you share the contents of libx52/x52_stringify.c
? The log messages that you shared indicate another fault which I thought I fixed in that file.
Yes no problem.
/*
- Saitek X52 Pro MFD & LED driver - stringification
- Copyright (C) 2012-2021 Nirenjan Krishnan (nirenjan@nirenjan.org)
- SPDX-License-Identifier: GPL-2.0-only WITH Classpath-exception-2.0
*/
#include "config.h"
#include <stdio.h>
#include "libx52.h"
#include "gettext.h"
#define N_(str) gettext_noop(str)
#define _(str) dgettext(PACKAGE, str)
#define STRINGIFY(name, max_id, errstr, ...)
const char * libx52_ ## name ## to_str (libx52 ## name param) {
static char invalid[256];
static const char *desc[] = { VA_ARGS };
if (param >= 0 && param <= max_id) {
return _(desc[param]);
}
snprintf(invalid, sizeof(invalid), _(errstr), param);
return invalid;
}
STRINGIFY(clock_id, LIBX52_CLOCK_3, N_("Unknown clock ID %d"),
N_("primary"),
N_("secondary"),
N_("tertiary"),
)
STRINGIFY(clock_format, LIBX52_CLOCK_FORMAT_24HR, N_("Unknown clock format %d"),
N_("12 hour"),
N_("24 hour"),
)
STRINGIFY(date_format, LIBX52_DATE_FORMAT_YYMMDD, N_("Unknown date format %d"),
N_("DD-MM-YY"),
N_("MM-DD-YY"),
N_("YY-MM-DD"),
)
STRINGIFY(led_state, LIBX52_LED_STATE_GREEN, N_("Unknown LED state %d"),
N_("off"),
N_("on"),
N_("red"),
N_("amber"),
N_("green"),
)
const char * libx52_led_id_to_str(libx52_led_id id)
{
static char invalid[256];
switch (id) {
case LIBX52_LED_FIRE:
return _("Fire");
case LIBX52_LED_A:
return _("A");
case LIBX52_LED_B:
return _("B");
case LIBX52_LED_D:
return _("D");
case LIBX52_LED_E:
return _("E");
case LIBX52_LED_T1:
return _("T1");
case LIBX52_LED_T2:
return _("T2");
case LIBX52_LED_T3:
return _("T3");
case LIBX52_LED_POV:
return _("POV");
case LIBX52_LED_CLUTCH:
return _("Clutch");
case LIBX52_LED_THROTTLE:
return _("Throttle");
default:
snprintf(invalid, sizeof(invalid), _("Unknown LED ID %d"), id);
return invalid;
}
}
Oh btw, if I can assist more, please let me know.
Really it is no trouble for me.
Thank you, if I need more help, I'll raise a separate discussion and tag you.