Meerdere muizen uitlezen

[Arjan]

gegroet,

Ik ben een tijd geleden linux in gerold en wat kleine problemen buiten beschouwing gelaten zeer tevreden. Nu wilde ik voor een spelletje waar ik mee bezig ben twee muizen uit kunnen lezen.

Als ik me niet vergis kunnen HID devices als muizen uitgelezen worden door /dev/input/event* aan te spreken. Het lijkt me op die manier dan ook niet al te moeilijk (ja, als het makkelijk was deed ik het wel ) om de gegevens van de muis zoals de hoeveelheid die er in de x of y richting bewogen is uit te lezen per muis.

Maar om eerlijk te zijn heb ik geen idee waar te beginnen. Via google kom ik eigenlijk alleen maar uit bij dingen als xdev, die dus de muis uitlezen zoals X 'm gebruikt. Dat terwijl ik eigenlijk één stapje hoger wil.

Heeft iemand enig idee om mij op weg te helpen? is er bijvoorbeeld een utility die een soort van raw-data kan uitspugen over wat ie op een input binnenkrijgt? alle hulp mbt. dit onderwerp is welkom natuurlijk!

Alvast bedankt

[CyBeR]

Bedoel je zoiets als /dev/input/mice? Dat is voor alle muizen samen.

[Arjan]

ja, ik was even verward door het geknoei met een wacom tablet dat ik aan de gang probeerde te krijgen.

Het gaat mij erom de muisbewegingen die dus laten we zeggen op mice0/1 binnenkomen apart weg te schrijven naar een textfile. Ik heb echter totaal geen idee hoe ik de inkomende data aanspreek...

[CyBeR]

/dev/input/mice en /dev/input/mouseX zijn afaik PS/2 data. (In werkelijkheid hangt er meestal een USB muis aan, maar de input layer maakt daar PS/2 van zodat dingen als X weten wat er mee te doen).

[Arjan]

Als ik het goed heb begrepen is het als volgt:
(/dev/input/mice, /dev/input/mouse enzo) -> kernel driver -> /dev/input/eventX
Op die manier komt er bij elke wijziging data in de eventX

toch?
Dan zou het toch mogelijk moeten zijn om de x en y waarden van bijv. mouse0 uit te lezen, al moet het via eventX. Als die aanname klopt dan lijkt het me ook niet zo'n probleem om een 2e muis apart uit te lezen, zodat je effectief 4 verschilende waarden kan lezen (twee maal x en twee maal y as).

Dat is wat ik probeer te bereiken, maar ik weet dus niet of bijv. /dev/input/mouse0 zomaar uit te lezen is.

[daft_dutch]

ik neem aan dat je het met de GUI doet.
kan je meerdere muizen toe voegen aan de configuratie
maar er is maar 1 mouse pointer

[CyBeR]

Je kunt afaik geen X en Y waarden uitlezen, omdat de grootte van X en Y niet gedefinieerd is. Muisbewegingen zijn altijd relatief.

[Arjan]

daft_dutch schreef op zaterdag 01 oktober 2005 @ 01:32:
ik neem aan dat je het met de GUI doet.
kan je meerdere muizen toe voegen aan de configuratie
maar er is maar 1 mouse pointer

Omdat het me niet om de cursor gaat hoeft het niet via GUI, het mag gewoon naar een txt filetje

CyBeR schreef op zaterdag 01 oktober 2005 @ 01:39:
Je kunt afaik geen X en Y waarden uitlezen, omdat de grootte van X en Y niet gedefinieerd is. Muisbewegingen zijn altijd relatief.

Het gaat mij ook om de bewegingen, de plek van de cursor is voor mij niet interesant

[CyBeR]

Mja. D'r is wel een programma dat dat kan. Maar ik kan met met geen mogelijkheid herinneren hoe het heet. Zoek eens wat rond op freshmeat.net?

[Verwijderd]

Dude, linux is open source. Gezien het feit dat je je muis kunt bewegen, en er dan wat gebeurd, is er al code die je muisbewegingen registreert.

Uit de make menuconfig van de kernel (mouse event interface) :

Say Y here if you want your mouse to be accessible as char devices
13:32+ - /dev/input/mouseX and 13:63 - /dev/input/mice as an
emulated IntelliMouse Explorer PS/2 mouse. That way, all user space
programs (including SVGAlib, GPM and X) will be able to use your
mouse

Kijk daar, ene snodaard GPM maakt gebruik van je muis. Dan moet die dus code bevatten die dat doet.
hier kun je de gpm source downloaden.

code:

/*-------------------------------------------------------------------
 * fetch the actual device data from the mouse device, dependent on
 * what Gpm_Type is being passed.
 *-------------------------------------------------------------------*/
