LID:
Filter:
Classes | Platform > Linux | External Control > HID

LID : Object

Linux Input Device
Source: LID.sc

Description

This class provides a way to access devices in the Linux input layer, which supports many input devices (mouse, keyboard, joystick, gamepad, tablet) and busses (serial, PS/2, USB).

NOTE: For external HID devices it is recommended to use the HID interface, as described in Working with HID, as it will ensure that your code is cross platform compatible. Only in cases where the raw HID interface does not provide access because the device needs a special driver (and this driver is provided in Linux kernel), or in case you want to access internal devices, you should use this class.

NOTE: if you have trouble opening a device, e.g. when you get the message ERROR: LID: Could not open device, please check the LID permissions

First example:

Class Methods

Finding devices

An example of finding a device:

LID.findAvailable(name)

queries the operating system which LID devices are attached to the system and can be accessed. When using LID this is the first method you need to execute, before you can access any device.

Arguments:

name

The basic path to look for, by default this is "event". See also deviceRoot.

Returns:

an IdentityDictionary of available devices

LID.deviceRoot

LID.deviceRoot = value

This is the base path where to look for devices. By default this is: "/dev/input". With findAvailable this is extended with the name that is passed in, which has as a default "event". Hence, by default we look for devices that match the path: "/dev/input/event*".

See below for some Opening devices with alternative deviceRoot

LID.available

A dictionary of available devices, or rather info about them in an instance of LIDInfo, populated by the method findAvailable

Returns:

an IdentityDictionary

LID.postAvailable

posts a human readable list of available LID devices and their properties (see also LIDInfo)

LID.findBy(vendorID, productID, path, version, physical, unique)

Find devices in the available device dictionary by specifying one or more characteristics of the device

Arguments:

vendorID

The vendor ID of the device, this is a number encoded by the device itself.

productID

The product ID of the device, this is a number encoded by the device itself.

path

The path of the device, this is a path defined by the operating system.

version

The version of the device.

physical

The physical location of the device, this is a path defined by the operating system.

unique

A unique identifier for the device, defined by the operating system.

Returns:

an IdentityDictionary of devices the match the search query, or nil if no arguments are given

Opening devices

LID.open(vendorID, productID, path, version, physical, unique)

Open a device with a given vendorID and product ID. For arguments description see *findBy. The method will call the method findBy and use the first available result as the device to open.

Returns:

The LID device - an instance of LID.

LID.new(path)

Same as LID.openPath.

LID.openPath(path)

Open a device using its path in the operating system.

Arguments:

path

The path in the operating system, e.g. "/dev/input/event4"

Returns:

The LID device - an instance of LID.

LID.openAt(index)

Open a device using its index in the dictionary of available devices

Arguments:

index

The index into the dictionary of available devices

Returns:

The LID device - an instance of LID.

LID.openDevices

A dictionary of the opened devices

Returns:

an IdentityDictionary

Adding functions to LID events

Whenever data comes in from an opened LID device, there are two types of actions fired. An action for the incoming element data and an action for the device, indicating that there has been a change in one of the elements. In most cases you will want to use the first action; only in cases where the order of parsing the element data is important, you may want to use the second type - e.g. when dealing with very accurately timed button press combinations.

There are three levels where you can set actions:

LID.debug

LID.debug = onoff: true

When set to true, the incoming data from any opened LID device will be printed to the post window.

LID.action

LID.action = function

Set or get the action to be performed upon receiving element data from any device. The function will be passed the following arguments: the value (mapped between 0 and 1), the raw value, element usage page, the element usage, the element id, the device id, the device (an instance of LID).

Arguments:

function

The function to be performed upon receiving element data from the device

LID.addRecvFunc(function)

add a function to the internal FunctionList that will be evaluated whenever element data comes in from an open device. The arguments passed to the function are as defined above. Use this method if you want to add actions to LID functions from classes you write, so that you still keep the option to add an action on the fly from user code.

Arguments:

function

The function to be added to the list.

LID.removeRecvFunc(function)

remove a function to the internal FunctionList that will be evaluated whenever data comes in from a device.

Arguments:

function

The function to remove from the list, this must be a reference to the Function that was originally added to the list

Managing the LID subsystem

The following methods are used internally to initialize and finalize the LID subsystem, but in rare cases you may wish to manage these methods manually.

LID.initializeLID

Initialize the LID subsystem, this method is called automatically when calling the method findAvailable.

LID.running

Indicates whether or not the LID subsystem is running.

LID.closeAll

