Obsługiwanie różnych precyzji padów

To raczej nie jest pytanie, ale jakby ktoś mnie chciał pocieszyć, wspólnie ponarzekać, albo zaproponować rozwiązanie, to będzie fajnie :)

Chciałbym, żeby celowanie padem w grze 2D miało jakieś szanse w starciu z myszką.
Żeby gracz mógł celować w dowolnym kierunku drążkiem pada.

Niestety precyzja drążków ssie. Ruchy drążka najchętniej by się "przyciągały" do jednego z ośmiu kierunków:

✳

Delikatne ruchy w ogóle nie mają wpływu na ustawienie kąta pod którym celujemy do wrogów.
Deadzone jest chyba fabrycznie ustawiony nie tylko na środku (żeby nie było drgań, kiedy nie ruszamy drążkiem), ale również wzdłuż krzyża:

Jak ktoś ma pada pod ręką to może spróbować powoli pokręcić drążkiem dookoła i obserwować krzyżyk/wartości Obrót X/Y we właściwościach urządzenia:

Ja testowałem pod tym kątem oryginalny pad do PS4 oraz zamiennik pada do Xboxa 360. Niestety obydwa porównywalnie wypadają przy testach.
Czytałem, że nowsze pady mają trochę mniejszy deadzone.

Jak na razie mam takie odczucia, jakby te urządzenia były projektowane pod gry niewymagające większej precyzji. Celowanie w GTA V realizujemy poprzez przesuwanie celownika, co dobrze współgra z gamepadami. Ja w grze 2D chciałem, żeby kąt celowania był ustawiany na podstawie kierunku wskazywanego przez drążek, co przy opisywanym przeze mnie działaniu drążków jest bardzo nieprecyzyjne i gra na padzie jest przez to znacznie trudniejsza niż na klawiaturze z myszką.

Gdyby dało się ustawić próg powyżej jakiego ruch gałką się zaczyna, byłoby to wygodniejsze. Wtedy działałoby tak samo niezależnie od pozycji. Gdyby jednak próg był bliski zeru, wystarczyłoby delikatne smyrnięcie gałki, żeby wywołać zmianę. Przy precyzyjnych grach to też niedobrze. W ogóle zastanawiam się czy przypadkiem nie można tego zmienić. Tyle, że sterownik musiałby być inny.

No właśnie gdyby zaprogramowanie deadzones pozostawiono twórcom gry, a nie ustawiano na sztywno, to by dawało znacznie większe możliwości.

Tutaj koleś opisuje razem z obrazkami, jak można zaimplementować samemu deadzone:
https://www.gamedeveloper.com/disciplines/doing-thumbstick-dead-zones-right

Gdyby te własne implementacje deadzone'ów działały zgodnie z tym co napiszemy to by było OK.
Ale skoro wartości drążków są wcześniej zepsute, zanim dostaniemy do nich dostęp, to i tak nie otrzymamy dokładnego sterowania :(

Znalazłem filmik, który całkiem zrozumiale przedstawia problem przeze mnie przytoczony:

Autorowi nawet udało się rozwiązać problem w Unity!
Chociaż podejrzewam, że częściowo to jest zasługa oryginalnego pada do Xbox One lub nowszego.
Bo gdyby to była w całości wina Unity, to wtedy we właściwościach mojego pada, ruchy drążka chyba byłyby precyzyjnie odwzorowane...

Ja w swoim projekcie przeszedłem na nowy Input System, ale przetestuję swoje pady pod starym, zgodnie z opisem autora filmiku i zobaczymy czy to wina gorszych padów ;)

update:
Stary Input w Unity działa tak samo jak nowy. Wartości drążka gamepada (PS4, fake Xbox 360) są przyciągane do pionu/poziomu.

Aż z ciekawości podlaczylem pada od PS5. U mnie takie zjawisko (deadzone) nie wystepuje, tzn najmniejsze ruchy są sygnalizowane. Sprawdzane przez kalibracje w Steam, w menedżerze urzadzen w windowsie nie mam takich funcji we wlasciwosciach pada.

Trudno mi powiedzieć czy jest to wina Unity, kontrolerów, sterownika HID, API systemowego czy jeszcze czegoś innego. A nie mam żadnego kontrolera z gałkami analogowymi, aby sprawdzić jak to u mnie wygląda — same klony retro-kontrolerów. ;)

