Free touchpad driver software for linux

uLan Driver provides 9-bit message oriented communication protocol, which is transferred over RS-485 link.
Characters are transferred same way as for RS-232 asynchronous transfer except parity bit, which is used to distinguish between data characters and protocol control information. A physical layer consists of one twisted pair of leads and RS-485 transceivers.
Use of 9-bit character simplifies transfer of binary data and for intelligent controllers can lower the CPU load, because of the CPU need not to care about data characters send to other node. Producers of most microcontrollers for embedded applications know that and have implemented 9-bit extension in UARTs of most of todays MCUs. There is the list below to mention some of them:
- all Intel 8051 and 8096 based MCUs with UART
- members of Motorola 683xx family ( 68332, 68376, ... )
- Hitachi H8 microcontrollers
The driver is implemented as relatively independent layers and subsystems. Messages are prepared and received in the driver dedicated memory. This memory is divided into blocks with uniform size with atomic allocation routines.
When message is being stored into blocks, head of message with couple of data bytes is stored in the first allocated memory block. If all data cannot be stored in the first block, next blocks are allocated and linked together.
The message heads are linked in bidirectional linked lists of messages prepared for sending, processed messages and messages prepared for client notification. These lists or queues are main mechanism for transferring of messages between subsystems.
Link protocol is programmed as finite state automata with state stack, which state routines are executed by interrupt handler. State routine can return positive integer information, negative error notification or zero, which leads to wait for next interrupt. Information or error is used as input parameter when state routine is called.
When the state routine wants initiate transfer to another state routine it changes pointer to the actual state routine. If previous state routine returns nonzero value new routine is called immediately, in other case next interrupt invokes new state routine.
There is stack of callers of actual state routines which enables to constructs automata subsystems, which can be used in more places in main automata loop. Main purpose of this automata is to send or process messages coming in list of messages prepared for sending and if specified, move these messages onto list of messages prepared for client notification.
Received messages are put onto this list too. Subsystem is supervised by timeout handler, which can revitalize communication in case of die of other node. The interrupt and timeout handlers are fully SMP reentrant.
The automata subsystem uses pointers to chip driver routines for hardware port manipulation. This is only part dependent on used chip, today 82510, 16450 and OX16C950PCI. These routines can send and receive 9 bit character, connect to RS-485 line by the arbitration sequence, wait for specified time for character and initialize and close port.
File operation subsystem makes interface between OS kernel VFS and client message queues. It enables to prepare single or multi-frame messages and stores notifications of received or processed messages in clients private state structures. This part is heavily operating system dependent.
Enhancements:
- This release enables you to build the driver within the WDF framework for Windows.
- Updates to support the latest Linux 2.6.x kernels are included (tested to 2.6.19).
- Changes to allow stand-alone system-less build for ARM targets (LPC21xx) are included.
- The OMK has been selected as the default build.
- The "switch2std" script allows you to switch to the old build system.

