The librxtxSerial.so in the repo is 32 bit only

[13rac1]

librxtxSerial.so included in the repo at: pixelcontroller-distribution/src/main/resources/lib is the 32bit version. This causes the following error on startup:

OpenJDK 64-Bit Server VM warning: You have loaded library /home/user/development/PixelController/pixelcontroller-distribution/target/assembly/pixelcontroller-distribution-2.1.0-RC2/lib/librxtxSerial.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
java.lang.UnsatisfiedLinkError: no rxtxSerial64 in java.library.path thrown while loading gnu.io.RXTXCommDriver
Exception in thread "PixelController Core" java.lang.NoClassDefFoundError: Could not initialize class gnu.io.RXTXVersion
    at gnu.io.CommPortIdentifier.<clinit>(CommPortIdentifier.java:123)
    at com.neophob.sematrix.core.output.transport.serial.SerialP5.list(SerialP5.java:597)
    at com.neophob.sematrix.core.output.transport.serial.SerialImpl.getSerialPortName(SerialImpl.java:109)
    at com.neophob.sematrix.core.output.Tpm2.<init>(Tpm2.java:66)
    at com.neophob.sematrix.core.output.PixelControllerOutput.getOutputDevice(PixelControllerOutput.java:114)
    at com.neophob.sematrix.core.api.impl.PixelControllerServerImpl.run(PixelControllerServerImpl.java:161)
    at java.lang.Thread.run(Thread.java:745)

My system, LinuxMint 17 (and therefore Ubuntu/Debian), already has the correct librxtxSerial.so because the package librxtx-java is required by the Arduino IDE. The file is available at: /usr/lib/jni/librxtxSerial.so.

If I change pixConServer/PixelController.sh and PixelController.properties to include this standard library location PixelController starts up fine.

-Djava.library.path=/usr/lib/jni:./lib

Should I make a pull request making this change or do you prefer a different way to correct the problem? The install procedure would need to be documented also.

Thanks!

[13rac1]

Seems like the file is in the same location on Fedora: http://stackoverflow.com/questions/10751304/java-lang-unsatisfiedlinkerror-no-rxtxserial-in-java-library-path-thrown-while

[neophob]

The vanilla rxtx library suffers from bad latency, there is an event loop that's called each 25ms. this is of course kinda bad if you want to send alot of data, (see http://neophob.com/2011/05/serial-library-rxtx-v2-2pre5/). I include already rpi arm releases of the library, maybe adding a generic 64b linux would be the simplest solution.

[13rac1]

I read your blog posts on the subject while trying to get this to work in originally, it helped me understand something was wrong.

Would it be possible to fix this issue upstream? Huh.. rxtx.qbang.org doesn't exist anymore (but is available on archive.org), so I'm not sure where "upstream" is.

The usleep(20000) call still exists in the current debian upstream here: http://anonscm.debian.org/cgit/pkg-java/rxtx.git/tree/src/SerialImp.c?id=a4cd13e04254cea7842df2e30e9d12e9765a3ef9#n4074 Can you file a bug report about the issue? https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=rxtx or https://bugs.launchpad.net/ubuntu/+source/rxtx or https://launchpad.net/rxtx or ?

Temporarily could your fork go in: https://github.com/neophob/rxtx ?

Update: http://rxtx.qbang.org/wiki/index.php/Main_Page exists again.

[GHPS]

A few years ago I built a LED matrix and I really liked to control it with PixelController under Win XP 32 bit. After moving to Kubuntu (64 Bit) I expected to get PixelController up and running in a short time again since it is open source.

This, however, proved to be an unsolvable quest: I've spend hours of testing, patching numerous files and testing again. In the end nothing worked for me. PixelController remains unusable on my 64 bit system.

So my question is: Has anyone managed to get the program working on a 64 bit OS or is PixelController a dead project since 64 bit is today's standard architecture?

[neophob]

the source is available here: https://github.com/neophob/librxtx however I don't active work on this project anymore

[GHPS]

the source is available here:

Thanks for the info.

How good are the chances that this version will work with a modern 64 bit linux? As I can see the latest commit is six years old and had to do with 64 bit issues.

[GHPS]

After spending some more time I've found a solution - two to be precise... PixelController now works flawlessly under (K)Ubuntu 18.04 64 bit.

1. After all attempts to update/patch the RXTX library failed I resorted to a different approach: Use PixelController's TPM.NET network interface and route the network packages to the serial port using a small Python program. This worked immediately and without any problems. And with this approach even Glediator, a different LED controller, comes alive again. So if nothing helps with PixelController or Glediator this Python glue logic comes in handy:

import serial
import socket
import time

vSocket=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
tServerAddress=('localhost',65506)
vSocket.bind(tServerAddress)
vSerial=serial.Serial('/dev/ttyACM0',baudrate=500000,bytesize=serial.EIGHTBITS,parity=serial.PARITY_NONE,stopbits=1)
while True:
    byData, _ = vSocket.recvfrom(1024)
    vSerial.write(byData)
    time.sleep(0.02)

Remember to change the settings of PixelController (data/config.properties) from serial TPM to TPM.net.

2. With the good results from the Python script I again twiddled with the Java side of the issue.

The central problem is twofold: a) Loading the correct 64 bit rxtxt library and b) Getting the com port to be opened.

at a) After enabling logging in the child process (app.follow=true) and resorting to Java version 8 (java8) (necessary since [1]) both parts become apparent.

java8 -verbose -jar PixelController.jar

OpenJDK 64-Bit Server VM warning: You have loaded library /MatrixDisplay/PixelController/source-git/pixelcontroller-distribution/target/assembly/pixelcontroller-distribution-2.1.0-RC1/lib/librxtxSerial.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
java.lang.UnsatisfiedLinkError: no rxtxSerial64 in java.library.path thrown while loading gnu.io.RXTXCommDriver

I previously tested all versions of the rxtx library I could get hold of. This accomplished nothing. The mentioned neophob-librxtx doesn't have any binaries available in the repo since they are now part of mainstream debian - which don't work either.

As 13rac1 pointed out the solution (the only one that worked for me) was to take the 64 bit rxtx-library file from a former Arduino distribution (archived version 1.0.6). Current Arduino versions don't contain this file any more.

Copy the file from the Arduino's lib directory to PixelController's lib directory: cp /home/download/Arduino/arduino-1.0.6/lib/librxtxSerial64.so lib

at b) Great - PixelController has the correct 64 bit library available and loads it without further modification.

But now PixelController has a hard time opening the com port that was specified in the settings file (data/config.properties):

WARNING:  RXTX Version mismatch
        Jar version = RXTX-2.2 http://PixelInvaders.ch low latency edition
        native lib Version = RXTX-2.1-7
Feb 22, 2019 10:38:57 PM com.neophob.sematrix.core.output.transport.serial.SerialImpl getSerialPortName
SCHWERWIEGEND: Could not find configured serial name: /DEV/TTYACM0, try anyway...

This can be fixed by changing the app.vm.options in PixelController.properties. Point to the respective com port by adding the parameter -Dgnu.io.rxtx.SerialPorts=/dev/ttyACM0

Voila - problem fixed. PixelController starts without any problem.

Epilog: Since the 64 rxtx-libray is part of the Arduino IDE which is released under GPL I suggest including it in this repos. This would make it much easier for users to run PixelController on a 64 bit machine/OS.

1: https://github.com/neophob/PixelController/issues/102

[neophob]

note: i dont maintain this project anymore but happy to merge prs.