From 97f5541fc0c7ed107103e6f87a6522f5327ab4b0 Mon Sep 17 00:00:00 2001 From: Benjamin Tissoires Date: Wed, 13 Jul 2016 18:06:10 +0200 Subject: HID: wacom: leds: use the ledclass instead of custom made sysfs files The now obsolete sysfs files for LEDs and EKRemote are kept for backward compatibility. Both the EKR (read-only) and the regular Cintiqs and Intuos are now sharing the same led API. Signed-off-by: Benjamin Tissoires Acked-by: Ping Cheng Signed-off-by: Jiri Kosina --- Documentation/ABI/testing/sysfs-driver-wacom | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom index dca429340772..2aa5503ee200 100644 --- a/Documentation/ABI/testing/sysfs-driver-wacom +++ b/Documentation/ABI/testing/sysfs-driver-wacom @@ -24,6 +24,7 @@ What: /sys/bus/hid/devices/::./wacom_led/status0_luminance Date: August 2014 Contact: linux-input@vger.kernel.org Description: + Writing to this file sets the status LED luminance (1..127) when the stylus does not touch the tablet surface, and no button is pressed on the stylus. This luminance level is @@ -33,6 +34,7 @@ What: /sys/bus/hid/devices/::./wacom_led/status1_luminance Date: August 2014 Contact: linux-input@vger.kernel.org Description: + Writing to this file sets the status LED luminance (1..127) when the stylus touches the tablet surface, or any button is pressed on the stylus. @@ -41,6 +43,7 @@ What: /sys/bus/hid/devices/::./wacom_led/status_led0_select Date: August 2014 Contact: linux-input@vger.kernel.org Description: + Writing to this file sets which one of the four (for Intuos 4 and Intuos 5) or of the right four (for Cintiq 21UX2 and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on the @@ -50,6 +53,7 @@ What: /sys/bus/hid/devices/::./wacom_led/status_led1_select Date: August 2014 Contact: linux-input@vger.kernel.org Description: + Writing to this file sets which one of the left four (for Cintiq 21UX2 and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on the left are always inactive. @@ -91,6 +95,7 @@ What: /sys/bus/hid/devices/::./wacom_remote//r Date: July 2015 Contact: linux-input@vger.kernel.org Description: + Reading from this file reports the mode status of the remote as indicated by the LED lights on the device. If no reports have been received from the paired device, reading -- cgit 1.4.1 From 17e2adf2a7d755e17fa75495d29cb98d553d4a66 Mon Sep 17 00:00:00 2001 From: Srinivas Pandruvada Date: Sun, 7 Aug 2016 02:25:33 -0700 Subject: Documentation: HID: Intel ISH HID document Document explaining ISH HID operation and implementation. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina --- Documentation/hid/intel-ish-hid.txt | 454 ++++++++++++++++++++++++++++++++++++ 1 file changed, 454 insertions(+) create mode 100644 Documentation/hid/intel-ish-hid.txt (limited to 'Documentation') diff --git a/Documentation/hid/intel-ish-hid.txt b/Documentation/hid/intel-ish-hid.txt new file mode 100644 index 000000000000..d48b21c71ddd --- /dev/null +++ b/Documentation/hid/intel-ish-hid.txt @@ -0,0 +1,454 @@ +Intel Integrated Sensor Hub (ISH) +=============================== + +A sensor hub enables the ability to offload sensor polling and algorithm +processing to a dedicated low power co-processor. This allows the core +processor to go into low power modes more often, resulting in the increased +battery life. + +There are many vendors providing external sensor hubs confirming to HID +Sensor usage tables, and used in several tablets, 2 in 1 convertible laptops +and embedded products. Linux had this support since Linux 3.9. + +Intel® introduced integrated sensor hubs as a part of the SoC starting from +Cherry Trail and now supported on multiple generations of CPU packages. There +are many commercial devices already shipped with Integrated Sensor Hubs (ISH). +These ISH also comply to HID sensor specification, but the difference is the +transport protocol used for communication. The current external sensor hubs +mainly use HID over i2C or USB. But ISH doesn't use either i2c or USB. + +1. Overview + +Using a analogy with a usbhid implementation, the ISH follows a similar model +for a very high speed communication: + + ----------------- ---------------------- + | USB HID | --> | ISH HID | + ----------------- ---------------------- + ----------------- ---------------------- + | USB protocol | --> | ISH Transport | + ----------------- ---------------------- + ----------------- ---------------------- + | EHCI/XHCI | --> | ISH IPC | + ----------------- ---------------------- + PCI PCI + ----------------- ---------------------- + |Host controller| --> | ISH processor | + ----------------- ---------------------- + USB Link + ----------------- ---------------------- + | USB End points| --> | ISH Clients | + ----------------- ---------------------- + +Like USB protocol provides a method for device enumeration, link management +and user data encapsulation, the ISH also provides similar services. But it is +very light weight tailored to manage and communicate with ISH client +applications implemented in the firmware. + +The ISH allows multiple sensor management applications executing in the +firmware. Like USB endpoints the messaging can be to/from a client. As part of +enumeration process, these clients are identified. These clients can be simple +HID sensor applications, sensor calibration application or senor firmware +update application. + +The implementation model is similar, like USB bus, ISH transport is also +implemented as a bus. Each client application executing in the ISH processor +is registered as a device on this bus. The driver, which binds each device +(ISH HID driver) identifies the device type and registers with the hid core. + +2. ISH Implementation: Block Diagram + + --------------------------- + | User Space Applications | + --------------------------- + +----------------IIO ABI---------------- + -------------------------- + | IIO Sensor Drivers | + -------------------------- + -------------------------- + | IIO core | + -------------------------- + -------------------------- + | HID Sensor Hub MFD | + -------------------------- + -------------------------- + | HID Core | + -------------------------- + -------------------------- + | HID over ISH Client | + -------------------------- + -------------------------- + | ISH Transport (ISHTP) | + -------------------------- + -------------------------- + | IPC Drivers | + -------------------------- +OS +---------------- PCI ----------------- +Hardware + Firmware + ---------------------------- + | ISH Hardware/Firmware(FW) | + ---------------------------- + +3. High level processing in above blocks + +3.1 Hardware Interface + +The ISH is exposed as "Non-VGA unclassified PCI device" to the host. The PCI +product and vendor IDs are changed from different generations of processors. So +the source code which enumerate drivers needs to update from generation to +generation. + +3.2 Inter Processor Communication (IPC) driver +Location: drivers/hid/intel-ish-hid/ipc + +The IPC message used memory mapped I/O. The registers are defined in +hw-ish-regs.h. + +3.2.1 IPC/FW message types + +There are two types of messages, one for management of link and other messages +are to and from transport layers. + +TX and RX of Transport messages + +A set of memory mapped register offers support of multi byte messages TX and +RX (E.g.IPC_REG_ISH2HOST_MSG, IPC_REG_HOST2ISH_MSG). The IPC layer maintains +internal queues to sequence messages and send them in order to the FW. +Optionally the caller can register handler to get notification of completion. +A door bell mechanism is used in messaging to trigger processing in host and +client firmware side. When ISH interrupt handler is called, the ISH2HOST +doorbell register is used by host drivers to determine that the interrupt +is for ISH. + +Each side has 32 32-bit message registers and a 32-bit doorbell. Doorbell +register has the following format: +Bits 0..6: fragment length (7 bits are used) +Bits 10..13: encapsulated protocol +Bits 16..19: management command (for IPC management protocol) +Bit 31: doorbell trigger (signal H/W interrupt to the other side) +Other bits are reserved, should be 0. + +3.2.2 Transport layer interface + +To abstract HW level IPC communication, a set of callbacks are registered. +The transport layer uses them to send and receive messages. +Refer to struct ishtp_hw_ops for callbacks. + +3.3 ISH Transport layer +Location: drivers/hid/intel-ish-hid/ishtp/ + +3.3.1 A Generic Transport Layer + +The transport layer is a bi-directional protocol, which defines: +- Set of commands to start, stop, connect, disconnect and flow control +(ishtp/hbm.h) for details +- A flow control mechanism to avoid buffer overflows + +This protocol resembles bus messages described in the following document: +http://www.intel.com/content/dam/www/public/us/en/documents/technical-\ +specifications/dcmi-hi-1-0-spec.pdf "Chapter 7: Bus Message Layer" + +3.3.2 Connection and Flow Control Mechanism + +Each FW client and a protocol is identified by an UUID. In order to communicate +to a FW client, a connection must be established using connect request and +response bus messages. If successful, a pair (host_client_id and fw_client_id) +will identify the connection. + +Once connection is established, peers send each other flow control bus messages +independently. Every peer may send a message only if it has received a +flow-control credit before. Once it sent a message, it may not send another one +before receiving the next flow control credit. +Either side can send disconnect request bus message to end communication. Also +the link will be dropped if major FW reset occurs. + +3.3.3 Peer to Peer data transfer + +Peer to Peer data transfer can happen with or without using DMA. Depending on +the sensor bandwidth requirement DMA can be enabled by using module parameter +ishtp_use_dma under intel_ishtp. + +Each side (host and FW) manages its DMA transfer memory independently. When an +ISHTP client from either host or FW side wants to send something, it decides +whether to send over IPC or over DMA; for each transfer the decision is +independent. The sending side sends DMA_XFER message when the message is in +the respective host buffer (TX when host client sends, RX when FW client +sends). The recipient of DMA message responds with DMA_XFER_ACK, indicating +the sender that the memory region for that message may be reused. + +DMA initialization is started with host sending DMA_ALLOC_NOTIFY bus message +(that includes RX buffer) and FW responds with DMA_ALLOC_NOTIFY_ACK. +Additionally to DMA address communication, this sequence checks capabilities: +if thw host doesn't support DMA, then it won't send DMA allocation, so FW can't +send DMA; if FW doesn't support DMA then it won't respond with +DMA_ALLOC_NOTIFY_ACK, in which case host will not use DMA transfers. +Here ISH acts as busmaster DMA controller. Hence when host sends DMA_XFER, +it's request to do host->ISH DMA transfer; when FW sends DMA_XFER, it means +that it already did DMA and the message resides at host. Thus, DMA_XFER +and DMA_XFER_ACK act as ownership indicators. + +At initial state all outgoing memory belongs to the sender (TX to host, RX to +FW), DMA_XFER transfers ownership on the region that contains ISHTP message to +the receiving side, DMA_XFER_ACK returns ownership to the sender. A sender +needs not wait for previous DMA_XFER to be ack'ed, and may send another message +as long as remaining continuous memory in its ownership is enough. +In principle, multiple DMA_XFER and DMA_XFER_ACK messages may be sent at once +(up to IPC MTU), thus allowing for interrupt throttling. +Currently, ISH FW decides to send over DMA if ISHTP message is more than 3 IPC +fragments and via IPC otherwise. + +3.3.4 Ring Buffers + +When a client initiate a connection, a ring or RX and TX buffers are allocated. +The size of ring can be specified by the client. HID client set 16 and 32 for +TX and RX buffers respectively. On send request from client, the data to be +sent is copied to one of the send ring buffer and scheduled to be sent using +bus message protocol. These buffers are required because the FW may have not +have processed the last message and may not have enough flow control credits +to send. Same thing holds true on receive side and flow control is required. + +3.3.5 Host Enumeration + +The host enumeration bus command allow discovery of clients present in the FW. +There can be multiple sensor clients and clients for calibration function. + +To ease in implantation and allow independent driver handle each client +this transport layer takes advantage of Linux Bus driver model. Each +client is registered as device on the the transport bus (ishtp bus). + +Enumeration sequence of messages: +- Host sends HOST_START_REQ_CMD, indicating that host ISHTP layer is up. +- FW responds with HOST_START_RES_CMD +- Host sends HOST_ENUM_REQ_CMD (enumerate FW clients) +- FW responds with HOST_ENUM_RES_CMD that includes bitmap of available FW +client IDs +- For each FW ID found in that bitmap host sends +HOST_CLIENT_PROPERTIES_REQ_CMD +- FW responds with HOST_CLIENT_PROPERTIES_RES_CMD. Properties include UUID, +max ISHTP message size, etc. +- Once host received properties for that last discovered client, it considers +ISHTP device fully functional (and allocates DMA buffers) + +3.4 HID over ISH Client +Location: drivers/hid/intel-ish-hid + +The ISHTP client driver is responsible for: +- enumerate HID devices under FW ISH client +- Get Report descriptor +- Register with HID core as a LL driver +- Process Get/Set feature request +- Get input reports + +3.5 HID Sensor Hub MFD and IIO sensor drivers + +The functionality in these drivers is the same as an external sensor hub. +Refer to +Documentation/hid/hid-sensor.txt for HID sensor +Documentation/ABI/testing/sysfs-bus-iio for IIO ABIs to user space + +3.6 End to End HID transport Sequence Diagram + +HID-ISH-CLN ISHTP IPC HW + | | | | + | | |-----WAKE UP------------------>| + | | | | + | | |-----HOST READY--------------->| + | | | | + | | |<----MNG_RESET_NOTIFY_ACK----- | + | | | | + | |<----ISHTP_START------ | | + | | | | + | |<-----------------HOST_START_RES_CMD-------------------| + | | | | + | |------------------QUERY_SUBSCRIBER-------------------->| + | | | | + | |------------------HOST_ENUM_REQ_CMD------------------->| + | | | | + | |<-----------------HOST_ENUM_RES_CMD--------------------| + | | | | + | |------------------HOST_CLIENT_PROPERTIES_REQ_CMD------>| + | | | | + | |<-----------------HOST_CLIENT_PROPERTIES_RES_CMD-------| + | Create new device on in ishtp bus | | + | | | | + | |------------------HOST_CLIENT_PROPERTIES_REQ_CMD------>| + | | | | + | |<-----------------HOST_CLIENT_PROPERTIES_RES_CMD-------| + | Create new device on in ishtp bus | | + | | | | + | |--Repeat HOST_CLIENT_PROPERTIES_REQ_CMD-till last one--| + | | | | + probed() + |----ishtp_cl_connect-->|----------------- CLIENT_CONNECT_REQ_CMD-------------->| + | | | | + | |<----------------CLIENT_CONNECT_RES_CMD----------------| + | | | | + |register event callback| | | + | | | | + |ishtp_cl_send( + HOSTIF_DM_ENUM_DEVICES) |----------fill ishtp_msg_hdr struct write to HW----- >| + | | | | + | | |<-----IRQ(IPC_PROTOCOL_ISHTP---| + | | | | + |<--ENUM_DEVICE RSP-----| | | + | | | | +for each enumerated device + |ishtp_cl_send( + HOSTIF_GET_HID_DESCRIPTOR |----------fill ishtp_msg_hdr struct write to HW--- >| + | | | | + ...Response + | | | | +for each enumerated device + |ishtp_cl_send( + HOSTIF_GET_REPORT_DESCRIPTOR |----------fill ishtp_msg_hdr struct write to HW- >| + | | | | + | | | | + hid_allocate_device + | | | | + hid_add_device | | | + | | | | + + +3.7 ISH Debugging + +To debug ISH, event tracing mechanism is used. To enable debug logs +echo 1 > /sys/kernel/debug/tracing/events/intel_ish/enable +cat sys/kernel/debug/tracing/trace + +3.8 ISH IIO sysfs Example on Lenovo thinkpad Yoga 260 + +root@otcpl-ThinkPad-Yoga-260:~# tree -l /sys/bus/iio/devices/ +/sys/bus/iio/devices/ +├── iio:device0 -> ../../../devices/0044:8086:22D8.0001/HID-SENSOR-200073.9.auto/iio:device0 +│   ├── buffer +│   │   ├── enable +│   │   ├── length +│   │   └── watermark +... +│   ├── in_accel_hysteresis +│   ├── in_accel_offset +│   ├── in_accel_sampling_frequency +│   ├── in_accel_scale +│   ├── in_accel_x_raw +│   ├── in_accel_y_raw +│   ├── in_accel_z_raw +│   ├── name +│   ├── scan_elements +│   │   ├── in_accel_x_en +│   │   ├── in_accel_x_index +│   │   ├── in_accel_x_type +│   │   ├── in_accel_y_en +│   │   ├── in_accel_y_index +│   │   ├── in_accel_y_type +│   │   ├── in_accel_z_en +│   │   ├── in_accel_z_index +│   │   └── in_accel_z_type +... +│   │   ├── devices +│   │   │   │   ├── buffer +│   │   │   │   │   ├── enable +│   │   │   │   │   ├── length +│   │   │   │   │   └── watermark +│   │   │   │   ├── dev +│   │   │   │   ├── in_intensity_both_raw +│   │   │   │   ├── in_intensity_hysteresis +│   │   │   │   ├── in_intensity_offset +│   │   │   │   ├── in_intensity_sampling_frequency +│   │   │   │   ├── in_intensity_scale +│   │   │   │   ├── name +│   │   │   │   ├── scan_elements +│   │   │   │   │   ├── in_intensity_both_en +│   │   │   │   │   ├── in_intensity_both_index +│   │   │   │   │   └── in_intensity_both_type +│   │   │   │   ├── trigger +│   │   │   │   │   └── current_trigger +... +│   │   │   │   ├── buffer +│   │   │   │   │   ├── enable +│   │   │   │   │   ├── length +│   │   │   │   │   └── watermark +│   │   │   │   ├── dev +│   │   │   │   ├── in_magn_hysteresis +│   │   │   │   ├── in_magn_offset +│   │   │   │   ├── in_magn_sampling_frequency +│   │   │   │   ├── in_magn_scale +│   │   │   │   ├── in_magn_x_raw +│   │   │   │   ├── in_magn_y_raw +│   │   │   │   ├── in_magn_z_raw +│   │   │   │   ├── in_rot_from_north_magnetic_tilt_comp_raw +│   │   │   │   ├── in_rot_hysteresis +│   │   │   │   ├── in_rot_offset +│   │   │   │   ├── in_rot_sampling_frequency +│   │   │   │   ├── in_rot_scale +│   │   │   │   ├── name +... +│   │   │   │   ├── scan_elements +│   │   │   │   │   ├── in_magn_x_en +│   │   │   │   │   ├── in_magn_x_index +│   │   │   │   │   ├── in_magn_x_type +│   │   │   │   │   ├── in_magn_y_en +│   │   │   │   │   ├── in_magn_y_index +│   │   │   │   │   ├── in_magn_y_type +│   │   │   │   │   ├── in_magn_z_en +│   │   │   │   │   ├── in_magn_z_index +│   │   │   │   │   ├── in_magn_z_type +│   │   │   │   │   ├── in_rot_from_north_magnetic_tilt_comp_en +│   │   │   │   │   ├── in_rot_from_north_magnetic_tilt_comp_index +│   │   │   │   │   └── in_rot_from_north_magnetic_tilt_comp_type +│   │   │   │   ├── trigger +│   │   │   │   │   └── current_trigger +... +│   │   │   │   ├── buffer +│   │   │   │   │   ├── enable +│   │   │   │   │   ├── length +│   │   │   │   │   └── watermark +│   │   │   │   ├── dev +│   │   │   │   ├── in_anglvel_hysteresis +│   │   │   │   ├── in_anglvel_offset +│   │   │   │   ├── in_anglvel_sampling_frequency +│   │   │   │   ├── in_anglvel_scale +│   │   │   │   ├── in_anglvel_x_raw +│   │   │   │   ├── in_anglvel_y_raw +│   │   │   │   ├── in_anglvel_z_raw +│   │   │   │   ├── name +│   │   │   │   ├── scan_elements +│   │   │   │   │   ├── in_anglvel_x_en +│   │   │   │   │   ├── in_anglvel_x_index +│   │   │   │   │   ├── in_anglvel_x_type +│   │   │   │   │   ├── in_anglvel_y_en +│   │   │   │   │   ├── in_anglvel_y_index +│   │   │   │   │   ├── in_anglvel_y_type +│   │   │   │   │   ├── in_anglvel_z_en +│   │   │   │   │   ├── in_anglvel_z_index +│   │   │   │   │   └── in_anglvel_z_type +│   │   │   │   ├── trigger +│   │   │   │   │   └── current_trigger +... +│   │   │   │   ├── buffer +│   │   │   │   │   ├── enable +│   │   │   │   │   ├── length +│   │   │   │   │   └── watermark +│   │   │   │   ├── dev +│   │   │   │   ├── in_anglvel_hysteresis +│   │   │   │   ├── in_anglvel_offset +│   │   │   │   ├── in_anglvel_sampling_frequency +│   │   │   │   ├── in_anglvel_scale +│   │   │   │   ├── in_anglvel_x_raw +│   │   │   │   ├── in_anglvel_y_raw +│   │   │   │   ├── in_anglvel_z_raw +│   │   │   │   ├── name +│   │   │   │   ├── scan_elements +│   │   │   │   │   ├── in_anglvel_x_en +│   │   │   │   │   ├── in_anglvel_x_index +│   │   │   │   │   ├── in_anglvel_x_type +│   │   │   │   │   ├── in_anglvel_y_en +│   │   │   │   │   ├── in_anglvel_y_index +│   │   │   │   │   ├── in_anglvel_y_type +│   │   │   │   │   ├── in_anglvel_z_en +│   │   │   │   │   ├── in_anglvel_z_index +│   │   │   │   │   └── in_anglvel_z_type +│   │   │   │   ├── trigger +│   │   │   │   │   └── current_trigger +... -- cgit 1.4.1 From 961af46f8e2c7bf793352c11262fb37e87706921 Mon Sep 17 00:00:00 2001 From: Simon Wood Date: Sun, 18 Sep 2016 10:55:37 -0600 Subject: HID: hid-logitech: Introduce control for combined pedals feature Introduce a dev_attr which can be used to combine the accelerator and brake pedals into a single axis. This is useful for older games which can not handle seperate accelerator and brake. Signed-off-by: Simon Wood Signed-off-by: Jiri Kosina --- .../ABI/testing/sysfs-driver-hid-logitech-lg4ff | 9 ++++ drivers/hid/hid-lg4ff.c | 58 ++++++++++++++++++++++ 2 files changed, 67 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff b/Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff index db197a879580..9cd7c5adeb7e 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff +++ b/Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff @@ -50,3 +50,12 @@ Description: Displays the real model of the wheel regardless of any alternate mode the wheel might be switched to. It is a read-only value. This entry is not created for devices that have only one mode. + +What: /sys/bus/hid/drivers/logitech//combine_pedals +Date: Sep 2016 +KernelVersion: 4.9 +Contact: Simon Wood +Description: Controls whether a combined value of accelerator and brake is + reported on the Y axis of the controller. Useful for older games + which can do not work with separate accelerator/brake axis. + Off ('0') by default, enabled by setting '1'. diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c index af3a8ec8a746..ca31ce4d2c24 100644 --- a/drivers/hid/hid-lg4ff.c +++ b/drivers/hid/hid-lg4ff.c @@ -75,6 +75,7 @@ static void lg4ff_set_range_g25(struct hid_device *hid, u16 range); struct lg4ff_wheel_data { const u32 product_id; + u16 combine; u16 range; const u16 min_range; const u16 max_range; @@ -345,6 +346,7 @@ static void lg4ff_init_wheel_data(struct lg4ff_wheel_data * const wdata, const s { struct lg4ff_wheel_data t_wdata = { .product_id = wheel->product_id, .real_product_id = real_product_id, + .combine = 0, .min_range = wheel->min_range, .max_range = wheel->max_range, .set_range = wheel->set_range, @@ -885,6 +887,58 @@ static ssize_t lg4ff_alternate_modes_store(struct device *dev, struct device_att } static DEVICE_ATTR(alternate_modes, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH, lg4ff_alternate_modes_show, lg4ff_alternate_modes_store); +static ssize_t lg4ff_combine_show(struct device *dev, struct device_attribute *attr, + char *buf) +{ + struct hid_device *hid = to_hid_device(dev); + struct lg4ff_device_entry *entry; + struct lg_drv_data *drv_data; + size_t count; + + drv_data = hid_get_drvdata(hid); + if (!drv_data) { + hid_err(hid, "Private driver data not found!\n"); + return 0; + } + + entry = drv_data->device_props; + if (!entry) { + hid_err(hid, "Device properties not found!\n"); + return 0; + } + + count = scnprintf(buf, PAGE_SIZE, "%u\n", entry->wdata.combine); + return count; +} + +static ssize_t lg4ff_combine_store(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count) +{ + struct hid_device *hid = to_hid_device(dev); + struct lg4ff_device_entry *entry; + struct lg_drv_data *drv_data; + u16 combine = simple_strtoul(buf, NULL, 10); + + drv_data = hid_get_drvdata(hid); + if (!drv_data) { + hid_err(hid, "Private driver data not found!\n"); + return -EINVAL; + } + + entry = drv_data->device_props; + if (!entry) { + hid_err(hid, "Device properties not found!\n"); + return -EINVAL; + } + + if (combine > 1) + combine = 1; + + entry->wdata.combine = combine; + return count; +} +static DEVICE_ATTR(combine_pedals, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH, lg4ff_combine_show, lg4ff_combine_store); + /* Export the currently set range of the wheel */ static ssize_t lg4ff_range_show(struct device *dev, struct device_attribute *attr, char *buf) @@ -1259,6 +1313,9 @@ int lg4ff_init(struct hid_device *hid) } /* Create sysfs interface */ + error = device_create_file(&hid->dev, &dev_attr_combine_pedals); + if (error) + hid_warn(hid, "Unable to create sysfs interface for \"combine\", errno %d\n", error); error = device_create_file(&hid->dev, &dev_attr_range); if (error) hid_warn(hid, "Unable to create sysfs interface for \"range\", errno %d\n", error); @@ -1358,6 +1415,7 @@ int lg4ff_deinit(struct hid_device *hid) device_remove_file(&hid->dev, &dev_attr_alternate_modes); } + device_remove_file(&hid->dev, &dev_attr_combine_pedals); device_remove_file(&hid->dev, &dev_attr_range); #ifdef CONFIG_LEDS_CLASS { -- cgit 1.4.1 From f777a3a7bd44509d42ecd57135cdb463ea7f023e Mon Sep 17 00:00:00 2001 From: Simon Wood Date: Sun, 18 Sep 2016 10:55:42 -0600 Subject: HID: hid-logitech: Documentation updates/corrections Signed-off-by: Simon Wood Signed-off-by: Jiri Kosina --- .../ABI/testing/sysfs-driver-hid-logitech-lg4ff | 6 ++++++ drivers/hid/Kconfig | 23 +++++++++++++--------- 2 files changed, 20 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff b/Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff index 9cd7c5adeb7e..305dffd229a8 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff +++ b/Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff @@ -35,6 +35,12 @@ Description: Displays a set of alternate modes supported by a wheel. Each DF-EX <*--------> G25 <-> G27 DF-EX <*----------------> G27 + G29: + DF-EX <*> DFP <-> G25 <-> G27 <-> G29 + DF-EX <*--------> G25 <-> G27 <-> G29 + DF-EX <*----------------> G27 <-> G29 + DF-EX <*------------------------> G29 + DFGT: DF-EX <*> DFP <-> DFGT DF-EX <*--------> DFGT diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 78ac4811bd3c..5227d8a9c9ea 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -457,8 +457,6 @@ config LOGITECH_FF - Logitech WingMan Cordless RumblePad - Logitech WingMan Cordless RumblePad 2 - Logitech WingMan Force 3D - - Logitech Formula Force EX - - Logitech WingMan Formula Force GP and if you want to enable force feedback for them. Note: if you say N here, this device will still be supported, but without @@ -488,15 +486,22 @@ config LOGIWHEELS_FF select INPUT_FF_MEMLESS default LOGITECH_FF help - Say Y here if you want to enable force feedback and range setting + Say Y here if you want to enable force feedback and range setting(*) support for following Logitech wheels: + - Logitech G25 (*) + - Logitech G27 (*) + - Logitech G29 (*) - Logitech Driving Force - - Logitech Driving Force Pro - - Logitech Driving Force GT - - Logitech G25 - - Logitech G27 - - Logitech MOMO/MOMO 2 - - Logitech Formula Force EX + - Logitech Driving Force Pro (*) + - Logitech Driving Force GT (*) + - Logitech Driving Force EX/RX + - Logitech Driving Force Wireless + - Logitech Speed Force Wireless + - Logitech MOMO Force + - Logitech MOMO Racing Force + - Logitech Formula Force GP + - Logitech Formula Force EX/RX + - Logitech Wingman Formula Force GP config HID_MAGICMOUSE tristate "Apple Magic Mouse/Trackpad multi-touch support" -- cgit 1.4.1