Difference between revisions of "Licht"

From CCCHHWiki
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 18:02, 31 August 2016

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