153 replies to this topic

[VU+NL]

Looks promising

Absolutely! There is another thread about this (AtmoLight, I think it's in the German part), also promising good results. Looks fabulous!

Today my AtmoLight package arrived (ordered via the "inventor"), and I must say: I am impressed!
Only drawback is that the plugin does not run properly on PLi 2.0, so I (hopefully temporarily) changed to VTi, where it runs smooth and without any problem.


Any chance for help to get it running under PLi? Relevant part of Kernel log is attached.

Attached Files

•  atmolight unter pli 2_1.0   3.34KB   0 downloads

[VU+NL]

I was informed by he plugin maker that Pli does not have "out of the box" support for UDEV and FTDI-SIO. He adviced me to install the FDT-SIO Support, after which the plugin should run nicely.

I tried that, but that went wrong:

opkg install kernel-module-ftdi-sio

Installing kernel-module-ftdi-sio (2.6.18-7.3-r7.3) to root...
Downloading http://downloads.pli-images.org/feeds/openpli-2.0/vuduo/vuduo/kernel-module-ftdi-sio_2.6.18-7.3-r7.3_vuduo.ipk.

Configuring kernel-module-ftdi-sio.

FATAL: Module ftdi_sio not found.

Any idea how to install that modul correctly?

[pieterg]

depmod runs too early. Just ingore the error and reboot.

[VU+NL]

I did, but the box never recovered from the reboot (no crash, but spinners forever).

[Meega]

I was informed by he plugin maker that Pli does not have "out of the box" support for UDEV and FTDI-SIO. He adviced me to install the FDT-SIO Support, after which the plugin should run nicely.

I tried that, but that went wrong:

opkg install kernel-module-ftdi-sio

Installing kernel-module-ftdi-sio (2.6.18-7.3-r7.3) to root...
Downloading http://downloads.pli-images.org/feeds/openpli-2.0/vuduo/vuduo/kernel-module-ftdi-sio_2.6.18-7.3-r7.3_vuduo.ipk.

Configuring kernel-module-ftdi-sio.

FATAL: Module ftdi_sio not found.

Any idea how to install that modul correctly?

Did you try it trough software management (bleubutton).
I just did on de DM8000 and it install's just fine.
Don't no yet what it does because my package is on it's way/images/smiley/pfft.gif
Hopefully tomorrow or the day after.

Meega

[VU+NL]

I will give it another try tomorrow.

In the meantime this forced itinerary was good for morale: experiencing once again how "crippled" other images are, makes one appreciate PLi's work even more /images/smiley/more_word_positive/8.gif

[VU+NL]

Back on PLi: I installed the "kernel-module-ftdi-sio" via advanced software management. This went without any problem. After a reboot the AtmoLight Plugin 0.4a was installed. This produced:

opkg install /var/tmp/imgmod.ipk; echo ">>> DONE <<<";

Installing enigma2-plugin-extensions-atmolightd (0.4a) to root...

Configuring enigma2-plugin-extensions-atmolightd.

Found VU+DUO with image younger than December 2010 (i.e. VTI 2.3).

**** Testing Atmolight ...

/usr/bin/atmodev.sh: 
line 50: can't create /etc/udev/rules.d/52-atmo.rules: nonexistent directory
Atmolight device (serial #23U2NAFF) found.
/etc/udev/rules.d/52-atmo.rules created.

ERROR: KERNEL-MODULE FTDI-SIO NOT INSTALLED OR NOT INCLUDED IN KERNEL.
Please install with 'ipkg install kernel-module-ftdi-sio'.


**** Testing amBX Light ...

Message: No amBX device found.

**** Testing Karatelight ...

Message: No Karatelight device found..

After a reboot, choosing "/dev/ttyUSB0" and changing the settings all went well: so now Atmolight runs nice & smooth under PLi 2.0

Again a happy man /images/smiley/more_word_greetings/1.gif

[Meega]

Whow, can't wait!!!


Meega

[VU+NL]

Whow, can't wait!!!

I recognize the feeling.


Sitting in front of the telly all day, just watching the backlight /images/smiley/more_word_other/5.gif

[Mamba0815]

Ist it possible to retrofit udev support in the PLI image after installation? It certainly would be an advantage to cover the sio-tty behind a universal device so that a reknodding the device won't leave the pluin in the dark. Other images such as iCVS, Gemini < 5.1, VTI, OoZoon do have udev support out of the box so there the atmolight plugin runs forever ... on the other side changes from /dev/ttyS0 to /dev/ttyS1 (..) happen very rarely.

Mamba

[pieterg]

we do not like the 10-15s delay udev gives during the trigger stage, that's the main reason why we use mdev.

[VU+NL]

Am I to expect some kind of trouble now that I have installed "kernel-module-ftdi-sio" ?

[pieterg]

no

[Mamba0815]

I am not yet familiar with mdev. Just read a little on the Internet. Right now I have a ton of other stuff to do, so I am not planning on using mdev in the very near future.

Mamba

[pieterg]

I don't think you need to do anything mdev specific.
What exactly do you need the custom udev rules for? To give a custom name to the devnode?

[Mamba0815]

Yes, correct. Here is rule that ALWAYS assigns the Karatelight Device (typically /dev/ttyACM0 ..or.. /dev/ttyACM1 or ...) to /dev/ttyUSBACM:

root@bm750:~# cat /etc/udev/rules.d/53-karate.rules
SUBSYSTEMS=="usb", KERNEL=="ttyACM*", ATTRS{serial}=="23af", SYMLINK+="ttyUSBACM"
root@bm750:~#

This way the daemon simply looks for the universal device /dev/ttyUSBACM and it works regardles of the number serial io-devices, because udev matches the serial number to the assign the universal device. It works the same way with Atmolight (/dev/ttyUSB0..1..2 to /dev/ttyUSBAtmo).

Mamba

[VU+NL]

@ Mamba0815:
any chance to get the plugin.py,in order to use the build-in screens for the Magic-HD skin?

[pieterg]

so the device uses acm? (ttyACM) I thought some users had to install ftdi-sio (ttyUSB)

a custom mdev entry could take care of this, only drawback is that mdev uses a single mdev.conf, which is distributed by us. So no seperate rule files as with udev, as far as I know.

ln -s /dev/ttyACM0 /dev/ttyACM

would also work of course.
Or a fallback in the daemon, from /dev/ttyACM to /dev/ttyACM0, if the first does not exist.

[VU+NL]

I thought some users had to install ftdi-sio (ttyUSB).

Yes, I did. The plugin itself told me so during the installation.

[Mamba0815]

No no ... Karatelight uses cdc-acm, Atmolight uses ftdi-sio. Our deamon supports both. Different hardware, different devices.

The kernel, at times, reknods the serial devices. Then the device /dev/ttyUSB0 disappears and reappears as /dev/ttyUSB1. If this happen, the deamon loses connection to the device, of course. Hence udev because it always links the specific device to one unique universal one. Our observation is that the reknodding appears maybe once a day on average. Daemon recognizes communication errors, waits 3 secs and the reopens the device successfully. Users practically don't recognize this. One could certainly build a device search function into the daemon, but we thought why reinventing the wheel?

Mamba