static inline char *getMouseData(int fd, Gpm_Type *type, int kd_mode)
{
   static unsigned char data[32]; /* quite a big margin :) */
   char *edata=data+type->packetlen;
   int howmany=type->howmany;
   int i,j;

/*....................................... read and identify one byte */

   if (read(fd, data, howmany)!=howmany) {
      if (opt_test) exit(0);
      gpm_report(GPM_PR_ERR,GPM_MESS_READ_FIRST, strerror(errno));
      return NULL;
   }

   if (kd_mode!=KD_TEXT && fifofd != -1 && opt_rawrep)
      write(fifofd, data, howmany);

   if ((data[0]&(m_type->proto)[0]) != (m_type->proto)[1]) {
      if (m_type->getextra == 1) {
         data[1]=GPM_EXTRA_MAGIC_1; data[2]=GPM_EXTRA_MAGIC_2;
         gpm_report(GPM_PR_DEBUG,GPM_EXTRA_DATA,data[0]);
         return data;
      }
      gpm_report(GPM_PR_DEBUG,GPM_MESS_PROT_ERR);
      return NULL;
   }

/*....................................... read the rest */

   /*
    * well, this seems to work almost right with ps2 mice. However, I've never
    * tried ps2 with the original selection package, which called usleep()
    */
     
   if((i=m_type->packetlen-howmany)) /* still to get */
      do {
         j = read(fd,edata-i,i); /* edata is pointer just after data */
         if (kd_mode!=KD_TEXT && fifofd != -1 && opt_rawrep && j > 0)
            write(fifofd, edata-i, j);
         i -= j;
      } while (i && j);

   if (i) {
      gpm_report(GPM_PR_ERR,GPM_MESS_READ_REST, strerror(errno));
      return NULL;
   }
     
   if ((data[1]&(m_type->proto)[2]) != (m_type->proto)[3]) {
      gpm_report(GPM_PR_INFO,GPM_MESS_SKIP_DATA);
      return NULL;
   }
   gpm_report(GPM_PR_DEBUG,GPM_MESS_DATA_4,data[0],data[1],data[2],data[3]);
   return data;
}

Nu heb ik er niet genoeg tijd in gestoken om te zien of je uberhaupt iets hebt aan deze code. Het gaat meer om het advies er achter, er is al genoeg muis-gebruikende code en van het meeste is de source te downen.

[AlterEgo]

CyBeR schreef op zaterdag 01 oktober 2005 @ 02:00:
Mja. D'r is wel een programma dat dat kan. Maar ik kan met met geen mogelijkheid herinneren hoe het heet. Zoek eens wat rond op freshmeat.net?

* AlterEgo graaft mee in zijn legacy storage.

Ik dacht dat het backstreet ruby heette.
Daarmee kun je dit soort kunsten uithalen.

[Arjan]

Verwijderd schreef op zaterdag 01 oktober 2005 @ 04:16:
Dude, linux is open source. Gezien het feit dat je je muis kunt bewegen, en er dan wat gebeurd, is er al code die je muisbewegingen registreert.

daar hoopte ik ook op ja

Uit de make menuconfig van de kernel (mouse event interface) :

[...]


Kijk daar, ene snodaard GPM maakt gebruik van je muis. Dan moet die dus code bevatten die dat doet.
hier kun je de gpm source downloaden.

[...]

Nu heb ik er niet genoeg tijd in gestoken om te zien of je uberhaupt iets hebt aan deze code. Het gaat meer om het advies er achter, er is al genoeg muis-gebruikende code en van het meeste is de source te downen.

Hoewel ik deze code waarschijnlijk wel kan gebruiken had ik gehoopt dat het met een simpel scriptje op te lossen was.

Ik ben helaas niet bekend met dit GPM gebeuren... Ik weet niet eens wat ik nu heb als ik het geheel compile (kan het ook niet testen aangezien deze comp. wat problemen heeft met linux)
Houd ik dan een programma over dat als daemon draait ofzo? En als ik code om naar een textfile te schrijven in de gpm.c zou zetten, zou dat werken? of moet ik een nieuw programma schrijven dat gebruik maakt van wat GPM aanbied?

Ja, n00b vragen misschien maar ik voel me een beetje verdwaald

AlterEgo schreef op zaterdag 01 oktober 2005 @ 09:40:
[...]


* AlterEgo graaft mee in zijn legacy storage.

Ik dacht dat het backstreet ruby heette.
Daarmee kun je dit soort kunsten uithalen.

Die optie had ik wel al gezien, maar ik kan er helaas geen gebruik van maken omdat het uiteindelijk moet gaan werken op 'n mac-mini.

[Keeper of the Keys]

Ik zal het wel helemaal verkeerd hebben begrepen, maar zou:

code:

cat /dev/input/mouseX > bestand

niet gewoon moeten doen wat jij wilt?

(Ik probeerde het net met /dev/psaux en dat werkte, niet dat het verder (voor mensen) leesbaar was maar de data van de muis stond in een bestand...
Dit is eigenlijk hoe ik altijd test of de muis werkt vanuit console)

[Arjan]

verdomd

Als het me lukt om de data in een nuttige vorm te krijgen, dan zou dit een hele simpele oplossing voor m'n probleem zijn

Hoe stop je met 'luisteren' ?
ik deed dit nu door m'n terminal venster te sluiten, maar daar heb je in een scriptje natuurlijk weinig aan.

[Arjan]

zou iemand mij nog verder op weg kunnen helpen?
Ik ben niet zo thuis in de linux console en kan nav. de pagina's die ik erover gelezen heb niet oordelen of ik de benodigde gegevens nou wel of niet dmv. een script kan uitfilteren.

Wat ik nodig heb is het volgende:

