We've launched our new site at www.openlighting.org. This wiki will remain and be updated with more technical information.
Difference between revisions of "Drivers and software"
From wiki.openlighting.org
| Line 1: | Line 1: | ||
| − | There is a number of ways to get a controller application to send DMX data to a hardware interface (that can send the data out on your DMX wire). | + | ==Drivers and software== |
| + | ''This is some old general notes, that was kind of hidden in the wiki'' | ||
| + | |||
| + | There is a number of ways to get a controller application to send [[DMX]] data to a hardware interface (that can send the data out on your [[DMX]] wire). | ||
Sometime the driver is split up into: | Sometime the driver is split up into: | ||
| − | * Hardware driver for sending raw data to and from the hardware | + | * Hardware driver for sending raw data to and from the hardware. |
| − | * Protocol driver for translating the codes from the controller app to codes the hardware can understand (both ways) | + | * Protocol driver for translating the codes from the controller app to codes the hardware can understand (both ways). |
| − | + | Most USB interfaces works as a "virtual com port", which means that there is a real com port in the hardware, and a driver makes a com interface available i the operating system. Most USB com ports are supported 'out of the box' on both Windows and Linux (nice!), so most USB-to-DMX interfaces just need a protocol driver (easy to make and use) | |
| − | |||
| − | + | On Windows it seems that (almost) all controller apps have their own drivers. Probably because no good framework existed. | |
| + | On Linux there exists a system for hardware drivers, which is a kernel module with a common interface to the controller software that is independent of which hardware you choose to use. This is called [[DMX4Linux]]. | ||
| + | Many drivers don't need to be in the kernel, and for that, there is a driver framework called [LLA]]. | ||
| − | |||
| + | Remember that it is possible to send DMX data over a network to an other computer or an Ethernet-to-DMX hardware interface. [[LLA]] is particularly good at this and in routing the signals between different systems and hardware. | ||
| − | |||
| + | '''Adwise:''' If your are looking for a interface to buy, then start with finding your favorite controller app, and find out which drivers and thereby which hardware is supported. | ||
| − | + | [[Category:Articles]] | |
Revision as of 07:29, 13 November 2008
Drivers and software
This is some old general notes, that was kind of hidden in the wiki
There is a number of ways to get a controller application to send DMX data to a hardware interface (that can send the data out on your DMX wire).
Sometime the driver is split up into:
- Hardware driver for sending raw data to and from the hardware.
- Protocol driver for translating the codes from the controller app to codes the hardware can understand (both ways).
Most USB interfaces works as a "virtual com port", which means that there is a real com port in the hardware, and a driver makes a com interface available i the operating system. Most USB com ports are supported 'out of the box' on both Windows and Linux (nice!), so most USB-to-DMX interfaces just need a protocol driver (easy to make and use)
On Windows it seems that (almost) all controller apps have their own drivers. Probably because no good framework existed.
On Linux there exists a system for hardware drivers, which is a kernel module with a common interface to the controller software that is independent of which hardware you choose to use. This is called DMX4Linux. Many drivers don't need to be in the kernel, and for that, there is a driver framework called [LLA]].
Remember that it is possible to send DMX data over a network to an other computer or an Ethernet-to-DMX hardware interface. LLA is particularly good at this and in routing the signals between different systems and hardware.
Adwise: If your are looking for a interface to buy, then start with finding your favorite controller app, and find out which drivers and thereby which hardware is supported.
