Kalibrácia dotykovej vrstvy sun4i-ts

21.10.2014 23:44 | Přečteno: 6261× | Hardware | | poslední úprava: 22.10.2014 13:10

Na linuxe je možné dotykový display používať rôznymi spôsobmi. Lineárne dotykové vrstvy sa dajú nakalibrovať a používať priamo cez evdev (nepoznám však žiaden lightweight kalibrátor), alebo cez knižnicu tslib (tá zvláda aj nelineárne dotykové vrstvy). Tento blog bude tak trochu o konverzii kalibrácie z tslib-u na min/max hodnotu pre evdev, trochu o úprave knižníc tak aby dokázali pracovať s prehodenou osou a nakoniec o úprave kernelu.

Najskôr kalibrácia cez tslib

Tento krok je pomerne jdenoduchý. Po načítaní modulu sun4i-ts a nastavení premennej prostredia:

TSLIB_TSDEVICE=/dev/input/eventX"

stačí už len spustiť ts_calibrate, 5x ťuknúť na display a vygenerovaný konfiguračný súbor by sa mal nachádzať v /etc/pointercal. Kalibračný program sa dá vidieť po asi 10. sekunde tohto videa. Obsah súboru by mal vyzerať približne takto:

13612 0 -1109201 56 8652 -3018144 65536 800 480
----- - -------- -- ---- -------- ----- --- ---
  a   b     c     d    e     f       g   w   h

Posledné 2 čísla súboru sú šírka a výška displaya. Zvyšné divoko vyzerajúce konštanty sa používajú pri prepočte polohy zo snímača na polohu na displayi.

Príklad: Snímač má rozsah 0 - 4095 v oboch osiach. Na osi x' bola nameraná hodnota 2048, y' bola hodnota 1024. Poloha na displayi sa vypočíta ako:

x = (ax' + by' + c) / g
y = (dx' + ey' + f) / g

x = (13612*2048 + 0*1024 - 1109201) / 65536 = approx. 408.44994
y = (56*2048 + 8652*1024 - 3018144) / 65536 = approx. 90.884277

Po dokončení kalibrácie by mali aplikácie používajúce tslib byť schopné reagovať korektne na dotyky. Vyskúšať sa to dá pomocou ts_test alebo kľudne aj pomocou OpenTTD (áno v prvých sekundách videa som si zamotal prsty)

Zvyšok systému

Rôzne grafické frameworky / X server štandardne nepoužívajú tslib, ale čítajú priamo evdev zariadenia. Pri inicializácii sa zvyčajne vykonajú 2 magické volania ioctl, ktoré zistia minimálnu a maximálnu hodnotu na danej osi:

ioctl(fd, EVIOCGABS(ABS_X), &absInfo);
...
ioctl(fd, EVIOCGABS(ABS_Y), &absInfo);

Maximálna a minimálna hodnota sa nastavuje volaním EVIOCSABS.

Prevod kalibrácie z tslibu na evdev

Konštanty z /etc/pointercal umožňujú flexibilne nakalibrovať osi ľubovoľnej dotykovej vrstvy s lineárnou hodnotou zo snímača (existujú pluginy aj pre nelineárne dotykové vrstvy, ale s takou som sa nestretol). Tieto konštanty sa musia teda previesť na minimálnu a maximálnu hodnot. To je možné len pre dotykové vrstvy, kde nie sú osi umiestnené diagonálne (áno aj také existujú, nemal som tú česť ich vyskúšať). Takže ak sú všetky podmienky splnené stačí zobrať súradnice ľavého horného a pravého dolného rohu a vyrátať z nich predpokladané hodnoty zo snímača.

Z vyššie uvedených rovníc máme dané kalibračné konštanty a hodnoty x, y. Vypočítať sa musia príslušné x' a y' čo dosiahneme obyčajnou sústavou 2 rovníc o 2 neznámych. Nechcem tu nikoho trápiť matematikou, takže tu je kompletný kód ktorý načíta pointercal, vypočíta min, max hodnoty a nastaví ich cez EVIOCSABS priamo do zariadenia.

extern "C" {
#include <linux/input.h>
#include <sys/stat.h>
#include <fcntl.h>
}
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <iostream>
#include <fstream>

using namespace std;

static double constants[9];

