TuX as LLG logo
Software
DMX4Linux
Driver Suite for Linux
csv2iif.pl suite
convert PayPal transactions to IIF, OFX, QIF
Hardware
DMX30 Interface
128Ch SPP
DMX43 Interface
2out 2in EPP
LED Hardware
for Linux and Windows
EPROM Sampler
for 8 bits of sound
Misc
CatWeasel
Linux drivers for MK3/4 PCI
pg_trompe
PostgreSQL replication
trycatch
C exception/signal handling lib
Patches
to various software
Tools
and small scripts
Docs
misc documents
Links
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.

Drivers

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.

or

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.

TODO

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.

IOCTL

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

DMX_IOCTL_GET_VERSION_MAJ
returns the major version of the driver. All ioctl calls for a certain major should be compatible
DMX_IOCTL_GET_VERSION_MIN
returns the minor version of the driver.
DMX_IOCTL_GET_SIZE
returns the size of all universes.
DMX_IOCTL_SET_STARTCODE
sets the startcode for (all) output universes.
DMX_IOCTL_GET_STARTCODE
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);

TODO

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:

[order]
kernel
rs232
network

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