Widać problemem tutaj nie jest oprogramowanie, a same kontrolery, które mają hardkodowane dodatkowe martwe pola (wzdłuż osi X i Y). Dlatego takie samo zachowanie istnieje zarówno w Unity, jak i w systemowym narzędziu do testowania kontrolerów. Ale żeby mieć pewność co do ich istnienia, trzeba sobie nastukać programik testowy i sprawdzić jakie dane faktycznie otrzymuje się w komunikatach — dane jałowe, nie uwzględniające mapowania i innych czynności wykonywanych za programistów.

A w ogóle to nie jest kwestia samej budowy pada i tego jak wygląda odczyt ruchu? Mam klony Xbox a. Ale ich jeszcze nie rozbierałem. Może te potencjometry łapią wychył od jakiegoś miejsca?

@jurek1980: dałoby się mechnicznie zaimplementować takie martwe strefy, ale po co, skoro można je zaprogramować w oprogramowaniu mikrokontrolera w PCB kontrolera, co nie dość że jest tańsze, to w dodatku zawsze precyzyjne, bez względu na stopień fizycznego zużycia gałek/potencjometrów.

IMO to kolejny przykład tego, że jedni twórcy robią niedorobione rzeczy dla kolejnych, niedorozwiniętych twórców. Tak jak SDL i jego usilne mapowanie kontrolerów bez wiedzy użytkownika, bo przecież kodzerzy to bezmózgie małpy i nie potrafią sobie mapowania sami napisać w swoim projekcie. W rezultacie niektórych kontrolerów nie da się w ogóle używać, bo SDL przysyła zupełnie błędne wartości osi, zarówno w formie jałowej, jak i zmapowanej. I nic z tym nie zrobisz — ja sobie mapowanie napisałem, ale SDL jest mądrzejszy. :/

Choć nadal mam cichą nadzieję, że to jednak zwykły, ogólny bug, a nie bug automatycznego mapowania.

@furious programming: nie wiem, po prostu wydaje mi się, że najłatwiej jest zrobić "pół milimetra" ścieżki na potencjometrze mniej, po pierwsze ten element mógłby się szybko wytrzeć. Po drugie jeśli jest odczyt to mikrokontoler już musi jakieś czynności z odczytem danych wykonać, a tak jest stan off i nie sytuacja jest czysta.

Trzeba sprawdzić jaki oznaczenie mają te potencjometry i sprawdzić dane techniczne — jeśli martwa strefa jest zaimplementowana mechanicznie, to w dokumentacji potencjometru będzie opisana.

Jednak nadal wątpię, aby tak było, dlatego że precyzja byłaby zbyt mała, aby cyfrowe dane nie wymagały walidacji.

Zobaczę niedługo jak działają nowe drogie pady. Jeśli są ok, to pozostanie mi tylko żałować, że kiedyś nie wprowadzono współczesnych standardów dla drążków, bo teraz tanie pady "dla plebsu" byłyby znacznie lepsze i nadawałyby się do komfortowego użytkowania mojej gry :]

