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: 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
An example of finding a device:
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.
| name |
The basic path to look for, by default this is |
an IdentityDictionary of available devices
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
A dictionary of available devices, or rather info about them in an instance of LIDInfo, populated by the method findAvailable
an IdentityDictionary
posts a human readable list of available LID devices and their properties (see also LIDInfo)
Find devices in the available device dictionary by specifying one or more characteristics of the device
| 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. |
an IdentityDictionary of devices the match the search query, or nil if no arguments are given
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.
The LID device - an instance of LID.
Same as LID.openPath.
Open a device using its path in the operating system.
| path |
The path in the operating system, e.g. |
The LID device - an instance of LID.
Open a device using its index in the dictionary of available devices
| index |
The index into the dictionary of available devices |
The LID device - an instance of LID.
A dictionary of the opened devices
an IdentityDictionary
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:
When set to true, the incoming data from any opened LID device will be printed to the post window.
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).
| function |
The function to be performed upon receiving element data from the device |
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.
| function |
The function to be added to the list. |
remove a function to the internal FunctionList that will be evaluated whenever data comes in from a device.
| function |
The function to remove from the list, this must be a reference to the Function that was originally added to the list |
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.
Initialize the LID subsystem, this method is called automatically when calling the method findAvailable.
Indicates whether or not the LID subsystem is running.
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.
Device specs are mappings between event codes and symbolic control names. New specs can be added to LID.specs via LID>>*register.
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.
| name |
The name of the device to register it for. |
| spec |
The spec to be added. This should be an IdentityDictionary. |
This returns the specs that have been registered.
This returns a default spec for a mouse device; any mouse, trackball, trackpad or trackpoint should be able to use this spec.
This returns a default spec for a keyboard device; any keyboard or numpad should be able to use this spec.
Close the LID device, closing a device is asynchronous. You can set a closeAction (see below), which will be performed when the device closes.
Returns true if the device is open, false if the device was closed.
Post the LIDInfo of this device in a human readable format. See also LIDInfo.
Post information about all the slots of this device in a human readable format
Post the list of available capabilities in a human readable format
Create a LIDGui for the device.
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
Access a slot by its evtType and evtCode. See also LIDSlot
| evtType |
The eventType to access the slot. |
| evtCode |
The eventCode to access the slot. |
If a spec is defined for this device, then you can use a controlName to look up a slot.
The IdentityDictionary that maps labels for slots to slot indices.
| forceLookup |
If set to true, this will force the dictionary to be reinitialised with the registered spec for this device. |
When set to true, the incoming data from this LID device will be printed to the post window.
Function to be performed when device is closed.
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.
An IdentityDictionary holding all the slots, i.e. controls, of the device
Retrieve the path of this device
Retrieve the LIDInfo of this device
Retrieve the vendor id of this device
Retrieve the product id of this device
The list of available capabilities.
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 the device to use exclusively for SC.
Release the device to use it no longer exclusively for SC.
Check whether the device is grabbed.
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:
When 'action' is nil, actions can be bound to specific events.
Relative slots can have deltaActions:
When a device spec was registered for a given device name, slot actions can be assigned by using the symbolic control name.
some devices have LEDs which can be turned on and off. These show up with d.caps as events of type 0x0011
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++"*")