Licht

From CCCHHWiki
(Difference between revisions)
Jump to: navigation, search
(wip)
 
(wip: DMX-Treiber)
Line 10: Line 10:
  
 
=== Hypervisor-Config ===
 
=== Hypervisor-Config ===
Da der bei uns in einer VM (mit dem Namen <code>licht</lich>) hängt ist noch einiges nötig.
+
Da der bei uns in einer VM (mit dem Namen <code>licht</code>) hängt ist noch einiges nötig.
Auf dem Hypervisor das <code>ftdi_sio</code>-Modul blacklisten:
+
Auf dem Hypervisor (Debian/systemd/GNU/Linux) das <code>ftdi_sio</code>-Modul blacklisten:
 
  <nowiki>
 
  <nowiki>
 
  root@red.bikeshed.hamburg.ccc.de:~# cat /etc/modprobe.d/blacklist.conf  
 
  root@red.bikeshed.hamburg.ccc.de:~# cat /etc/modprobe.d/blacklist.conf  
Line 24: Line 24:
 
       </source>
 
       </source>
 
     </hostdev></nowiki>
 
     </hostdev></nowiki>
Man beachte das <code>startupPolicy</code>. Das ist ein USB-Gerät, das könnten Leute abziehen, und wir wollen trotzdem, dass die VM dann startet. Genau aus dem Grund müssen wir auch noch mehr tun. Obigen XML-Code in eine Datei tun, z.B. <code>/root/dmxcontroller.xml</conf>. Dann legen wir eine udev-Regeln an, dass beim anstöpseln des Gerätes das auch direkt an die VM geht:
+
Man beachte das <code>startupPolicy</code>. Das ist ein USB-Gerät, das könnten Leute abziehen, und wir wollen trotzdem, dass die VM dann startet. Genau aus dem Grund müssen wir auch noch mehr tun. Obigen XML-Code in eine Datei tun, z.B. <code>/root/dmxcontroller.xml</code>. Dann legen wir eine udev-Regeln an, dass beim anstöpseln des Gerätes das auch direkt an die VM geht:
 
  <nowiki>
 
  <nowiki>
 
  # /etc/udev/rules.d/90-libvirt-usb.rules
 
  # /etc/udev/rules.d/90-libvirt-usb.rules
Line 39: Line 39:
 
Lustig, nech? Bitte bitte Bescheid sagen, falls ich da ne Funktion in libvirt übersehen hab.  
 
Lustig, nech? Bitte bitte Bescheid sagen, falls ich da ne Funktion in libvirt übersehen hab.  
  
=== Rechner-Config ===
+
=== Treiber-Config ===
 +
So, endlich haben wir das Device am Gerät. Wir erinnern uns, USB-Vendor 0x0403 und Device-ID 0x6001. Jetzt wollen wir es auch schön ansteuern. Dazu muss man dem FTDI beibringen, auch ordentliches DMX rauszupipen, das einfach aus einer Folge Bits besteht und keine doofen Start/Stopbits und so hat. Das macht der normale ftdi-Treiber im Linux Kernel nicht, also rauswerfen:
 +
<nowiki>
 +
root@licht.z9:~# cat /etc/modprobe.d/dmx_usb.conf
 +
blacklist ftdi_sio</nowiki>
 +
Außerdem muss man darauf achten, dass <code>brltty</code> nicht dazwischenfunkt, also deinstallieren.
 +
<nowiki>
 +
root@licht.z9:~# apt-get remote brltty</nowiki>
 +
 
 +
Jetzt müssen wir ein neues Kernelmodul installieren. Dazu brauchen wir die Kernel-Header und nen Compiler und so. Das sei dem Leser überlassen.
 +
Yay. Angeblich ist das nur für 2.6, klappt mit 3.16 aber auch noch. Wir sind gerade auf Commit ee99ca7edbd9e093480ad63341ac007394047bde.
 +
<nowiki>
 +
# git clone https://github.com/lowlander/dmx_usb_module.git
 +
# cd dmx_usb_module
 +
# make
 +
# cp dmx_usb.ko /lib/modules/`uname -r`/kernel/drivers/usb/serial/
 +
# systemctl reboot # Ist ja ne VM, geht fix ;)</nowiki>
 +
 
 +
Wenn alles geklappt hat müsste es jetzt ein Device <code>/dev/dmx0</code> geben. Weil wir ja mit minimalen Berechtigungen arbeiten und nix als root laufen lassen wollen müssen wir noch ne udev-Regel schreiben.
 +
<nowiki>
 +
# /etc/udev/rules.d/65-dmxinput.rules
 +
KERNEL=="dmx[0-9]*", GROUP="licht"
 +
ACTION=="add", \
 +
    SUBSYSTEM=="usb", \
 +
    ENV{ID_VENDOR_ID}=="0403", \
 +
    ENV{ID_MODEL_ID}=="6001"
 +
ACTION=="remove", \
 +
    SUBSYSTEM=="usb", \
 +
    ENV{ID_VENDOR_ID}=="0403", \
 +
    ENV{ID_MODEL_ID}=="6001"</nowiki>
 +