TAP provides packet reception and transmission for user-space programs. It can be viewed as a simple Ethernet device, which instead of receiving packets from a physical medium, receives them from a user-space program and instead of sending packets via physical media, writes them to the user-space program.
When a program opens /dev/tunX or /dev/tapX, driver creates and registers corresponding net device tunX or tapX. After a program closed above devices, driver will automatically delete tunXX or tapXX device and all routes corresponding to it.
This package(http://vtun.sourceforge.net/tun) contains two simple example programs that shows you how to use tun and tap devices. Both programs work like bridge between two network interfaces. br_select.c - bridge based on select system call. br_sigio.c - bridge based on async io and SIGIO signal. However the best example is VTun http://vtun.sourceforge.net
Enhancements:
- Massive Linux driver update: 2.4.x kernel support. New cloning interface, protocol indication. Statistics counting fixes.
- Solaris driver update: Correct Ethernet header substitution.
- Configure and Makefile updates. RPM package update.
- Documentation update.

EXAMPLE

# This is a really long synopsis, but hopefully it will give you an idea...

package MyPackage;

use Class::Driver;
use base q(Class::Driver);

our %drivers;

return 1;

sub new {
my($class, %args) = @_;
die "mime_type is required" unless($args{mime_type});
die "no driver to handle type $args{mime_type}"
unless($drivers{$args{mime_type}});
return $class->driver_load($drivers{$args{mime_type}}, %args);
}

sub driver_new {
my($class, %args) = @_;
return bless %args, $class;
}

sub driver_required { 1; }
sub driver_requied_here { 0; }

package MyPackage::avi;

use MyPackage;
use base q(MyPackage);
use Video::Info;

$MyPackage::drivers{video/x-msvideo} = avi;

return 1;

sub driver { "avi"; }

sub driver_new {
my($class, %args) = @_;
die "file is a required parameter for $args{mime_type} files"
unless($args{file});
$args{info} = Video::Info->new(-file => $args{file})
or die "Failed to create a Video::Info object for $args{file}";
return $class->SUPER::driver_new(%args);
}

sub duration {
my $self = shift;
return $args{info}->duration;
}

package MyPackage::mp3;
use base q(MyPackage);
use MP3::Info;

$MyPackage::drivers{audio/mpeg} = mp3;

## (etc...)

package main;

my $foo = MyPackage->new(file => foobar.mp3, mime_type => audio/mpeg);
print "foobar.mp3 is ", $foo->duration, " seconds long.n";

Apache LDAP vhost driver project lets you put vhost with all possible information in an LDAP database for both Apache 1.x and 2.x.

Bug report system

With the new maintainence, there is now also a bug report system at the URL http://bugs.bayour.com/ (project mod_ldap_cfg).

Schemas

A schema called mod_ldap_cfg is used.

Apache config

To setup Apache to use this module, the httpd.conf is used.

Nomad II supports the Creative Nomad II, IIc and II MG under Linux running USB for file transfers and other operations.
By default, the ownership of the newly created device file for the Nomad II is owned by root, without group/other read+write permissions.
make nomadii setuid root; on startup, nomadii
detects it is running in this mode and changes the owner of the device file to the original user, and then immediately drops back to the user ID of the original user (in order to minimize the possibility of security issues). This can be made with a number of techniques:
use the devuid, devgid or devmode mount options for usbdevfs, either in your /etc/fstab file or located where the mount call for usbdevfs is made (/etc/rc.d/rc.sysinit on RedHat 7.x); for example use devmode=0666 to open full access to all USB devices (with the attendant insecureness this creates). In a multi-user machine, setting up a group for USB would be the more secure option using this method.
locate and install the usb_perms daemon
use the hotplug package; this subsystem has good support for USB devices with user-level drivers such as this one with its usb.usermap launch method. The module launched by hotplug can be used to set ownerships or permissions on the device file as soon as the Nomad II is connected, and then even launch an xterm running a nomadii session. This is the most delicate of these methods to set up - sample instructions are given in the HOTPLUG file that comes with the source distribution.
Enhancements:
- Rename of utility to nomadii
- Availablility of RPM
- Full support of the Nomad II, IIc and II MG with latest firmware
- Autocorrection of bad data when getting files from the Nomad
- Much improved error detection and reporting
- Split of code into text front end and library
- Better name handling and progress reporting
- Updated support for nomadii-driver
- Better USB device permission options
- Added send/get methods
- Added support for multiple send, get and delete
- Hotplug documentation and scripts
- Many major and minor bug fixes

Open Aureal Linux Driver is a fork of Aureals own soundcard drivers for the Vortex 2, Vortex 1 and Vortex Advantage. It is built with the goals of making the drivers more Open Sound System (OSS) compliant, more stable, and supporting later kernels.
Installing the Driver
1. Unpack the distribution:
tar xvzf aureal*.tar.gz
2. Change to the driver directory and become root:
cd aureal*
su
3. Edit the Makefile to suit your system (SMP, CPU type, etc)
4. Type the following install commands:
If you have an 8830-based (Vortex 2) card:
make install
If you have an 8820-based (Vortex 1) card:
make install20
If you have an 8810-based (Vortex Advantage) card:
make install10
There is no need to reboot.
Note: if you get "unresolved symbol" errors during the install, rebuild your kernel with sound support (soundcore) built in (not a module).
Enhancements:
- Works with kernel 2.4.0

The intel-wings project is a Linux driver for the Intel Wireless Series of input devices.
Somehow, Intel managed to avoid using the USB Human Interface Device standards with their wireless gamepads.
All other USB gamepads work out-of-the-box: plug it in, and the computer knows that it has an X axis, a Y axis, and six buttons. Not Intel. Thats where intel-wings comes in.
Wireless Series?
Yes, youve seen them. Everyone hated them. The keyboards were of poor manufacturing, the mice eat batteries like theres no tomorrow, and the whole system was ridiculously expensive. They were killed off by Intel several years ago -- after hitting the shelves and getting a lukewarm reaction, manufacturing was stopped, and support was terminated 18 months after release.
All of these complaints are valid. On the other hand, when used infrequently, the mice last a few months, and work great on a glass coffee table in my living room. (A newer wireless optical mouse wouldnt work.)
The gamepads are actually pretty fun, in my opinion: you can have a whole bunch of them attached to one base station, which is great for playing old console games with friends. You can get a complete set of devices for $10 on eBay, and with Linux-based PVRs becoming increasingly common, I find my devices to be a great addition to my living room.
Note that I wouldnt recommend the mice to anyone that uses their computer on a regular basis, but its easier for navigating menus than a remote control. In my opinion, the Intel Wireless Series devices on Linux PVRs are the way to go.
Enhancements:
- Preliminary keyboard support was added.
- The Intel wireless keyboards are at least partially functional.