double compute_x(double x, double y) {
    double c = constants[6] * x - constants[2];
    double q = constants[4];
    double r = constants[6] * y - constants[5];
    double b = constants[1];
    double a = constants[0];
    double p = constants[3];
    return (c*q-r*b)/(a*q-p*b);
}

double compute_y(double x, double y) {
    double c = constants[6] * x - constants[2];
    double p = constants[3];
    double r = constants[6] * y - constants[5];
    double a = constants[0];
    double b = constants[1];
    double q = constants[4];
    return (c*p-r*a)/(b*p-q*a);
}

int main(int argc, char *argv[])
{
    if (argc != 3) {
        cerr << "Usage: " << argv[0] << " /path/to/pointercal /dev/input/eventX" << endl;
        return -1;
    }

    ifstream pointercal(argv[1], ifstream::in);
    if (!pointercal.is_open()) {
        cerr << "File " << argv[1] << " not opened";
        return -1;
    }

    for (int i = 0; i < 9; ++i) {
        pointercal >> constants[i];
    }

    if (pointercal.bad()) {
        cerr << "Bad file format: " << argv[1];
    }

    double width = constants[7];
    double height = constants[8];

    double minx = (compute_x(0, 0) + compute_x(0, height - 1)) / 2.0;
    double maxx = (compute_x(width - 1, 0) + compute_x(width - 1, height - 1)) / 2.0;
    double miny = (compute_y(0, 0) + compute_y(width - 1, 0)) / 2.0;
    double maxy = (compute_y(0, height - 1) + compute_y(width - 1, height - 1)) / 2.0;

    cout
        << "MinX: " << static_cast<int>(minx) << "  "
        << "MaxX: " << static_cast<int>(maxx) << "  "
        << "MinY: " << static_cast<int>(miny) << "  "
        << "MaxY: " << static_cast<int>(maxy) << endl;

    int fd = open(argv[2], O_RDWR);
    if (!fd) {
        cerr << "File " << argv[2] << " not opened." << endl;
        return -1;
    }

    input_absinfo absInfo;
    memset(&absInfo, 0, sizeof(input_absinfo));

    absInfo.minimum = static_cast<int>(minx);
    absInfo.maximum = static_cast<int>(maxx);
    ioctl(fd, EVIOCSABS(ABS_X), &absInfo);

    absInfo.minimum = static_cast<int>(miny);
    absInfo.maximum = static_cast<int>(maxy);
    ioctl(fd, EVIOCSABS(ABS_Y), &absInfo);

    return 0;
}

Nefunguje to

Niektoré dotykové vrstvy majú niektoru z osí zrkadlovo prevrátenú. Takže minimálna hodnota je okolo 4095 a max hodnota okolo 0. Lenže to v X-kach a rôznych ďalších zbytočnostiach nefunguje. Takto vyzerá spracovanie napr v Qt:

qBound(hw_range_y_min, data->value, hw_range_y_max);

Čo by sa dalo prepísať ako:

qMax(hw_range_y_min, qMin(data->value, hw_range_y_max))

alebo s číslami:

qMax(4095, qMin(data->value, 0))

To samozrejme za každých okolností vráti hodnotu 4095. Opraviť sa to dá napr.

