TuX as LLG logo
Driver Suite for Linux
csv2iif.pl suite
convert PayPal transactions to IIF, OFX, QIF
DMX30 Interface
128Ch SPP
DMX43 Interface
2out 2in EPP
LED Hardware
for Linux and Windows
EPROM Sampler
for 8 bits of sound
Linux drivers for MK3/4 PCI
PostgreSQL replication
C exception/signal handling lib
to various software
and small scripts
misc documents
to lighting stuff

Preview of dmx4linux v3

We collect some ideas for the big rewrite of dmx4linux on this page. Please tell Dirk Jagdmann <doj@cubic.org> about your ideas.

The 3.x versions of dmx4linux will run only on linux >= 2.6 kernels and thus can use features present in the new kernels.


Redo the complete backend of the drivers. Dump all family/property system into trash. The backend needs to deal solely with mapping multiple dmx interface drivers into a single universe and multiplex the user code fops onto the drivers fops.

Decide which device semantics the output and input drivers should have. The output drivers can be used as a block device, thus allowing random access to an internal buffer. For input drivers we could use a character device, which just emits a stream of received/altered channels.

An interface drivers registers itself to the backend with a single call to int dmx_driver_reg(char *name, int pos, dmx_fops_t read_func, dmx_fops_t write_func) which has to be called for every universe of 512 slots the driver wishes to register. The desired position in the dmx4linux master universe is indicated by pos. The obtained position is returned. read_func or write_func can be NULL.

typedef int (*dmx_fops_t)(dmx_t *buf, int start, int len) the function signature used by the backend to communicate with the driver.

Each driver has a module parameter which indicates the desired universe number (for all kernel based drivers). If the desired number is already in use the next available is choosen by the driver backend. This allows the user to configure different interface types consistently regardless of module initialisation/load order.


Each hardware driver just uses /dev/dmx[0..255] and /dev/dmxin[0..255] for each universe. The universes are not combined into a single big universe in the driver level. You can use ioctl on each dev to get/set hardware information.


How to deal with IRQs and usb poll threads? How to do RDM?

User space

Remove all /proc stuff and use the new /sys instead.


All existing ioctls are removed. They are not needed. The following new calls are added.

returns the major version of the driver. All ioctl calls for a certain major should be compatible
returns the minor version of the driver.
returns the size of all universes.
sets the startcode for (all) output universes.
gets the startcode last received.

User lib

User applications should use our provided dmx4linux lib. This lib will provide a generic API to different kinds of interfaces. This will allow us to create drivers for rs232 and network interfaces with user code, which is included in the user lib. usb, firewire, parport, pci, isa interfaces are accessed with the kernel drivers. A configuration file in /etc will configure which interfaces to map to which universes.

Functions provided by lib:

int DMXinit();
dmx_t DMXget(int slot);
int DMXfd();
int DMXgetn(dmx_t *buf, int start, int len);
int DMXset(int slot, dmx_t val);
int DMXsetn(dmx_t *buf, int start, int len);


How to handle RDM?

Configuration file

The configuration file (presumably /etc/dmx4linux) will set certain aspects of the dmx4linux drivers. Most important the device order of interfaces can be customised with a section like:


http://llg.cubic.org/dmx4linux © 2001-2017 by Dirk Jagdmann and Michael Stickel