evdev-java icon indicating copy to clipboard operation
evdev-java copied to clipboard

Invalid Argument exception

Open shahbaz-momi opened this issue 10 years ago • 5 comments

Hello, currently I have an N-Trig Multitouch panel hooked to the event file /dev/input/event4, and I am trying to use your library to access it. I have included all of the natives and such in the java.library.path but am getting this error even when superuser. The exception:

java.io.IOException: Invalid argument at sun.nio.ch.FileDispatcherImpl.read0(Native Method) at sun.nio.ch.FileDispatcherImpl.read(FileDispatcherImpl.java:46) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at sun.nio.ch.IOUtil.read(IOUtil.java:197) at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:149) at com.dgis.input.evdev.EventDevice.readEvent(EventDevice.java:269) at com.dgis.input.evdev.EventDevice.access$1(EventDevice.java:265) at com.dgis.input.evdev.EventDevice$1.run(EventDevice.java:200) EVENT: null Exception in thread "Thread-0" java.lang.NullPointerException at com.asdev.t3.Bootstrap$1.event(Bootstrap.java:41) at com.dgis.input.evdev.EventDevice.distributeEvent(EventDevice.java:256) at com.dgis.input.evdev.EventDevice.access$2(EventDevice.java:253) at com.dgis.input.evdev.EventDevice$1.run(EventDevice.java:201) Do you why this happens? Thanks

shahbaz-momi avatar Mar 31 '15 20:03 shahbaz-momi

Also, it seems to corrupt my filesystem a little bit which I then later have to fix by using fsck

shahbaz-momi avatar Mar 31 '15 23:03 shahbaz-momi

Hi, I tried to use this library on a Raspberry Pi and I got the same exception, but I figured out the source of the problem and managed to get it work. Basically, the problem is that this library is written for 64 bit CPU/OS only. Explanation:

The input_event structure looks like this (source):

struct input_event {
    struct timeval time;
    unsigned short type;
    unsigned short code;
    unsigned int value;
};

Here we have timeval, which has the following members (source):

time_t         tv_sec      seconds
suseconds_t    tv_usec     microseconds

These two types are represented differently on a 32 bit and a 64 bit system.

The solution:

  1. Change the size of input_event from 24 to 16 bytes:

    change line 34 of the source file evdev-java/src/com/dgis/input/evdev/InputEvent.java from this:

    public static final int STRUCT_SIZE_BYTES = 24;
    

    to this:

    public static final int STRUCT_SIZE_BYTES = 16;
    
  2. Change the parse function in the same source file as follows:

    public static InputEvent parse(ShortBuffer shortBuffer, String source) throws IOException {
        InputEvent e = new InputEvent();
        short a,b,c,d;
    
        a=shortBuffer.get();
        b=shortBuffer.get();
        //c=shortBuffer.get();
        //d=shortBuffer.get();
        e.time_sec = (b<<16) | a; //(d<<48) | (c<<32) | (b<<16) | a;
        a=shortBuffer.get();
        b=shortBuffer.get();
        //c=shortBuffer.get();
        //d=shortBuffer.get();
        e.time_usec = (b<<16) | a; //(d<<48) | (c<<32) | (b<<16) | a;
        e.type = shortBuffer.get();
        e.code = shortBuffer.get();
        c=shortBuffer.get();
        d=shortBuffer.get();
        e.value = (d<<16) | c;
        e.source = source;
    
        return e;
    }
    

I hope this will be useful also for other people.

LostParrot avatar Feb 07 '16 08:02 LostParrot

Hi, I have the same problem on a SECO SBC62, which has an armv7l 32-bit arch... But your solution doesn't work for me ! Do you have any hints for me to help me find a way to make it work ?

RomDep avatar Mar 16 '16 13:03 RomDep

Hi, maybe you should comment out everything in the above parse function, except the initialization of the variable e and the return e. If it gives no exception, then maybe you can debug it manually by checking the size and content of the shortBuffer argument in run-time, if that is possible in your set-up.

LostParrot avatar Mar 16 '16 14:03 LostParrot

Hi thanks for your help. Actually, it was a compilation and export to the board problem. Your solution was exactly what was required. A switch using System.getProperty("os.arch") could be a permanent fix of this issue.

RomDep avatar Mar 21 '16 09:03 RomDep