--- old/src/platformsupport/input/evdevtouch/qevdevtouch.cpp    2014-10-04 15:57:19.812329227 +0200
+++ new/src/platformsupport/input/evdevtouch/qevdevtouch.cpp    2014-10-04 15:57:11.315708591 +0200
@@ -434,7 +434,7 @@
     if (data->type == EV_ABS) {
 
         if (data->code == ABS_MT_POSITION_X || (m_singleTouch && data->code == ABS_X)) {
-            m_currentData.x = qBound(hw_range_x_min, data->value, hw_range_x_max);
+            m_currentData.x = qBound(qMin(hw_range_x_min, hw_range_x_max), data->value, qMax(hw_range_x_max, hw_range_x_min));
             if (m_singleTouch)
                 m_contacts[m_currentSlot].x = m_currentData.x;
             if (m_typeB) {
@@ -443,7 +443,7 @@
                     m_contacts[m_currentSlot].state = Qt::TouchPointMoved;
             }
         } else if (data->code == ABS_MT_POSITION_Y || (m_singleTouch && data->code == ABS_Y)) {
-            m_currentData.y = qBound(hw_range_y_min, data->value, hw_range_y_max);
+            m_currentData.y = qBound(qMin(hw_range_y_min, hw_range_y_max), data->value, qMax(hw_range_y_max, hw_range_y_min));
             if (m_singleTouch)
                 m_contacts[m_currentSlot].y = m_currentData.y;
                 if (m_typeB) {

Opravovať kvôli tomu každú knižnicu, ktorá používa evdev je tak trochu kontraproduktívne. Takže poďme si zababrať ruky hrabaním v jadre.

Zrkadlenie osi v kerneli

Nemám moc rád hardcoding, takže začneme úpravou script.fex pre našu dosku. Do sekcie [rtp_para] pridáme riadok rtp_invert_x = 1, ktorý v module sun4i-ts použijeme. Úprava samotného sun4i-ts je veľmi triviálna, takže nebudem moc chodiť okolo horúcej kaše:

--- sun4i-ts.c.old    2014-10-19 14:06:35.819329213 +0200
+++ sun4i-ts.c    2014-10-19 16:07:59.613202847 +0200
@@ -117,6 +117,7 @@
 static int tp_press_threshold = 0; //usded to adjust sensitivity of touch
 static int tp_sensitive_level = 0; //used to adjust sensitivity of pen down detection
 static int tp_exchange_x_y = 0;
+static int tp_invert_x = 0;
 
 //停用设备
 #ifdef CONFIG_HAS_EARLYSUSPEND
@@ -218,7 +219,8 @@
         /* The 1st location reported after an up event is unreliable */
         if (!ts_data->ignore_fifo_data) {
             /* pr_err("motion: %dx%d\n", x, y); */
-            input_report_abs(ts_data->input, ABS_X, x);
+            input_report_abs(ts_data->input, ABS_X, tp_invert_x ? 4095 - x : x);
             input_report_abs(ts_data->input, ABS_Y, y);
             /*
              * The hardware has a separate down status bit, but
@@ -446,6 +448,10 @@
     printk("rtp_used == %d. \n", device_used);
     if(1 == device_used){
 
+            if(SCRIPT_PARSER_OK != script_parser_fetch("rtp_para", "rtp_invert_x", &tp_invert_x, 1)){
+                pr_err("sun4i_ts_init: script_parser_fetch err rtp_invert_x. \n");
+                goto script_parser_fetch_err;
+            }
             if(SCRIPT_PARSER_OK != script_parser_fetch("rtp_para", "rtp_press_threshold_enable", &tp_press_threshold_enable, 1)){
                 pr_err("sun4i_ts_init: script_parser_fetch err rtp_press_threshold_enable. \n");
                 goto script_parser_fetch_err;

Po skompilovaní modulu jadra a jeho načítaní (samozrejme aj s upraveným script.bin) by mal ovládač reportovať hodnoty na x-ovej osi správne a po kalibrácii by hádam všetky slušnejšie aplikácie mali fungovať korektne.

       

Komentáře

[smazáno]

respekt

[pc2005]

Blbý je, že ta kalibrace u tslib je jen sedmiciferná a neumí všechny typy lineárních transformací (jako u mýho touchcreenu, kterej má za určitých podmínek různá zkosení u všech stran).

Jinak Xka umí i tu sedmicifernou i kompletní (jen dvě hodnoty v 3x3 matici nenulové)

xinput set-prop "ADS2046 Touchscreen" "Coordinate Transformation Matrix"

+ jsou tam i volby pro axes swap (Evdev Axes Swap, Evdev Axis Inversion, Evdev Axis Calibration).

BTW Zkoušel jsi ts_calibrate? U mě dokáže nakalibrovat osy libovolně převráceně (schválně jsem klikal na protilehlé rohy a fungovaly osové i bodové převrácení).

[mirec]

Práve na začiatu som súšal ts_calibrate a výsledok som potom zapísal cez ioctl do zariadenia. X-ka samozrejme pekne vedia kadečo (lenže na ARM-e s Xkami nenabootujem do sekundy), ani tslib nie je na zahodenie, ale keď Qt od verzie 5.3 pribaľuje input plugin evdevtouch ešte napevno zakompilovaný do eglfs platform pluginu tak som jednoducho musel vymyslieť ako ho dnonútiť fungovať aspoň s mojou dotykovou vrstvou. Inak evdevtouch je úplna primitívnosť čítajúca raw x, y hodnoty ktoré potom podľa min x/y a max x/y prevedie na koordináty displaya. Samozrejme v Qt sa dá používať aj tslib ... lenže evdevtouch sa nedá vypnúť takže mi vždy posielal každý event duplicitne a ešte aby som to mal celkom zábavné tak jeden event mal vždy prevrátenú x-ovú os (ten ktorý si prečítal evdevtouch). Takže to moje riešenie nie je ani univerzálne ani nejak extra flexibilné ale presne na môj usecase to sadlo. A ako bonus som som konečne dorobil akú-takú podporu multitouch do mojej virtuálnej klávesnice lebo tslib plugin do Qt podporuje len single touch a to emuluje pomocou mouse eventov.

[pc2005]

Aha tak pevná kompilace evdev do Qt je pěkně blbej nápad .

Nechtěl bys zkusit dát tu transformaci do obecné evdev vrstvy z kernelu? To by vyřešilo rozdíly mezi kalibracemi tslib, gpm, xorg a qt jednou provždy . Kompletní matice by pak vypadala asi takhle:

| a b c |   | x |
| d e f | * | y |
| g h i |   | 1 |

Vynásobeno pak (jmenovatel tu hodnotu zpětně normalizuje a umožňuje zbývající transformace v tslib případě je g=h=0):

x_transformed = ( a*x + b*y + c ) / ( g*x + h*y + i)
y_transformed = ( d*x + e*y + f ) / ( g*x + h*y + i)

K tomu bych mohl poslat aplikaci, co naměří body a spočítá ty koeficienty. Je sice pro Xka, ale používá jen věci typu drawline a maximalizace okna.

[mirec]

Aplikáciu na kalibráciu (aj bez X-iek) s počítaním koeficientov mám tiež (písal som si dávnejšie keď som pri prvom štarte svojej aplikácie chcel nejak elegantne cez wizard nakalibrovať LCD). Dať to do kernelu nie je až taký zlý nápad akurát chcem ešte preskúmať jeden komunitný driver ktorý údajne podporuje multitouch. Ak by bol lepší tak je zbytočné modifikovať oficiálny od výrobcu hardvéru ktorý práve používam.

[BFU]

Zrovna narvat vsechno do kernelu misto toho, aby se opravil userland je hodne spatny napad. Smrdi to resenim problemu na spatnem miste nebo dokonce obchazenim problemu. Zrovna zde ti nic nebrani userland rebuildnout a defektni casti opravit.

Tslib je tu k tomu, aby skrz ni userland komunikovat s driverem na dotykac v kernelu. Libovolne transformace a podobne serepeticky jsou v kernelu akorat na skodu -- pokud v tom kodu bude nejaky defekt, muze jednak sundat cely kernel a/nebo bude pro jeho odstraneni potreba ten kernel vymenit. Navic je to kod, ktery muze viset klidne v userlandu (ani nekomunikuje s HW, ani neni kriticky pro vykon systemu). Nakonec, evdev nema vracet zadnym zpusobem modifikovane input eventy, takze to do evdev skutecne nepatri.

Systematicke reseni je opravit defektni userlandovy komponenty popr. samotnou tslib.

[pc2005]

Tak já s tebou třeba souhlasím, ale člověka po nějaký době začne unavovat, když musí prolézat ten samý mechanismus několikrát a s různejma chybama. Ta kalibrace je fakt na několika místech (xka, GPM, tslib, ...) a jenom v xkách horko těžko v tuhle chvíli funguje "univerzálně".

Je sice prasárna mít v kernelu modifikaci dat, ale z hlediska kódu to je jen vynásobení maticí 3x3. Nehledě na to, že třeba u ADS7846 touchscreenu se vzorky nejdříve proženou debounce filtrem (vím, funguje hodně blbě, ale bez něj zase naprosto nefungují kalibrace) a event ABS_PRESSURE se vygeneruje komplikovaným výpočtem odporového děliče (hodnotu odporu dostane driver jako platform_data parametr).

[BFU]

> člověka po nějaký době začne unavovat, když musí prolézat ten samý mechanismus několikrát a s různejma chybama.

Proto staci opravit TSlib jednou, poradne a pak ji konsistentne pouzivat.

btw. Xka umi pouzivat tslib ( http://pengutronix.de/software/xf86-input-tslib/index_en.html ). GPM by asi stacilo patchnout, aby pouzivalo tslib.

> z hlediska kódu to je jen vynásobení maticí 3x3

Z hlediska kodu je to _nyni_ vynasobeni matici. Netrvalo by dlouho, nez by nekdo zacal vymyslet komplikovanejsi zalezitosti a ten kod by zacal kynout.

> hodnotu odporu dostane driver jako platform_data parametr

To je vcelku ocekavane, nelze predem vedet, jaky touchscreen k tomu chipu vyrobce pripoji. Nicmene i tak by se ta hodnota mela predavat spise pres DT.

[pc2005]

On to byl takový povzdech. Každý ten subsystém stojí paměť a výpočetní výkon (do driveru mě lezou kvanta dat, z evdevu už vyfiltrovaný - nekvalitně a z xek už je jich tak málo, že jsou pohyby kurzoru extra trhaný).

Z hlediska kodu je to _nyni_ vynasobeni matici. Netrvalo by dlouho, nez by nekdo zacal vymyslet komplikovanejsi zalezitosti a ten kod by zacal kynout.

Jo toho bych se taky bál. Nejhorší je, že různé aplikace vyžadují ruzné rozhraní a pak je člověk musí mít všechny nacpané v omezené embedded paměti. A přitom by stačilo jedno nebo dvě ioctl na /dev/input/eventX.

To je vcelku ocekavane, nelze predem vedet, jaky touchscreen k tomu chipu vyrobce pripoji. Nicmene i tak by se ta hodnota mela predavat spise pres DT.

DT nevedu, ale je to kompatibilní mechanismus s definicí v pdata . Jinak stejná věc je kalibrace IMHO, neboť mezní hodnoty závisí právě na tom odporu.

[mirec]

Ako už bolo napísané upraviť v jadre je najmenej pracné riešenie. Situácia by bola jednoduchšia keby existoval jeden univerzálny spôsob ako kalibrovať a transformovať vstup. Lenže ten nie je ... X-ka si to riešia po svojom (na embedded zariadení si ich nemôžem dovloiť), Qt si to rieši posvojom (áno je tam aj podpora tslibu), SDL si to rieši posvojom ... väčšinou by sa to dalo poriešiť vyhodením všetkých ostatných inputov a použitím tslibu ale aj samotný tslib treba upraviť kvôli podpore multitouchu no a potom treba upraviť aj všetky aplikácie / knižnice používajúce tslib aby zvládali multitouch. Preto som sa rozhodol pre jednoduchú úpravu modulu jadra.

No nezostáva nám nič iné len čakať na systemd-tslibd ktorý všetko konečne zjednotí

[BFU]

> Situácia by bola jednoduchšia keby existoval jeden univerzálny spôsob ako kalibrovať a transformovať vstup.

tslib

> X-ka si to riešia po svojom

Xka umi tslib, viz vyse.

> Qt si to rieši posvojom

Pokud myslis Qt/Embedded , pak $ export QWS_MOUSE_PROTO=Tslib:/dev/input/touchscreen0

> SDL si to rieši posvojom

$ export SDL_MOUSEDRV=TSLIB $ export SDL_MOUSEDEV=$TSLIB_TSDEVICE

> ...aby zvládali multitouch

Input layer v linuxu posila jak MT eventy, tak emulovane ST eventy. Neni potreba upravovat nic, pokud je spravne naimplementovany driver pro multitouch. Viz input_mt_report_pointer_emulation() a spol.

[pc2005]

tslib

Já jsem například tslib zavrhl proto, že do komunikace nic nepřidá a je pomalej (pro Xka má míň voleb než evdev driver). Kdyby byla kalibrace v input vrstvě, tak bych se mohl přestat starat i o Xka a navíc bych mohl číst validní údaje přímo v shell skriptu .

[BFU]

> Já jsem například tslib zavrhl proto, že do komunikace nic nepřidá

tslib se stara o transformaci souradnic na nelinearnich touchscreenech. Evdev se da pouzivat primo pouze pokud ten touchcontroller sam zvlada takovou korekci delat (typicky USB HID MT atp.)

> a je pomalej (pro Xka má míň voleb než evdev driver)

Samozrejme, to prepocitavani v software bude vzdy pomale. Netusim sice jak rychlost souvisi s poctem voleb, ale OK.

> Kdyby byla kalibrace v input vrstvě, tak bych se mohl přestat starat i o Xka a navíc bych mohl číst validní údaje přímo v shell skriptu

Na to ma tslib taky nejaky tool, ts_harvest nebo ts_print nebo tak neco.

[pc2005]

tslib se stara o transformaci souradnic na nelinearnich touchscreenech

Do komunikace s Xkama. Evdev driver v xkách má svojí vlastní kalibraci, která pokryje víc nepřesností než tslib (včetně věcí jako emulace druhého tlačítka pokud dotyk na jednom místě dost dlouho). BTW co myslíš tou nelinearitou, já mám za to, že tslib umí jen lineární transformace (zkosení a offset a možná další - to je automaticky v té matici). Je ale fakt, že jsem měl na verze tslibu dost smůlu (furt něco nefungovalo).

Samozrejme, to prepocitavani v software bude vzdy pomale. Netusim sice jak rychlost souvisi s poctem voleb, ale OK.

Moje chyba, moc jsem editoval, to měla být další vlastnost .

ts_print

Jo to jsem používal, v shellu to bylo moc pomalý, nakonec jsem přešel do Xek (kde v X input vrstvě vypadávaly eventy). V tuhle chvíli čtu v xkách přímo evdev a můžu načíst tak tisíce měření za sekundu (X input přímo z evdevu vypadával a X input z tslibu by měl výpočetní blok navíc).

BTW taky je nějaká aplikace v GPM, akorát tam je EV_ABS dost zplácanej a ignoruje se synchronizace, takže při "pen down" má jedna z os ještě minulou hodnotu. Bohužel patch by byl ve smyslu: předělat to znova a na to zrovna nemám čas .

[mirec]

Pokud myslis Qt/Embedded , pak $ export QWS_MOUSE_PROTO=Tslib:/dev/input/touchscreen0

Myslim Qt5 / eglfs (áno do verzie 5.2 bol tslib jediná možnosť ako tam dostať dotykové ovládanie a +/- to fungovalo, od 5.3 je napevno zakompilovaný evdevtouch ktorý sa zahákne na /dev/input/eventX ktorý má ABS a kalibruje sa len pomocou min / max hodnôt takže s ničím iným než lineárny neotočený neskreslený signál s ním nebude fungovať, odstrániť a nahradiť znovy tslibom by to šlo ale keď som len tak vyskúšal evdevtouch ... tak ide o toľko lepšie, že tam tslib jednoducho nechcem).

K SDL ... nepáči sa mi spôsob ako sa to musí nastavovať, inak práve s týmto som nahrával to video v blogu.

Input layer v linuxu posila jak MT eventy, tak emulovane ST eventy.

Áno, lenže použitím tslibu stratím multitouch.

Osobne nevidím nič zlé na kalibrácii priamo v kerneli. Áno, je to potenciálne vec ktorá sa môže rozbiť ale tých je v kerneli ... no povedzme dosť. Na druhej strane chcieť po userspace aby hádal čo je pripojené ku konkrétnemu /dev/input/eventX ak to môže náhodou vedieť kernel ... fakt by som mal radšej už pekne upravené hodnoty (a kľudne nech sa posielajú aj s raw ak niekto chce) priamo z kernelu.

[pavlix]

Osobne nevidím nič zlé na kalibrácii priamo v kerneli. Áno, je to potenciálne vec ktorá sa môže rozbiť ale tých je v kerneli ... no povedzme dosť.

+1

V kernelu je tuna věcí, které tam vyloženě nepatří, tak proč tam nedat jednu, u které se inkluze do kernelu přímo nabízí?

[BFU]

Vysvetli mi, jaka je vyhoda mit takove prepocitavani v kernelu oproti userlandu.

[mirec]

Vyrieši sa to na jednom mieste a bude fungovať bez ohľadu aké knižnice / frameworky userland používa. Myslím že by to bolo konzistentnejšie správanie riešiť to v kerneli a nechať userland pracovať so zariadením rovnako ako v prípade klávesnice / myši (teda bez dodatočnej knižnice). Okrem toho už teraz výrobcovia HW dávajú do svojich ovládačov veci ako dejitter, nastavenie tlaku a pod. S použitím tslib-u som mal dvojitý dejitter a ešte ako bonus Qt 5 tslib plugin má vlastný dejitter takže v konečnom dôsledku to oproti surovému zariadeniu poriadne sekalo.

[BFU]

> Vyrieši sa to na jednom mieste a bude fungovať bez ohľadu aké knižnice / frameworky userland používa

Pokud by clovek postupoval timto smerem, pak by se do kernelu dalo splachnout ovsem uplne vse, ze ...

> ...rovnako ako v prípade klávesnice / myši

Zrovna na tohle se casto pouzivaji knihovny taky. Napr. veci jako xinput atp.

> Okrem toho už teraz výrobcovia HW dávajú do svojich ovládačov veci ako dejitter, nastavenie tlaku a pod.

Ne kazdy touch tohle umi (!). Input subsys v linuxu umi exportovat do userlandu ruzne informace o input zarizenich, cili by stacilo do userlandu vyexportovat, ze zarizeni uz dejitter udelalo a ze userlandova knihovna muze delat pouze passthrough.

> S použitím tslib-u som mal dvojitý dejitter a ešte ako bonus Qt 5 tslib plugin má vlastný dejitter...

Nasledek nesystematickeho reseni, kdy si kazdy patla svoje reseni znovu, protoze vi, ze to zvladne lepe ... misto toho, aby se udelala jedna knihovna a poradne.

[pc2005]

Nasledek nesystematickeho reseni, kdy si kazdy patla svoje reseni znovu, protoze vi, ze to zvladne lepe ... misto toho, aby se udelala jedna knihovna a poradne.

Souhlasím, jenže která? Musela by umět všechny polohovací zařízení (ať relativní, tak absolutní) a navíc by musela být opravdu dobře udržovaná (což GPM není a tslib neumí). Jedinej projekt, kterej je dobře udržovanej je právě kernel. Nebo vyrobit něco novýho, ale to je pak cesta do pekel nebo do systemd . Situace v tuhle chvíli vypadá tak, že pokud člověk chce třeba vylepšit transformace os, tak musí patchout několik projektů stejným algoritmem, přičemž minimálně Xka a asi i Qt se rekompilují poměrně komplikovaně.

[BFU]

> ...ktorý má ABS a kalibruje sa len pomocou min / max hodnôt...

Aha, uz chapu o co jde. Ten evdevtouch ocekava, ze to zarizeni je skutecne predkalibrovane a chova se linearne (cili jako USB MT HID zarizeni atp). Pokud se tak ten touch nechova, tak zrejme ten evdevtouch neni input, ktery se ma pro nej pouzivat.

> K SDL ... nepáči sa mi spôsob ako sa to musí nastavovať

Patch jde poslat vzdy. Tohle res na SDL ML.

> Áno, lenže použitím tslibu stratím multitouch.

OK, chapu. Nejde tslib upravit, aby umel MT ?

> Osobne nevidím nič zlé na kalibrácii priamo v kerneli.

Jaky je pro to duvod? Nevidim nic, co by branilo mit to prepocitavani v userlandove knihovne a tu pouzivat. Je lepsi mit v kernelu mene veci, ktere se mohou pokazit ; cim mene tim lepe.

[mirec]

OK, chapu. Nejde tslib upravit, aby umel MT ?

Je potrebné upraviť API a samozrejme potom prepísať každú userland aplikácu / knižnicu ktorá používa tslib aby používala multitouch.

[BFU]

Kazda vec, co MT nepouziva, tak bude pouzivat pouze ST eventy. Proto tam ta emulate ST eventu na MT zarizenich je, zejo ...

[mirec]

S emuláciou to nemá nič spoločné. Problém je so samotným tslib-om ktorý definuje touch event ako:

struct ts_sample {
    int	x;
    int	y;
    unsigned int    pressure;
    struct timeval  tv;
};

Takže pre podporu API sa musí buť breaknúť súčasné API a rozbiť tým všetko alebo dorobiť multitouch api tak aby jedno API emulovalo myš ako doteraz a druhé riešilo multitouch. Tak či tak treba dopísať podporu všade kde sa má používať multitouch. Tslib to v súčasnosti nedokáže a preto knižnice ktoré podporujú multitouch (ako Qt) používajú evdev priamo.