bv /dev/input/mouse0 -> buffer -> filteren op bep. commando's -> commando's die van belang zijn naar een textfile schrijven.

Het lijkt me dat dit moet kunnen, maar ik ben nog niet veel verder gekomen.
op de een of andere manier loopt het commando

code:

cat /dev/input/mouse0 bs=1024 count=1 > /home/atgast/test.txt

vast, in de zin dat ik eigenlijk alleen nog maar ctrl+alt+del kan doen na enige tijd

[ Voor 4% gewijzigd door Arjan op 05-10-2005 01:44 ]

[SambalBij]

Atgast schreef op woensdag 05 oktober 2005 @ 01:44:

Het lijkt me dat dit moet kunnen, maar ik ben nog niet veel verder gekomen.
op de een of andere manier loopt het commando

code:

cat /dev/input/mouse0 bs=1024 count=1 > /home/atgast/test.txt

vast, in de zin dat ik eigenlijk alleen nog maar ctrl+alt+del kan doen na enige tijd

Dat verbaast me niet heel veel, aangezien bs= en count= geen opties zijn van cat maar van dd

probeer het eens met 'dd if=/dev/input/mouse0 of=/home/atgast/test.txt bs=1024 count=1'
Dat commando blijft waarschijnlijk ook 'hangen' totdat ie 1024 bytes heeft verwerkt.

[Da Fox]

"in de zin dat ik eigenlijk alleen nog maar ctrl+alt+del kan doen na enige tijd"
Probeer eens ctrl+c?

[ Voor 8% gewijzigd door Da Fox op 05-10-2005 13:00 . Reden: typo fix ]

[DeMoN]

Da Fox schreef op woensdag 05 oktober 2005 @ 13:00:
"in de zin dat ik eigenlijk alleen nog maar ctrl+alt+del kan doen na enige tijd"
Probeer eens ctrl+c?

Of switch naar een andere console (ctrl+alt+F1)* en kill het proces?

*F1 t/m F6, meestal.

[ Voor 4% gewijzigd door DeMoN op 05-10-2005 13:20 ]

[Arjan]

ctrl+c werkte inderdaad, ik ben in de tussentijd nog een beetje aan het zoeken geweest, maar loop consequent vast op het probleem dat de meeste guides met code aan komen zetten. Daarom heb ik voorlopig maar even het idee opzij gezet dat dit dmv scripting opgelost kan worden. Nu heb ik wel enige programeer ervaring, maar dat beperkt zich tot script-talen, java en een beetje C++.

Ik had een guide gevonden: http://www.linuxjournal.com/article/6396
Dat leek mij een zeer geschikt document om een beetje te kunnen testen met het lezen van inputs. Echter, de links die in het document staan, bv: http://www.linuxjournal.c.../lj/0106/6396/6396l2.html
die kan ik niet compilen. Nu weet ik toch al next-to-nothing van C maar ik kom op deze manier dus totaal geen stap verder, hetgeen ik erg jammer vind.
Foutmelding bij het compilen met tcc:

code:

/usr/include/linux/jiffies.h:84: ';' expected

alles wat me nu weer een stap verder kan helpen is welkom

[edeboeck]

Atgast schreef op zondag 09 oktober 2005 @ 18:10:
...Foutmelding bij het compilen met tcc:

code:

/usr/include/linux/jiffies.h:84: ';' expected

alles wat me nu weer een stap verder kan helpen is welkom

Net zoals in C++, eindig je elk statement in C met een ";".
Kijk eens in die header-file (jiffies.h) op regel 84 of er geen ; ontbreekt (en check voor alle zekerheid ook maar regel 83).

Sorry als dit je geen millimeter vooruit helpt, maar het is al wat ik kan doen ...

[Arjan]

die missende ';' lijkt het probleem niet te zijn. Het 64bit gedeelte in quote's zetten levert weer andere foutmeldingen, dus ik ben bang dat ook dit een doodlopende weg is

[ Voor 7% gewijzigd door Arjan op 09-10-2005 18:33 ]

[MSalters]

Tip: [code=c] tags. Ik gok verkeerde compiler; __attribute is volgens mij gcc-specifiek.

[QuasaR]

Atgast schreef op zondag 09 oktober 2005 @ 18:33:
[afbeelding]

die missende ';' lijkt het probleem niet te zijn. Het 64bit gedeelte in quote's zetten levert weer andere foutmeldingen, dus ik ben bang dat ook dit een doodlopende weg is

Regel 77 mist volgens mij wel een ; op het eind (of hoeft dat bij definities niet?)

[smokalot]

volgens mij hoeft dat idd niet, de preprocessor commando's worden namelijk door een newline beeindigd. C (en java, php, enz) gebruiken de ;, zodat je meerdere commando's op een regel kunt zetten.

[Arjan]

MSalters schreef op maandag 10 oktober 2005 @ 00:19:
Tip: [code=c] tags. Ik gok verkeerde compiler; __attribute is volgens mij gcc-specifiek.

met gcc zijn het aantal fouten totaal niet te overzien, no luck there.

En er staan nergens ; achter defenities dus ik neem aan dat dat geen probleem is.

[Arjan]