Nowy oryginalny kontroler do PS5 jest mniej więcej dwa razy droższy (kosztuje ~300zł) niż nowy oryginalny kontroler do PS4 (na którym problem występuje) :(

Nie masz za bardzo czego żałować, bo możesz bez problemu wyłączyć w Unity te durne martwe strefy i ich obsługę zaprogramować samemu. A skoro da się w Unity wyłaczyć przyciąganie do osi, to znaczy, że kontroler dostarcza prawidłowe dane, które następnie są przetwarzane w celu dodania martwych stref.

Jedyne co mnie zastanawia to to, dlaczego systemowe narzędzie również obsługuje przyciąganie do osi.

furious programming napisał(a):

Nie masz za bardzo czego żałować, bo możesz bez problemu wyłączyć w Unity te durne martwe strefy i ich obsługę zaprogramować samemu. A skoro da się w Unity wyłaczyć przyciąganie do osi, to znaczy, że kontroler dostarcza prawidłowe dane, które następnie są przetwarzane w celu dodania martwych stref.

Masz jakieś info na ten temat? Bo jeśli wysuwasz takie założenie na podstawie filmiku gościa z niebieskim padem, to sprawdziłem to i niestety dla mojego pada PS4 to nie działa.
Konfiguruję tak jak pokazywał. Ustawiam deadzone na 0 itd. i dalej zachodzi przyciąganie do osi.

Datasheet od Alpsa dla takich potencjometrów:
https://tech.alpsalpine.com/prod/e/pdf/multicontrol/potentiometer/rkjxk/rkjxk.pdf
Nie jest dla mnie jasne jak działa dokładnie tutaj dzielniki napięciowy, ale pokazana jest precyzja na poziomie 0,1mm lub do 5 stopni. Tym samym w pozycji zero wychył może być liczony powiedzmy od 0,05mm lub 2 stopni, co przy długości drążka może być sporą odległością. Szukajac datasheet szukałem po PS4 bo @Spine o takim padzie pisał, ale nie mam pojęcia czy to co znalazłem odpowiada realnej budowie takiego pada.

Zrobiłem przykład w Unity 3D. Ustawiłem Input zgodnie z filmikiem How to Fix Controller Input Snapping in Unity

Nagrałem demonstrację:

Można porównać ruchy kciuka do ruchów kropki. Kropka się przyciąga do osi...

Kod:

public class DeadzoneDebug : MonoBehaviour
{
    public TMPro.TextMeshProUGUI values;

    public RectTransform L, R, Bg;

    const float radius = 275.0f;
    const float radialDeadzone = 0.05f;

    void Update()
    {
        Vector2 stickValue = new Vector2(Input.GetAxisRaw("Horizontal"), Input.GetAxisRaw("Vertical"));
        Vector2 rStickValue = new Vector2(Input.GetAxisRaw("RHorizontal"), Input.GetAxisRaw("RVertical"));

        if (stickValue.magnitude < radialDeadzone)
        {
            stickValue = Vector2.zero;
        }

        if (rStickValue.magnitude < radialDeadzone)
        {
            rStickValue = Vector2.zero;
        }

        values.text = string.Format(
            "L: {0}\nR: {1}",
            stickValue,
            rStickValue);

        L.anchoredPosition = stickValue * radius;
        R.anchoredPosition = rStickValue * radius;
    }
}

Obiekty L i R to kropki odpowiadające poszczególnym drążkom.

Spine napisał(a):

Masz jakieś info na ten temat? Bo jeśli wysuwasz takie założenie na podstawie filmiku gościa z niebieskim padem […]

Tak, na tej podstawie — innych podstaw nie mam. :D

Czyli wygląda na to, że te martwe strefy są zaimplementowane po stronie kontrolera. Teraz tylko kwestia czy są za to odpowiedzialne same potencjometry, czy ich implementacja znajduje się w oprogramowaniu mikrokontrolera, będącego na PCB gamepada.

Według mnie, nieważne co implementuje martwe strefy, ważne jest to, że pecet otrzymuje dane już po ich uwzględnieniu. A skoro tak, to poruszony problem nie ma rozwiązania. Jedyne co wg mnie warto zrobić to to, co zrobił ten koleś z niebieskim kontrolerem. Lepiej wykluczyć problem dla jakiejś części kontrolerów, niż udawać, że on nie istnieje.

Gała możemy wykręcic 360 stopni. Jeśli mamy jakiś ruch który nie jest jednoznacznym kierunkiem góra/dół, prawo/lewo, zostają nam 4 pola gdzie mamy możliwe 90stopni. Gram na padach różnego typu od ponad 25 lat. Zatem problem leży w tym że OP chce chyba mieć 90 pośrednich wartości, co na przestrzeni tak małej jaką jest to co ogarniają nasze kciuki, jest troszke niezrozumiałe dla mnie. Nie wiem jaki byłby idealny zakres - ale doświadczenie mi mówi ze pomiędzy góra a prawo zazwyczaj występuje max 20 wartości pośrednich - po 10 od gałki ustawionej pod kątem 45st.

Analog nie jest tak precyzyjny jak myszka, bo nieprecyzyjne są nasze kciuki. Poza tym w grach/padach znaczenie wg mnie ma nie tylko ile możliwości wychylenia gałki mamy, ale także z jaką prędkością to robimy. Znaczenie ma także wysokość samego analoga - dlatego chyba xbox miał specjalne pady (razer chyba tez) - gdzie można było analoga podmienić na jego wyższy odpowiednik. Mimo wszystko nadal nie widzę problemu, a responsywność analoga nigdy nie dorówna celności myszki i jej responswyności (polecam zagrać na myszce i padzie w strzelanki, gdzie są etapy ze strzelnicą).

Jako ciekawostkę dodam, że miałem okazję pobawić się trokarami laparoskopowymi(takie medyczne narzędzie, które służy temu by nie ciąć pacjenta za mocno, a zamiast tego zrobić 23 dziurki i na monitorze widzieć co siedzi w człowieku). Przechodząc do sedna, rozmawiając z lekarzem, który to udostępnił - dowiedziałem się że w posługiwaniu się takim sprzetem prym wiodą osoby, które są graczami (na padach) - bo ich kciuki są już lepiej przystosowane do tego typu sterowania. Moim zadaniem było zawiązanie kilku supełków wokół metalowych pierścieni, za pomocą długich na około 3040cm trokarów. Udało mi się zawiązać 3 z 4 możliwych supełkow (ograniczał mnie czas). W moim odczuciu ten sprzęt był bardzo nieprecyzyjny - to tak jakbyśmy chcieli złapac ziarenko ryżu za pomocą długich pałeczek do sushi.

Myślę ze problem dead-zone'a lepiej by było rozwiązać najpierw u medyków :)

A no i posiadaczom pada - polecam ćwiczenie - ustawić analoga na 90 róznych pozycjach w dowolnie wybranej ćwiartce.

axelbest napisał(a):

Zatem problem leży w tym że OP chce chyba mieć 90 pośrednich wartości, co na przestrzeni tak małej jaką jest to co ogarniają nasze kciuki, jest troszke niezrozumiałe dla mnie.

Załóżmy, że drążek ma pozycję: X = 0.0, Y = -0.8. Chcę żeby delikatne korekcje kierunku z tej pozycji (kciuk przesuwa się w lewo lub w prawo) miały widoczny efekt. Niestety wartość X się nie zmienia, gdy drążek znajduje się blisko środka X = 0.0.

Jak kręcisz drążkiem dookoła, to zachodzą odczuwalne przeskoki, dlatego że twój ruch kciuka przez moment przestaje wpływać na celownik w grze 2D.

Właśnie pobawiłem się padem od Xboksa na Linuksie, żeby sobie przypomnieć jak to było. Tam jak się używa pada "na surowo" (np. po kliknięciu "Raw Events" w jstest-gtk), to martwej strefy nie ma, czyli w tym przypadku raczej nie jest ona sprzętowa. W większości przypadków ma to słaby sens, bo widać duże niedoskonałości trochę zużytego pada i nie trzymałby on środka, bo puszczony swobodnie daje różne surowe odczyty z pewnego zakresu zależnie od przypadku. W niektórych grach nawet widać jednocześnie pad jako 2 kontrolery (event) i (js).

Obrazek nie mój, ale przejrzyście pokazuje, na czym tam polega kalibracja.

To jest myśl. Obczaję jak moje aktualne pady zachowują się pod Linuksem.

xy napisał(a):

W większości przypadków ma to słaby sens, bo widać duże niedoskonałości trochę zużytego pada i nie trzymałby on środka, bo puszczony swobodnie daje różne surowe odczyty z pewnego zakresu zależnie od przypadku.

Akurat do celowania w grze 2D będzie ok. Środkowy deadzone można sobie zaprogramować nawet na 0.4 i wtedy puszczony drążek nie będzie nic robił. im większe odchylenie drążka od środka, tym większa precyzja, a na podstawie wartości X Y określamy tylko kierunek celowania.

@axelbest: odnoszę wrażenie, że nie rozumiesz w czym tkwi problem, pomimo tego, że został on dokładnie opisany i zademonstrowany w filmiku. Problem jest ewidentny i w całej grupie gier stanowi poważny problem, utrudniający sterowanie (zobacz filmik z niebieskim kontrolerem).

axelbest napisał(a):

Gała możemy wykręcic 360 stopni. Jeśli mamy jakiś ruch który nie jest jednoznacznym kierunkiem góra/dół, prawo/lewo, zostają nam 4 pola gdzie mamy możliwe 90stopni. Gram na padach różnego typu od ponad 25 lat. Zatem problem leży w tym że OP chce chyba mieć 90 pośrednich wartości, co na przestrzeni tak małej jaką jest to co ogarniają nasze kciuki, jest troszke niezrozumiałe dla mnie. Nie wiem jaki byłby idealny zakres - ale doświadczenie mi mówi ze pomiędzy góra a prawo zazwyczaj występuje max 20 wartości pośrednich - po 10 od gałki ustawionej pod kątem 45st.

No nie, gałki analogowe, przepustnice i inne wajchy o regulowanej pozycji mają wielobajtową precyzję, co daje od 127 do dziesiątek tysięcy wartości pośrednich. Wartości odczytywane z pozycji potencjometrów są mapowane do takich zakresów i dostępne z poziomu jakiegoś API (np. systemowego, gdzie wartości osi siedzą w strukturze JOYINFOEX jako DWORD-y).

xy napisał(a):

Tam jak się używa pada "na surowo" (np. po kliknięciu "Raw Events" w jstest-gtk), to martwej strefy nie ma, czyli w tym przypadku raczej nie jest ona sprzętowa. W większości przypadków ma to słaby sens, bo widać duże niedoskonałości trochę zużytego pada i nie trzymałby on środka, bo puszczony swobodnie daje różne surowe odczyty z pewnego zakresu zależnie od przypadku.

Wartości surowe powinny być takie, jakie faktycznie są — to do programisty należy napisanie kodu w taki sposób, aby sterowanie było wygodne i w ogóle możliwe. I właśnie martwe strefy są jedną z rzeczy, które powinny być imeplementowane po stronie projektu gry, a nie po stronie kontrolera/sterownika. A drugą taką rzeczą jest uśrednianie wartości w celu wykluczenia mikro-drgań.

Tymczasem problem jest taki, że martwe strefy wzdłuż osi X i Y najwyraźniej są zaimplementowane właśnie po stronie gamepada, przez co nie da się ich wykluczyć w żaden sposób po stronie kodu źródłowego gry. A to powoduje, że taki kontroler nie może być użyty do grania, bo sterowanie jest równie gówniane co w przypadku wyrobionego do cna, starego rupiecia.

No niestety ale te gałki są bardzo niedokładne, im starszy kontroler (w sensie bardziej zużyty) tym bardziej - wartości nie są precyzyjne i cały czas oscylują wokół ustawionej pozycji. Gdyby nie było zaokrąglania / przyciągania to nawet na puszczonym drążku miałbyś losowe odczyty od -2,-2 do 2,2 (/127) albo nawet większe. W Twojej grze 2d może by to nie wyglądało nawet tak tragicznie ale w grach 3d gdzie ruch lewo / prawo / góra / dół obraca całą kamerą efekt by był jakby gracz miał zaawansowanego parkinsona

Problemem nie jest ”parkinson” wartości, a hardkodowane martwe strefy. Ile jeszcze off-topu się tu pojawi, zanim w końcu zrozumiecie o jakiego rodzaju problem chodzi?

są hardkodowane zapewne w sterowniku pada żeby game developerzy nie musieli się tym martwić
nawet w grze 2d bez tego u niektórych postać by się ciągle odwracała z lewa na prawo, do góry i w dół. To że u Spine'a zadziała dobrze jakaś tam wartość nie znaczy że na innym kontrolerze innej firmy będzie tak samo - najlepiej żeby ustalił to producent sprzętu. To nie jest tak że im większe odchylenie tym większa precyzja - wartości na osi Y drgają tak samo przy odchyleniu w prawo jak bez odchylenia, ma więc to sens że deadzone jest zrobiony na całej osi a nie tylko na środku.
Nie wiem czego nie rozumiesz

obscurity napisał(a):

są hardkodowane zapewne w sterowniku pada żeby game developerzy nie musieli się tym martwić

Zobacz, co napisał: @kzkzg

kzkzg napisał(a):

Aż z ciekawości podlaczylem pada od PS5. U mnie takie zjawisko (deadzone) nie wystepuje, tzn najmniejsze ruchy są sygnalizowane. Sprawdzane przez kalibracje w Steam, w menedżerze urzadzen w windowsie nie mam takich funcji we wlasciwosciach pada.

Sęk w tym, że jeśli jedne pady hardkodują (PS4), a inne nie (PS5), to wtedy programista kodujący własny deadzone dla pada PS5, wciąż jest skazany na deadzone hardkodowany dla PS4.

Być może to kwestia wydajności starszych konsol.
Jeśli kontroler obrabia dane, to konsola ma mniej roboty.

Jednak wątpię, żeby w PS4 przetwarzanie danych z analoga było wąskim gardłem...

Hardkodowanie działania drążka ogranicza jego ilość zastosowań. Przez co mogą go używać tylko gry z mechaniką wykorzystującą drążek w jedyny możliwy sposób. Zamyka to drogę do innowacji i eksperymentów.

Kontroler do PS4 jest dość drogi. A kontroler do PS5 to już w ogóle kosmos, żeby gracz go kupował tylko dla poprawnie działających drążków.

Wiadomo, że droższe pady swoją wygodą i żywotnością mogą górować nad tańszymi zamiennikami. Ale to frustrujące, że konieczny jest najdroższy markowy pad, tylko po to aby można było cieszyć się drążkami z akceptowalną precyzją.

obscurity napisał(a):

są hardkodowane zapewne w sterowniku pada żeby game developerzy nie musieli się tym martwić

No właśnie widać jak nie muszą się martwić. @Spine — czemu martwisz się nieistniejącym problemem? :D

nawet w grze 2d bez tego u niektórych postać by się ciągle odwracała z lewa na prawo, do góry i w dół.

A ten dalej swoje. Mowa o martwych strefach z d**y, a ten nawija o drganiach. Wymiękam.

Spine napisał(a):

Sęk w tym, że jeśli jedne pady hardkodują (PS4), a inne nie (PS5), to wtedy programista kodujący własny deadzone dla pada PS5, wciąż jest skazany na deadzone hardkodowany dla PS4.

IMO jest to zrobione po to, aby upośledzeni programiści nie musieli poświęcać połowy swojego życia na implementację martwych stref wzdłuż osi na potrzeby obsługi menu (lub innych elementów bazujących na kierunkach świata, nie na płynnych wartościach) z poziomu gałek analogowych. Kontroler sam w sobie ma te strefy zdefiniowane, więc programista wystarczy że sprawdzi kąt wychylenia i w ten sposób określi, że trzeba zmienić zaznaczenie/wartość menu. Oczywiście wg mnie taki jest powód — implementacja D-Pada w gałce analogowej, po prostu.

Dla mnie to szajz. Jako programista oczekuję, że poprzez API dostanę surowe dane, które sobie odpowiednio dostosuję do potrzeb własnej gry. Sam określę rozmiar martwej strefy pozycji neutralnej i sam obsłużę lub nie przyciąganie wartości do osi. Tzn. tak bym zrobił, gdymym miał szansę dostać jałowe dane, ale widać można o nich zapomnieć, w niektórych przypadkach.

furious programming napisał(a):

IMO jest to zrobione po to, aby upośledzeni programiści nie musieli poświęcać połowy swojego życia na implementację martwych stref wzdłuż osi na potrzeby obsługi menu (lub innych elementów bazujących na kierunkach świata, nie na płynnych wartościach) z poziomu gałek analogowych.

I tak mogłoby to być po prostu zaimplementowane w silniku do gier...

W Unity w wielu miejscach masz wybór. Przykładowo: sam programujesz fizykę obiektu, albo ustawiasz, żeby był dynamiczny i zdajesz się na samowolkę silnika fizycznego.

Więc drążki mogłyby mieć deadzone obsłużone przez silnik, albo ręcznie przez programistę.

Spine napisał(a):

I tak mogłoby to być po prostu zaimplementowane w silniku do gier...

No i jest zaimplementowane — w Unity np. sam znalazłeś gdzie to jest. Jest możliwość wyłączenia stref, jest też możliwość dostosowania ich do własnych potrzeb, ustalając ich rozmiar. Problem tylko taki, że silnik musi dostać dane jałowe, a takich nie dostaje w przypadku niektórych kontrolerów, więc ich wyłączenie w Unity niczego nie zmieni.

Jedyne co można zrobić to sprawdzić, czy da się cokolwiek ustawić w ustawieniach kontrolera lub podczas kalibracji w narzędziu systemowym. Ale że nie mam żadnego kontrolera z gałkami analogowymi, to i nie wiem jakie opcje są dla gałek wyświetlane podczas kalibracji.

@xy: Sprawdziłem na linuksie tego jstest-gtk z padem PS4 (na razie to najnowszy markowy pad, jakim dysponuję).
Niestety nawet z użyciem Raw Events pad jest nieczuły w okolicach osi...

Wreszcie miałem okazję zobaczyć na własne oczy jak sprawuje się pad do Xbox OneSeries.

Jak widać, osiowy deadzone nie występuje :]

Fajnie byłoby porównać do wcześniejszych Xboxowych padów, a na YouTube ciężko znaleźć testy drążków padów...
Najczęściej pady są demonstrowane podczas grania. Albo YouTuberzy pokazują jak pady są zbudowane, jak wyglądają i czym się różni wygląd różnych padów...
Zero aplikacji diagnostycznych/debugujących/kalibrujących.