Also, vorausgesetzt, unser DMX-Progrämmchen läuft in der Gruppe <code>licht</code>. Wer Lust hat kann hier noch nen Symlink anlegen, damit wir auch immer das gleiche Device an derselben Stelle haben.
 +
 
 +
=== Software ===

Revision as of 17:02, 31 August 2016

Contents

Hardware

Da sind ein paar Licht-Dinge an der Decke. Die werden über DMX-512 angesprochen.

  • Leiste Tafel/Fenster
  • Leiste Tafel/Tür

Ansteuerung

Es hängt ein ENTTEC Open DMX USB-Gerät rum und bespielt den DMX-Bus. ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC. Ist also im Prinzip ein normaler FTDI USB-Seriell-Wandler.

Hypervisor-Config

Da der bei uns in einer VM (mit dem Namen licht) hängt ist noch einiges nötig. Auf dem Hypervisor (Debian/systemd/GNU/Linux) das ftdi_sio-Modul blacklisten:

 root@red.bikeshed.hamburg.ccc.de:~# cat /etc/modprobe.d/blacklist.conf 
 blacklist ftdi_sio

Device der VM mitgeben:

    <hostdev mode='subsystem' type='usb' managed='no'>
      <source startupPolicy='optional'>
        <vendor id='0x0403'/>
        <product id='0x6001'/>
      </source>
    </hostdev>

Man beachte das startupPolicy. Das ist ein USB-Gerät, das könnten Leute abziehen, und wir wollen trotzdem, dass die VM dann startet. Genau aus dem Grund müssen wir auch noch mehr tun. Obigen XML-Code in eine Datei tun, z.B. /root/dmxcontroller.xml. Dann legen wir eine udev-Regeln an, dass beim anstöpseln des Gerätes das auch direkt an die VM geht:

 # /etc/udev/rules.d/90-libvirt-usb.rules
 ACTION=="add", \
    SUBSYSTEM=="usb", \
    ENV{ID_VENDOR_ID}=="0403", \
    ENV{ID_MODEL_ID}=="6001", \
    RUN+="/usr/bin/virsh attach-device licht /root/dmxcontroller.xml"
 ACTION=="remove", \
    SUBSYSTEM=="usb", \
    ENV{ID_VENDOR_ID}=="0403", \
    ENV{ID_MODEL_ID}=="6001", \
    RUN+="/usr/bin/virsh detach-device licht /root/dmxcontroller.xml"

Lustig, nech? Bitte bitte Bescheid sagen, falls ich da ne Funktion in libvirt übersehen hab.

Treiber-Config

So, endlich haben wir das Device am Gerät. Wir erinnern uns, USB-Vendor 0x0403 und Device-ID 0x6001. Jetzt wollen wir es auch schön ansteuern. Dazu muss man dem FTDI beibringen, auch ordentliches DMX rauszupipen, das einfach aus einer Folge Bits besteht und keine doofen Start/Stopbits und so hat. Das macht der normale ftdi-Treiber im Linux Kernel nicht, also rauswerfen:

 root@licht.z9:~# cat /etc/modprobe.d/dmx_usb.conf 
 blacklist ftdi_sio

Außerdem muss man darauf achten, dass brltty nicht dazwischenfunkt, also deinstallieren.

 root@licht.z9:~# apt-get remote brltty

Jetzt müssen wir ein neues Kernelmodul installieren. Dazu brauchen wir die Kernel-Header und nen Compiler und so. Das sei dem Leser überlassen. Yay. Angeblich ist das nur für 2.6, klappt mit 3.16 aber auch noch. Wir sind gerade auf Commit ee99ca7edbd9e093480ad63341ac007394047bde.

 # git clone https://github.com/lowlander/dmx_usb_module.git 
 # cd dmx_usb_module
 # make
 # cp dmx_usb.ko /lib/modules/`uname -r`/kernel/drivers/usb/serial/
 # systemctl reboot # Ist ja ne VM, geht fix ;)

Wenn alles geklappt hat müsste es jetzt ein Device /dev/dmx0 geben. Weil wir ja mit minimalen Berechtigungen arbeiten und nix als root laufen lassen wollen müssen wir noch ne udev-Regel schreiben.

 # /etc/udev/rules.d/65-dmxinput.rules 
 KERNEL=="dmx[0-9]*", GROUP="licht"
 ACTION=="add", \
    SUBSYSTEM=="usb", \
    ENV{ID_VENDOR_ID}=="0403", \
    ENV{ID_MODEL_ID}=="6001"
 ACTION=="remove", \
    SUBSYSTEM=="usb", \
    ENV{ID_VENDOR_ID}=="0403", \
    ENV{ID_MODEL_ID}=="6001"

Also, vorausgesetzt, unser DMX-Progrämmchen läuft in der Gruppe licht. Wer Lust hat kann hier noch nen Symlink anlegen, damit wir auch immer das gleiche Device an derselben Stelle haben.

Software

Personal tools
Namespaces

Variants
Actions
Navigation
Language
Tools