Ik heb misschien toch nog iets waarmee ik met m'n console optie verder kan.
Na de output van het dd commando eindeloos te bestuderen () bekeek ik het eens op hexadecimale wijze in Ultra Edit.
Dit kwam er uit bij het bewegen van de muis (X-as, naar links)

code:

^Xþ^@^Xý^@^Xþ^@^Xþ^@^Xþ^@^Xþ^@^Xþ^@^Xý^@^Xþ^@^Xý^@^Xý^@^Xý^@^Xü^@^Xü^@^Xü^@^Xü^$

is in HEX

code:

00000000h: 5E 58 FE 5E 40 5E 58 FD 5E 40 5E 58 FE 5E 40 5E ; ^Xþ^@^Xý^@^Xþ^@^
00000010h: 58 FE 5E 40 5E 58 FE 5E 40 5E 58 FE 5E 40 5E 58 ; Xþ^@^Xþ^@^Xþ^@^X
00000020h: FE 5E 40 5E 58 FD 5E 40 5E 58 FE 5E 40 5E 58 FD ; þ^@^Xý^@^Xþ^@^Xý
00000030h: 5E 40 5E 58 FD 5E 40 5E 58 FD 5E 40 5E 58 FC 5E ; ^@^Xý^@^Xý^@^Xü^
00000040h: 40 5E 58 FC 5E 40 5E 58 FC 5E 40 5E 58 FC 5E 24 ; @^Xü^@^Xü^@^Xü^$

Zoals je kan zien zit de volgende reeks erin:
5E 58 F* 5E 40
waaruit ik de wellicht voorbarige conlusie trek dat het F* blok de relative verandering in de X-as is.

om dit te testen zal ik de input data een beetje moeten bewerken, any thoughts on that?

[MSalters]

Atgast schreef op maandag 10 oktober 2005 @ 14:09:
[...]
met gcc zijn het aantal fouten totaal niet te overzien, no luck there.

En er staan nergens ; achter defenities dus ik neem aan dat dat geen probleem is.