This method is called automatically upon Shutdown, if the LID subsystem was initialized. It can be stopped manually, in order to save system resources. This method will close all opened LID devices.

Creating specs for devices

Device specs are mappings between event codes and symbolic control names. New specs can be added to LID.specs via LID>>*register.

LID.register(name, spec)

This will register the spec for the specified device. If the device was opened and did not use the spec before, it will use this spec. See also LID: *specs.

Arguments:

name

The name of the device to register it for.

spec

The spec to be added. This should be an IdentityDictionary.

LID.specs

This returns the specs that have been registered.

LID.mouseDeviceSpec

This returns a default spec for a mouse device; any mouse, trackball, trackpad or trackpoint should be able to use this spec.

LID.keyboardDeviceSpec

This returns a default spec for a keyboard device; any keyboard or numpad should be able to use this spec.

Inherited class methods

Instance Methods

.close

Close the LID device, closing a device is asynchronous. You can set a closeAction (see below), which will be performed when the device closes.

.isOpen

Returns true if the device is open, false if the device was closed.

Posting human readable information about the device

.postInfo

Post the LIDInfo of this device in a human readable format. See also LIDInfo.

.postSlots

Post information about all the slots of this device in a human readable format

.dumpCaps

Post the list of available capabilities in a human readable format

.makeGui

From extension in /usr/local/share/SuperCollider/SCClassLibrary/Platform/linux/GUI/LIDGui.sc

Create a LIDGui for the device.

Accessing slots

Device capabilities are reported as event type and event code mappings. Event type and event code constants can be found in /usr/include/linux/input.h

.slot(evtType, evtCode)

Access a slot by its evtType and evtCode. See also LIDSlot

Arguments:

evtType

The eventType to access the slot.

evtCode

The eventCode to access the slot.

.at(controlName)

If a spec is defined for this device, then you can use a controlName to look up a slot.

.spec(forceLookup: false)

The IdentityDictionary that maps labels for slots to slot indices.

Arguments:

forceLookup

If set to true, this will force the dictionary to be reinitialised with the registered spec for this device.

Adding functionality to the device

.debug

.debug = onoff

When set to true, the incoming data from this LID device will be printed to the post window.

.closeAction

.closeAction = value

Function to be performed when device is closed.

.action

.action = value

Set or get the action to be performed upon receiving data from the device. The function will be passed in the evtType, the evtCode, the value (mapped according to the slot's spec), and the raw value.

Properties of the device

.slots

An IdentityDictionary holding all the slots, i.e. controls, of the device

.path

Retrieve the path of this device

.info

Retrieve the LIDInfo of this device

.vendor

Retrieve the vendor id of this device

.product

Retrieve the product id of this device

.caps

The list of available capabilities.

Grabbing devices

Given proper permissions, devices can be grabbed to prevent use in other applications (including X). Be careful when grabbing mouse or keyboard, as you will not be able to use them for normal interaction (like typing code or moving the mouse pointer) anymore!

.grab(flag: true)

Grab the device to use exclusively for SC.

.ungrab

Release the device to use it no longer exclusively for SC.

.isGrabbed

Check whether the device is grabbed.

Inherited instance methods

Examples

Finding and opening the device

Event actions (raw events)

The device's 'action' instance variable can be used for event notifications. it is passed the event type, code and current value.

If a device is detached LID will detect this, and close the device. It will execute a closeAction, which can be defined by the user:

Event actions (raw slot events)

When 'action' is nil, actions can be bound to specific events.

Relative slots can have deltaActions:

Event actions (symbolic slot events)

When a device spec was registered for a given device name, slot actions can be assigned by using the symbolic control name.

LED's

some devices have LEDs which can be turned on and off. These show up with d.caps as events of type 0x0011

Closing devices

Opening devices with alternative deviceRoot

Input devices are accessed through device nodes, typically /dev/input/event[0-9]. When using a userspace daemon like udev, meaningful names can be assigned to devices.

raw device name:

symbolic device name

device name relative to LID.deviceRoot

build a list of the available devices:

buildDeviceList builds a table of the devices found in LID.deviceRoot+"/event", trying to open all that it finds, looking up its name and closing them again. The result is returned and can later be accessed by LID.deviceList. You can query another name than "/event" by passing an argument. (the search will be: LID.deviceRoot++"/"++name++"*")

NOTE: this is likely to give the info that the devices could not be opened, as "mouse" uses another interface (you can of course access mice via the "event" interface)
NOTE: if you cannot open the devices at all, please look in the helpfile for: LID permissions