Check: het is GCC, en achter definities staat altijd een ; (#define is geen definitie maar een macro)

[Soultaker]

Je bent een Linux kernel module aan het compileren, als ik het goed begrijp? Dan zou ik om te beginnen eens -D__KERNEL__ -DMODULE meegeven aan de compiler, anders gaat het helemaal nooit werken.

(Zorg er ook voor dat je de juiste kernel headers gebruikt, anders gaat het afaik ook stuk.)

[Arjan]

Soultaker schreef op dinsdag 11 oktober 2005 @ 00:48:
Je bent een Linux kernel module aan het compileren, als ik het goed begrijp? Dan zou ik om te beginnen eens -D__KERNEL__ -DMODULE meegeven aan de compiler, anders gaat het helemaal nooit werken.

(Zorg er ook voor dat je de juiste kernel headers gebruikt, anders gaat het afaik ook stuk.)

Als het goed is heb ik de juiste kernel headers, de stroom van fouten is dermate groot dat ik em niet eens kan plakken, en "gcc -D__KERNEL__ -DMODULE ./register.c > errors.txt" werkt ook niet, maar dat heeft vast andere redenen.
hier een greep uit de foutmeldingen:

code:

In file included from /usr/include/linux/sched.h:28,
                 from /usr/include/linux/fs.h:217,
                 from /usr/include/linux/input.h:776,
                 from ./register.c:1:
/usr/include/linux/signal.h: At top level:
/usr/include/linux/signal.h:30: error: syntax error before 'siginfo_t'
/usr/include/linux/signal.h:32: error: syntax error before '}' token
/usr/include/linux/signal.h:235: error: syntax error before '*' token
In file included from /usr/include/linux/sched.h:103,
                 from /usr/include/linux/fs.h:217,
                 from /usr/include/linux/input.h:776,
                 from ./register.c:1:
/usr/include/linux/resource.h:22: error: field 'ru_utime' has incomplete type
/usr/include/linux/resource.h:23: error: field 'ru_stime' has incomplete type
In file included from /usr/include/linux/sched.h:195,
                 from /usr/include/linux/fs.h:217,
                 from /usr/include/linux/input.h:776,
                 from ./register.c:1:
/usr/include/linux/aio.h:55: error: syntax error before 'ssize_t'
/usr/include/linux/aio.h:66: error: syntax error before 'ki_pos'
/usr/include/linux/aio.h:69: error: syntax error before 'ki_nbytes'
/usr/include/linux/aio.h:71: error: syntax error before 'ki_left'
/usr/include/linux/aio.h:78: error: syntax error before '}' token
/usr/include/linux/aio.h:157: error: syntax error before 'wait_on_sync_kiocb'
/usr/include/linux/aio.h: In function 'list_kiocb':
/usr/include/linux/aio.h:194: error: dereferencing pointer to incomplete type
/usr/include/linux/aio.h:194: error: invalid use of undefined type 'struct kiocb'

nja, een grote troep dus, het lijkt mij verstandig ivm beperkte C ervaringe me toch maar weer meer te richten op de console oplossing

Moet ik alleen de input kunnen converten naar een formaat waar ik wat mee kan...

[Soultaker]

Atgast schreef op woensdag 12 oktober 2005 @ 23:34:
Als het goed is heb ik de juiste kernel headers, de stroom van fouten is dermate groot dat ik em niet eens kan plakken, en "gcc -D__KERNEL__ -DMODULE ./register.c > errors.txt" werkt ook niet, maar dat heeft vast andere redenen.

Ja; de foutmeldingen gaan naar een aparte error stream. Als je sh of bash gebruikt kun je 'gcc ....blablabla.. 2> errors.txt' doen om de error stream te redirecten. Is handig om de foutmeldingen en de gewone uitvoer te kunnen scheiden.

hier een greep uit de foutmeldingen:
<knip>

Je gebruikt nu de headers in /usr/include; die zijn bedoeld om usermode programma's mee te compileren, geen kernel modules. De kernel sources staan normaliter in /usr/src/<kernelnaam>/.

Je kunt proberen te compileren met: 'gcc -D__KERNEL__ -DMODULE -isystem /usr/src/`uname -r` -O2 -c register.c -o register.ko'. Ik hoop dat ik zo compleet ben (anders moet je het zelf even nazoeken); in ieder geval zijn optimalisaties verplicht (er zijn inline functies die niet in de kernel zitten). De kernelmodule kun je dan (als het goed is) laden met insmod.

Mja, een grote troep dus, het lijkt mij verstandig ivm beperkte C ervaringe me toch maar weer meer te richten op de console oplossing

Ja, dat lijkt me veel slimmer, ook omdat je anders elke keer die kernel module moet gaan zitten recompilen en herinstalleren.

[Soultaker]

Atgast schreef op woensdag 12 oktober 2005 @ 23:34:
Moet ik alleen de input kunnen converten naar een formaat waar ik wat mee kan...

Het is gewoon PS/2 data. Alle muizen zitten standaard in PS/2 streaming mode voor zover ik weet; als je extra features wil gebruiken (zoals een scrollwiel) moet je die expliciet aanzetten. Ik heb even zitten testen met een protocolbeschrijving die ik hiervandaan geplukt had:
PS/2 mouse protocol

Dat blijkt bij mij precies te kloppen; ik had er even een testprogrammaatje bij geschreven:

C:

#include <stdio.h> 
#include <unistd.h> 
#include <sys/types.h> 
#include <fcntl.h> 

int main() 
{
    unsigned char data[3], old_flags = 0;
    int x = 0, y = 0, dx, dy, b;

    int fd = open("/dev/input/mouse0", O_RDONLY);
    while(read(fd, data, 3) == 3)
    {
        printf("\nData: %02x%02x%02x\n", data[0], data[1], data[2]);

        /* Verplaatsing berekenen (9-bits 2-complements) */
        dx = data[1], dy = data[2];
        if((data[0] >> 4) & 1) dx = -((dx^255) + 1);
        if((data[0] >> 5) & 1) dy = -((dy^255) + 1);
        if(dx || dy)
        {
            x += dx, y += dy;
            printf("Moved to: %d %d\n", x, y);
        }

        /* Muisknoppen */
        for(b = 0; b < 3; ++b)
        {
            if(((data[0]^old_flags) >> b) & 1)
                printf( "Button %d %s\n", b + 1,
                        ((data[0] >> b) & 1) ? "pressed" : "released" );
        }
        old_flags = data[0];

        if(data[0] >> 6)
            printf("WARNING: overflow!\n");
    }

    return 0;
}

Nu lijkt het erop dat uit /dev/mice precies dezelfde data komt. Dat is dus niet handig als je twee mouse pointers wilt implementeren, maar niets weerhoudt je ervan om gewoon meerdere afzonderlijke devices te openen en met select() ze simultaan te verwerken.

[ Voor 35% gewijzigd door Soultaker op 13-10-2005 02:53 ]

[Arjan]

Ik heb je programma bestudeerd, gecompileerd, maar helaas krijg ik geen output.

dit is wat ik van je programma snap:

C:

#include <stdio.h> 
#include <unistd.h> 
#include <sys/types.h> 
#include <fcntl.h> 

int main() 
{
    unsigned char data[3], old_flags = 0;
    int x = 0, y = 0, dx, dy, b;

    int fd = open("/dev/input/mouse0", O_RDONLY); //muisdata inlezen
    while(read(fd, data, 3) == 3) //lees totdat alle 3 de waarden van de data[] vol staan ?
    {
        printf("\nData: %02x%02x%02x\n", data[0], data[1], data[2]); //ouput naar het scherm

        /* Verplaatsing berekenen (9-bits 2-complements) */
        dx = data[1], dy = data[2];
        if((data[0] >> 4) & 1) dx = -((dx^255) + 1); //que?
        if((data[0] >> 5) & 1) dy = -((dy^255) + 1); //que deel 2
        if(dx || dy) // als dx of dy ? ik neem dus aan dat dx/y 0 is zolang er niet bewogen is.
        {
            x += dx, y += dy;
            printf("Moved to: %d %d\n", x, y);
        }
//vanaf hier is het in principe niet interesant voor mijn doeleinden :)

        /* Muisknoppen */
        for(b = 0; b < 3; ++b)
        {
            if(((data[0]^old_flags) >> b) & 1)
                printf( "Button %d %s\n", b + 1,
                        ((data[0] >> b) & 1) ? "pressed" : "released" );
        }
        old_flags = data[0];

        if(data[0] >> 6)
            printf("WARNING: overflow!\n");
    }

    return 0;
}

[Soultaker]

Hmm, misschien gebruikt je muis een ander protocol. Wat bedoel je precies met geen uitvoer? Het programma start wel, maar print niets? Of start 't wel, maar sluit direct weer af? Of start 't wel en print het wel data, maar geen verplaatsingen?

Dat je er helemaal niets uit krijgt zou raar zijn als je 'met de hand' wel /dev/input/mouse0 kunt uitlezen. Uit je eerdere dump leek het ook dat de muis een ander protocol gebruikt, maar dan nog is het raar dat er helemaal niets zou gebeuren. Kun je eens 'hexdump /dev/input/mouse0' doen, een beetje rondbewegen, en wat uitvoer posten? (Dat zou overeen moeten komen met je eerdere hexdump die je via-via had gemaakt.)

Wat de code betreft: op regel 12 lees ik gewoon 3 bytes uit (de lus wordt onderbroken als ik om een of andere reden niet kan lezen). In regel 18 en 19 reconstrueer ik de horizontale en verticale verplaatsing, die is gegeven als 9-bits 2-complements integers. Voor de horizontale verplaatsing zitten de eerste 8 bits in data[1] en is de negende bit (het teken) de 5e bit van data[0], zoals ook uitgelegd stond in het document waar ik naar verwees. Maar dat is nog niet belangrijk als je helemaal geen uitvoer krijgt.

[Arjan]

Ik weet al waar het fout ging en het was natuurlijk mijn eigen domme fout
Om /dev/* te lezen heb je admin rechten nodig en ik zat met user rechten te testen...

Je code werkt perfect, het is precies wat ik zoek

Ik ga proberen een beter inzicht te krijgen in je code en zal mijn vorderingen hier postten!

alvast hartelijk bedankt voor de steun zover!

[Arjan]

ok, ik heb wat zitten knoeien, maar C is toch wel wat anders dan C++.
Ik denk dat ik later maar ga proberen de code om te zetten naar C++. Voor nu vraag ik me af waarom het volgende niet werkte.

C:

#include <stdio.h> 
#include <unistd.h> 
#include <sys/types.h> 
#include <fcntl.h> 

int main()
{
    unsigned char data[3], old_flags = 0;

    int x = 0, y = 0, dx, dy;

    int fd = open("/dev/input/mouse0", O_RDONLY);

    int bestand = fopen("/home/arjan/output.txt", "w");

    while(read(fd, data, 3) == 3)
    {

//      Verplaatsing berekenen (9-bits 2-complements)
            dx = data[1], dy = data[2];
            
        if((data[0] >> 4) & 1) dx = -((dx^255) + 1);
            if((data[0] >> 5) & 1) dy = -((dy^255) + 1);
//          

        if(dx || dy)
            {
            x += dx, y += dy;
            printf(bestand, "Moved to: %d %d\n", x, y);
        }

            old_flags = data[0];

        if(data[0] >> 6)
        {
            printf("WARNING: overflow!\n");
        }
    }

    fclose(bestand);

    return 0;
}

het resultaat was dat het bestand wel bewerkt werd, maar gewoon leeg bleef. Ook als ik bijvoorbeeld

C:

printf(bestand, "dode hond");

deed

[Soultaker]

Toch interessant om te zien hoe je met zo weinig wijzigingen zoveel verschillende fouten weet te introduceren. Zet om te beginnen eens alle warnings aan; dat doe ik ook terwijl ik mezelf toch een gevorderd C-programmeur vind.

Met warnings aan had je al kunnen zien dat alle fxxx-functies (fopen, fread, fwrite, fprintf, fclose, enzovoorts) met een FILE* werken en niet met een int (wat alleen een file descriptor is).

Verder schrijft printf altijd naar standard output (het eerste argument is een format string en dan de rest van de argumenten); als je naar een bestand wil schrijven moet je fprintf gebruiken (die accepteert als eerste argument een FILE*, dan een format string, en dan de argumenten).

Tenslotte is het verschil tussen I/O op OS-nivo (met open/close/read/write) en die van de standard C library (fopen/fclose/fread/fwrite) dat de C library data buffert. Als je naar een console schrijft dan is de uitvoer normaliter line buffered maar als je naar een bestand schrijft (of eigenlijk alles wat geen console is) dan buffert 'ie een vast aantal bytes. Waarschijnlijk heb jij maar heel kort getest en druk je daarna op Control-C waardoor nog niets uit de buffer weggeschreven is (en dan kom je ook nooit bij de fclose uit, die de buffer zou wegschrijven).

Ik kan drie manieren bedenken om dat op te lossen, waarvan twee platformafhankelijk. Je kunt de uitvoer line buffered maken, zodat elke regel naar het bestand wordt geschreven. Je kunt een interrupt handler maken zodat het bestand netjes afgesloten wordt als je op Control-C drukt. En tenslotte (en wat het makkelijkst is) kun je de uitvoer flushen nadat je een regel hebt weggeschreven, met een aanroep van fflush na regel 29.

Maar ik vermoed dat het schrijven naar het bestand maar een tussenstation voor je was en niet het uiteindelijke doel, dus je moet maar zien hoe je het op wil lossen. (Merk op dat twee van de drie problemen al gesignaleerd waren door de compiler als je naar de compiler warnings gekeken had.)

In C++ werkt het trouwens op dezelfde manier:

C++:

#include <fstream>

int main()
{
    std::ifstream mouse("/dev/input/mouse0");
    std::ofstream output("output.txt");

    unsigned char data[3];
    int x = 0, y = 0;
    while(mouse.read((char*)data, 3))
    {
        int dx = data[1], dy = data[2];
        if((data[0] >> 4) & 1) dx = -((dx^255) + 1);
        if((data[0] >> 5) & 1) dy = -((dy^255) + 1);

        if(dx || dy)
        {
            x += dx, y += dy;
            output << "Moved to: " << x << ", " << y << std::endl;
        }
    }
}

Merk op dat std::endl automatisch flusht (dat is het verschil met gewoon '\n' wegschrijven).

edit:
Ik begin me ook af te vragen wat dit in NOS doet i.p.v. in P&W.

[ Voor 24% gewijzigd door Soultaker op 14-10-2005 16:42 ]

[Arjan]

Dat C++ ziet er al wat bekender uit

Ik heb wat met de code zitten spelen, maar ik loop continue vast op de while loop.
Misschien dat iemand kan proberen mij wat inzicht te geven in wat er daar gebeurd?

C++:

while(mouse.read((char*)data, 3))

De gelezen waarde wordt in data gestopt, maar precies met welke eigenschappen?

[ Voor 16% gewijzigd door Arjan op 14-10-2005 23:30 ]

[Verwijderd]

Volgens mij leest hij daar 3 chars uit mouse.

Kennelijk bestaat 1 beweging uit 3 chars, wat ik ook opmaak uit je eerder hier geposte output:

code:

^@
^Xý
^@
^Xþ
^@
^Xþ
^@

waarom geen move ->pw?

[ Voor 52% gewijzigd door Verwijderd op 14-10-2005 23:14 ]

[Arjan]

Ah, ik ben er al uit, ik heb een move aangevraagd, maar het lijkt erop dat ik er nu uitkom.
Ik ben wel nog nieuwsgierig naar wat (char*) nu precies betekend, want dat is me nog niet helemaal duidelijk.

[Soultaker]

Die (char*) in het eerste argument van read() is een cast; een cast converteert het ene type naar het andere. ((double)10) cast de 10 (een integer) naar een double. Met read() kun je een aantal karakters in een buffer lezen van het type (char*), maar het type van buffer is unsigned char * (eigenlijk is het zelfs unsigned char[3], als je technisch wil worden, maar dat degenereert naar unsigned char*). Aangezien unsigned char* en char* geen compatible types zijn, cast ik naar char* (aangezien ik als programmeur weet dat onder Linux char en unsigned char even groot zijn).

Het tweede argument van read is het aantal bytes, maar dat is ook in de documentatie op te zoeken. Elke update in PS/2 streamining mode bestaat uit 3 bytes (volgens die pagina waaraan ik eerder refereerde) dus ik lees gewoon steeds 3 bytes.

[ Voor 19% gewijzigd door Soultaker op 15-10-2005 03:26 ]

[Arjan]

Ik ben weer druk in de weer geweest, hier is het resultaat.
In principe doet het wel wat, alleen krijg ik ontzettend veel overflows ed. dat kan niet de bedoeling zijn.

C++:

#include <fstream>
#include <iostream>

using namespace std;

int main()
{
    ifstream muis("/dev/input/mouse0");
//  ifstream muis("/dev/input/mouse1");

    unsigned char data[3];
    int x = 0, y = 0;

    while(muis.good())
    {
        muis.get((char*)data, 3);
        int dx = data[1], dy = data[2];

////////////////////////////////////////////////////////////////////// debug
        cout << endl;
        for (int i=7; i>=0; i--)
        {
            cout << i;
        }
        cout << " byte#" << endl;
        for (int i=0; i<3; i++)
        {
            for (int t=7; t>=0; t--)
            {
                cout << ((data[i] >> t) & 1);
            }
            if(i==0) cout << endl;
            if(i==1) cout << " horizontaal - " << dx << endl;
            if(i==2) cout << " verticaal   - " << dy << endl;
        }
////////////////////////////////////////////////////////////////////// debug

        if((data[0] >> 6) & 1)
        {
            cout << "^ overflow ^" << endl;
            muis.clear();
        }
        else
        {
            if((data[0] >> 4) & 1) dx = -((dx^255) + 1);
            if((data[0] >> 5) & 1) dy = -((dy^255) + 1);
    
            if(dx || dy)
            {
                x += dx, y += dy;
//              ofstream waardes("/home/arjan/Desktop/output.txt");
//              waardes << "X=" << x << "\nY=" << y << endl;
//              cout << "dx=" << dx << "\ndy=" << dy << endl;
//              waardes.close();
            }
        }
    }

    return muis.good();
}

dat levert het volgende op als ik een beetje ga rondfietsen met de muis:

code:

76543210 byte#
11111001
00101000 horizontaal - 40
00000000 verticaal - 0
^ overflow ^

76543210 byte#
00000000
11111010 horizontaal - 250
00000000 verticaal - 0

76543210 byte#
00101000
00000000 horizontaal - 0
00000000 verticaal - 0

76543210 byte#
11111101
00001000 horizontaal - 8
00000000 verticaal - 0
^ overflow ^

76543210 byte#
00000000
00000010 horizontaal - 2
00000000 verticaal - 0

76543210 byte#
00001000
00000000 horizontaal - 0
00000000 verticaal - 0

76543210 byte#
00000100
00001000 horizontaal - 8
00000000 verticaal - 0

76543210 byte#
00000000
00000100 horizontaal - 4
00000000 verticaal - 0

76543210 byte#
00001000
00000000 horizontaal - 0
00000000 verticaal - 0

76543210 byte#
00000111
00001000 horizontaal - 8
00000000 verticaal - 0

76543210 byte#
00000000
00000111 horizontaal - 7
00000000 verticaal - 0

76543210 byte#
00001000
00000000 horizontaal - 0
00000000 verticaal - 0

76543210 byte#
00001000
00001000 horizontaal - 8
00000000 verticaal - 0

76543210 byte#
00000000
00001001 horizontaal - 9
00000000 verticaal - 0

76543210 byte#
00001000
00000000 horizontaal - 0
00000000 verticaal - 0

76543210 byte#
00000000
00000000 horizontaal - 0
00000000 verticaal - 0

Het lijkt wel alsof de timing niet klopt, alsof de bytes niet op de juiste plaats ingelezen worden. Misschien dat dit komt doordat de code voor het opvragen niet meer direct in de while loop staat. Dit heb ik gedaan omdat ik steeds geen output kreeg zolang deze code daarin stond.

Echter, zoals jullie zien werkt dit ook niet, wat doe ik verkeerd?

[Soultaker]

Atgast schreef op zaterdag 15 oktober 2005 @ 17:20:

C++:

        muis.get((char*)data, 3);

Waarom bedacht je dat je beter get kon gebruiken dan read? get is bedoeld voor het lezen van tekst, geen binaire data en het gaat hier om twee redenen fout: ten eerste stopt get met lezen als 'ie een delimiter ('\n' standaard) tegenkomt en dat wil je niet en ten tweede leest get een zero terminated string in. Als je dus als buffergrootte 3 ingeeft, dan leest 'ie maximaal 2 chars in en voegt dan een '\0' toe. Dan klopt er natuurlijk niets meer van je data, omdat je de data dan per twee bytes inleest (in plaats van per drie bytes). read daarintegen heeft al deze problemen niet (daarom gebruikte ik ook al read) en leest gewoon 3 bytes in de buffer en verder niets.

Dit soort dingen moet je trouwens zelf ook kunnen debuggen en een beetje kritisch de C++ documentatie doorlezen kan ook geen kwaad. In een geval als dit kun je een dump van wat muisdata maken naar een bestand en dat gebruiken, zodat je elke keer met dezelfde invoer werkt. Dan kun je in een hex editor bekijken welke data je hoort in te lezen en dat vergelijken met wat je daadwerkelijk inleest; lijkt me dat het patroon dan snel genoeg op zou moeten vallen.

[ Voor 8% gewijzigd door Soultaker op 15-10-2005 17:43 ]

[Arjan]

Kijk, nu is het duidelijk. In mijn boek kon ik nergens read() vinden, en als je googled op "C++ read()" dan trekt google tigduizend hits uit de kast die het hebben over dingen als "...read more on this subject"
Omdat ik van get() wel documentatie kon vinden besloot ik die te gebruiken, denkende dat ik dan meer begrip zou hebben over waar ik mee bezig was

hartelijk dank voor je hulp!

[Soultaker]

Twee websites die ik heel veel gebruik voor C++, zijn:
• De STL reference van SGI: http://www.sgi.com/tech/stl/table_of_contents.html
• De iostream (en standard C) reference van cplusplus.com: http://www.cplusplus.com/ref/
Die twee coveren zo'n beetje de hele standard library. Verder is er natuurlijk met Google van alles te vinden; als ik simpelweg Google op "ifstream" staat die pagina van cplusplus.com al bovenaan bijvoorbeeld.

[Arjan]

Ik moet het topic toch nog een keer kicken, op de een of andere manier draait alles, zoals gewoonlijk, op het laatste moment in de soep. Ik ben niet in staat op een van de codes die op deze pagina staan werkend te krijgen. Ik snap er absoluut geen kont van, maar dat is de situatie. Het maakt niet uit of ik root ben of niet, een mouse-dump inlaad of /dev/input/mouse0 zelf, het werkt gewoon niet

hexdump /dev/input/mouse0 werkt daarentegen prima en alle code die ik tik doet het ook. Het lijkt wel of alleen de read functie niet meer werkend te krijgen is...

De files staan hier je moet toestemming hebben om /dev/input/mouse0 te hebben lezen. Het output gedeelte heb ik tijdelijk eruit gequote.

Heeft iemand enig idee waarom dezelfde code op een vergelijkbare computer niet werkt???

edit:
hmm, lag waarschijnlijk aan m'n compiler, met gcc 4nogwat doet ie t wel, woohoo

[ Voor 7% gewijzigd door Arjan op 26-10-2005 18:00 ]