* [PATCH v3 3/4] Input: st1232 - add overlay touchscreen and buttons handling
From: Javier Carrasco @ 2023-06-16 7:28 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Bastian Hecht, Michael Riesch
Cc: linux-kernel, linux-input, devicetree, Javier Carrasco
In-Reply-To: <20230510-feature-ts_virtobj_patch-v3-0-b4fb7fc4bab7@wolfvision.net>
Use ts-overlay to support overlay objects such as buttons and resized
frames defined in the device tree.
If a overlay-touchscreen is provided, ignore touch events outside of
the area defined by its properties. Otherwise, transform the event
coordinates to the overlay-touchscreen x and y-axis if required.
If buttons are provided, register an additional device to report key
events separately. A key event will be generated if the coordinates
of a touch event are within the area defined by the button properties.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
drivers/input/touchscreen/Kconfig | 1 +
drivers/input/touchscreen/st1232.c | 87 ++++++++++++++++++++++++++++++--------
2 files changed, 70 insertions(+), 18 deletions(-)
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 8382a4d68326..202e559371e8 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -1215,6 +1215,7 @@ config TOUCHSCREEN_SIS_I2C
config TOUCHSCREEN_ST1232
tristate "Sitronix ST1232 or ST1633 touchscreen controllers"
depends on I2C
+ select TOUCHSCREEN_TS_OVERLAY
help
Say Y here if you want to support the Sitronix ST1232
or ST1633 touchscreen controller.
diff --git a/drivers/input/touchscreen/st1232.c b/drivers/input/touchscreen/st1232.c
index f49566dc96f8..7d8a69e4831b 100644
--- a/drivers/input/touchscreen/st1232.c
+++ b/drivers/input/touchscreen/st1232.c
@@ -22,6 +22,7 @@
#include <linux/pm_qos.h>
#include <linux/slab.h>
#include <linux/types.h>
+#include <linux/input/ts-overlay.h>
#define ST1232_TS_NAME "st1232-ts"
#define ST1633_TS_NAME "st1633-ts"
@@ -56,6 +57,8 @@ struct st1232_ts_data {
struct touchscreen_properties prop;
struct dev_pm_qos_request low_latency_req;
struct gpio_desc *reset_gpio;
+ struct input_dev *overlay_keypad;
+ struct ts_overlay_map *map;
const struct st_chip_info *chip_info;
int read_buf_len;
u8 *read_buf;
@@ -129,10 +132,12 @@ static int st1232_ts_read_resolution(struct st1232_ts_data *ts, u16 *max_x,
static int st1232_ts_parse_and_report(struct st1232_ts_data *ts)
{
- struct input_dev *input = ts->input_dev;
+ struct input_dev *tscreen = ts->input_dev;
+ __maybe_unused struct input_dev *keypad = ts->overlay_keypad;
struct input_mt_pos pos[ST_TS_MAX_FINGERS];
u8 z[ST_TS_MAX_FINGERS];
int slots[ST_TS_MAX_FINGERS];
+ __maybe_unused bool button_pressed[ST_TS_MAX_FINGERS];
int n_contacts = 0;
int i;
@@ -143,6 +148,15 @@ static int st1232_ts_parse_and_report(struct st1232_ts_data *ts)
unsigned int x = ((buf[0] & 0x70) << 4) | buf[1];
unsigned int y = ((buf[0] & 0x07) << 8) | buf[2];
+ /* forward button presses to the keypad input device */
+ if (ts_overlay_is_button_slot(ts->map, i) ||
+ ts_overlay_button_press(ts->map, keypad, x, y, i)) {
+ button_pressed[i] = true;
+ continue;
+ }
+ /* Ignore events out of the overlay screen if defined */
+ if (!ts_overlay_mt_on_touchscreen(ts->map, &x, &y))
+ continue;
touchscreen_set_mt_pos(&pos[n_contacts],
&ts->prop, x, y);
@@ -154,18 +168,25 @@ static int st1232_ts_parse_and_report(struct st1232_ts_data *ts)
}
}
- input_mt_assign_slots(input, slots, pos, n_contacts, 0);
+ input_mt_assign_slots(tscreen, slots, pos, n_contacts, 0);
for (i = 0; i < n_contacts; i++) {
- input_mt_slot(input, slots[i]);
- input_mt_report_slot_state(input, MT_TOOL_FINGER, true);
- input_report_abs(input, ABS_MT_POSITION_X, pos[i].x);
- input_report_abs(input, ABS_MT_POSITION_Y, pos[i].y);
+ input_mt_slot(tscreen, slots[i]);
+ input_mt_report_slot_state(tscreen, MT_TOOL_FINGER, true);
+ input_report_abs(tscreen, ABS_MT_POSITION_X, pos[i].x);
+ input_report_abs(tscreen, ABS_MT_POSITION_Y, pos[i].y);
if (ts->chip_info->have_z)
- input_report_abs(input, ABS_MT_TOUCH_MAJOR, z[i]);
+ input_report_abs(tscreen, ABS_MT_TOUCH_MAJOR, z[i]);
+ }
+ input_mt_sync_frame(tscreen);
+ input_sync(tscreen);
+
+ if (ts_overlay_mapped_buttons(ts->map)) {
+ for (i = 0; i < ts->chip_info->max_fingers; i++)
+ if (ts_overlay_is_button_slot(ts->map, i) &&
+ !button_pressed[i])
+ ts_overlay_button_release(ts->map, keypad, i);
+ input_sync(keypad);
}
-
- input_mt_sync_frame(input);
- input_sync(input);
return n_contacts;
}
@@ -226,6 +247,7 @@ static int st1232_ts_probe(struct i2c_client *client)
const struct st_chip_info *match;
struct st1232_ts_data *ts;
struct input_dev *input_dev;
+ struct input_dev __maybe_unused *overlay_keypad;
u16 max_x, max_y;
int error;
@@ -292,18 +314,28 @@ static int st1232_ts_probe(struct i2c_client *client)
if (error)
return error;
- /* Read resolution from the chip */
- error = st1232_ts_read_resolution(ts, &max_x, &max_y);
- if (error) {
- dev_err(&client->dev,
- "Failed to read resolution: %d\n", error);
- return error;
- }
-
if (ts->chip_info->have_z)
input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR, 0,
ts->chip_info->max_area, 0, 0);
+ /* map overlay objects if defined in the device tree */
+ ts->map = ts_overlay_map_objects(&ts->client->dev, ts->input_dev);
+ if (IS_ERR(ts->map))
+ return PTR_ERR(ts->map);
+
+ if (ts_overlay_mapped_touchscreen(ts->map)) {
+ /* Read resolution from the overlay touchscreen if defined*/
+ ts_overlay_get_touchscreen_abs(ts->map, &max_x, &max_y);
+ } else {
+ /* Read resolution from the chip */
+ error = st1232_ts_read_resolution(ts, &max_x, &max_y);
+ if (error) {
+ dev_err(&client->dev,
+ "Failed to read resolution: %d\n", error);
+ return error;
+ }
+ }
+
input_set_abs_params(input_dev, ABS_MT_POSITION_X,
0, max_x, 0, 0);
input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
@@ -335,6 +367,25 @@ static int st1232_ts_probe(struct i2c_client *client)
return error;
}
+ /* Register keypad input device if overlay buttons were defined */
+ if (ts_overlay_mapped_buttons(ts->map)) {
+ overlay_keypad = devm_input_allocate_device(&client->dev);
+ if (!overlay_keypad)
+ return -ENOMEM;
+
+ ts->overlay_keypad = overlay_keypad;
+ overlay_keypad->name = "st1232-keypad";
+ overlay_keypad->id.bustype = BUS_I2C;
+ ts_overlay_set_button_caps(ts->map, overlay_keypad);
+ error = input_register_device(ts->overlay_keypad);
+ if (error) {
+ dev_err(&client->dev,
+ "Unable to register %s input device\n",
+ overlay_keypad->name);
+ return error;
+ }
+ }
+
i2c_set_clientdata(client, ts);
return 0;
--
2.39.2
^ permalink raw reply related
* [PATCH v3 2/4] dt-bindings: touchscreen: add overlay-touchscreen and overlay-buttons properties
From: Javier Carrasco @ 2023-06-16 7:28 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Bastian Hecht, Michael Riesch
Cc: linux-kernel, linux-input, devicetree, Javier Carrasco
In-Reply-To: <20230510-feature-ts_virtobj_patch-v3-0-b4fb7fc4bab7@wolfvision.net>
The overlay-touchscreen object defines an area within the touchscreen
where touch events are reported and their coordinates get converted to
the overlay origin. This object avoids getting events from areas that
are physically hidden by overlay frames.
For touchscreens where overlay buttons on the touchscreen surface are
provided, the overlay-buttons object contains a node for every button
and the key event that should be reported when pressed.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
.../bindings/input/touchscreen/touchscreen.yaml | 139 +++++++++++++++++++++
1 file changed, 139 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
index 895592da9626..6f5d7ac5560e 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
@@ -80,6 +80,145 @@ properties:
touchscreen-y-plate-ohms:
description: Resistance of the Y-plate in Ohms
+ overlay-touchscreen:
+ description: Clipped touchscreen area
+
+ This object can be used to describe a frame that restricts the area
+ within touch events are reported, ignoring the events that occur outside
+ this area. This is of special interest if the touchscreen is shipped
+ with a physical overlay on top of it with a frame that hides some part
+ of the original touchscreen area.
+
+ The x-origin and y-origin properties of this object define the offset of
+ a new origin from where the touchscreen events are referenced.
+ This offset is applied to the events accordingly. The x-size and y-size
+ properties define the size of the overlay-touchscreen (effective area).
+
+ The following example shows the new touchscreen area and the new origin
+ (0',0') for the touch events generated by the device.
+
+ Touchscreen (full area)
+ ┌────────────────────────────────────────┐
+ │ ┌───────────────────────────────┐ │
+ │ │ │ │
+ │ ├ y-size │ │
+ │ │ │ │
+ │ │ overlay-touchscreen │ │
+ │ │ │ │
+ │ │ │ │
+ │ │ x-size │ │
+ │ ┌└──────────────┴────────────────┘ │
+ │(0',0') │
+ ┌└────────────────────────────────────────┘
+ (0,0)
+
+ where (0',0') = (0+x-origin,0+y-origin)
+
+ type: object
+
+ properties:
+ x-origin:
+ description: horizontal origin of the clipped area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ y-origin:
+ description: vertical origin of the clipped area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ x-size:
+ description: horizontal resolution of the clipped area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ y-size:
+ description: vertical resolution of the clipped area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ overlay-buttons:
+ description: list of nodes defining the buttons on the touchscreen
+
+ This object can be used to describe buttons on the touchscreen area,
+ reporting the touch events on their surface as key events instead of
+ the original touch events.
+
+ This is of special interest if the touchscreen is shipped with a
+ physical overlay on top of it where a number of buttons with some
+ predefined functionality are printed. In that case a specific behavior
+ is expected from those buttons instead of raw touch events.
+
+ The overlay-buttons properties define a per-button area as well as an
+ origin relative to the real touchscreen origin. Touch events within the
+ button area are reported as the key event defined in the linux,code
+ property. Given that the key events do not provide coordinates, the
+ button origin is only used to place the button area on the touchscreen
+ surface. Any event outside the overlay-buttons object is reported as a
+ touch event with no coordinate transformation.
+
+ The following example shows a touchscreen with a single button on it
+
+ Touchscreen (full area)
+ ┌───────────────────────────────────┐
+ │ │
+ │ │
+ │ ┌─────────┐ │
+ │ │button 0 │ │
+ │ │KEY_POWER│ │
+ │ └─────────┘ │
+ │ │
+ │ │
+ ┌└───────────────────────────────────┘
+ (0,0)
+
+ The overlay-buttons object can be combined with the overlay-touchscreen
+ object as shown in the following example. In that case only the events
+ within the overlay-touchscreen object are reported as touch events.
+
+ Touchscreen (full area)
+ ┌─────────┬──────────────────────────────┐
+ │ │ │
+ │ │ ┌───────────────────────┐ │
+ │ button 0│ │ │ │
+ │KEY_POWER│ │ │ │
+ │ │ │ │ │
+ ├─────────┤ │ overlay-touchscreen │ │
+ │ │ │ │ │
+ │ │ │ │ │
+ │ button 1│ │ │ │
+ │ KEY_INFO│ ┌└───────────────────────┘ │
+ │ │(0',0') │
+ ┌└─────────┴──────────────────────────────┘
+ (0,0)
+
+ type: object
+
+ patternProperties:
+ '^button-':
+ type: object
+ description:
+ Each button (key) is represented as a sub-node.
+
+ properties:
+ label:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: descriptive name of the button
+
+ linux,code: true
+
+ x-origin:
+ description: horizontal origin of the button area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ y-origin:
+ description: vertical origin of the button area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ x-size:
+ description: horizontal resolution of the button area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ y-size:
+ description: vertical resolution of the button area
+ $ref: /schemas/types.yaml#/definitions/uint32
+
dependencies:
touchscreen-size-x: [ touchscreen-size-y ]
touchscreen-size-y: [ touchscreen-size-x ]
--
2.39.2
^ permalink raw reply related
* [PATCH v3 1/4] Input: ts-overlay - Add touchscreen overlay object handling
From: Javier Carrasco @ 2023-06-16 7:28 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Henrik Rydberg, Bastian Hecht, Michael Riesch
Cc: linux-kernel, linux-input, devicetree, Javier Carrasco
In-Reply-To: <20230510-feature-ts_virtobj_patch-v3-0-b4fb7fc4bab7@wolfvision.net>
Some touchscreens provide mechanical overlays with different objects
like buttons or clipped touchscreen surfaces.
In order to support these objects, add a series of helper functions
to the input subsystem to transform them into overlay objects via
device tree nodes.
These overlay objects consume the raw touch events and report the
expected input events depending on the object properties.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
MAINTAINERS | 7 +
drivers/input/touchscreen/Kconfig | 9 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/ts-overlay.c | 356 +++++++++++++++++++++++++++++++++
include/linux/input/ts-overlay.h | 43 ++++
5 files changed, 416 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7e0b87d5aa2e..db9427926a4c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21434,6 +21434,13 @@ W: https://github.com/srcres258/linux-doc
T: git git://github.com/srcres258/linux-doc.git doc-zh-tw
F: Documentation/translations/zh_TW/
+TOUCHSCREEN OVERLAY OBJECTS
+M: Javier Carrasco <javier.carrasco@wolfvision.net>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: drivers/input/touchscreen/ts-overlay.c
+F: include/linux/input/ts-overlay.h
+
TTY LAYER
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Jiri Slaby <jirislaby@kernel.org>
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 143ff43c67ae..8382a4d68326 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -1388,4 +1388,13 @@ config TOUCHSCREEN_HIMAX_HX83112B
To compile this driver as a module, choose M here: the
module will be called himax_hx83112b.
+config TOUCHSCREEN_TS_OVERLAY
+ bool "Touchscreen Overlay Objects"
+ help
+ Say Y here if you are using a touchscreen driver that supports
+ printed overlays with keys or a clipped touchscreen area.
+
+ Should be selected by the touchscren drivers that support
+ this feature.
+
endif
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 159cd5136fdb..f554826706ff 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -117,3 +117,4 @@ obj-$(CONFIG_TOUCHSCREEN_RASPBERRYPI_FW) += raspberrypi-ts.o
obj-$(CONFIG_TOUCHSCREEN_IQS5XX) += iqs5xx.o
obj-$(CONFIG_TOUCHSCREEN_ZINITIX) += zinitix.o
obj-$(CONFIG_TOUCHSCREEN_HIMAX_HX83112B) += himax_hx83112b.o
+obj-$(CONFIG_TOUCHSCREEN_TS_OVERLAY) += ts-overlay.o
diff --git a/drivers/input/touchscreen/ts-overlay.c b/drivers/input/touchscreen/ts-overlay.c
new file mode 100644
index 000000000000..7afa77d86c1f
--- /dev/null
+++ b/drivers/input/touchscreen/ts-overlay.c
@@ -0,0 +1,356 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Helper functions for overlay objects on touchscreens
+ *
+ * Copyright (c) 2023 Javier Carrasco <javier.carrasco@wolfvision.net>
+ */
+
+#include <linux/property.h>
+#include <linux/input.h>
+#include <linux/input/mt.h>
+#include <linux/module.h>
+#include <linux/input/ts-overlay.h>
+
+enum ts_overlay_valid_objects {
+ TOUCHSCREEN,
+ BUTTON,
+};
+
+static const char *const ts_overlay_names[] = {
+ [TOUCHSCREEN] = "overlay-touchscreen",
+ [BUTTON] = "overlay-buttons",
+};
+
+struct ts_overlay_shape {
+ u32 x_origin;
+ u32 y_origin;
+ u32 x_size;
+ u32 y_size;
+};
+
+struct ts_overlay_button {
+ struct ts_overlay_shape shape;
+ u32 key;
+ bool pressed;
+ int slot;
+};
+
+static int ts_overlay_get_shape_properties(struct fwnode_handle *child_node,
+ struct ts_overlay_shape *shape)
+{
+ int rc;
+
+ rc = fwnode_property_read_u32(child_node, "x-origin", &shape->x_origin);
+ if (rc < 0)
+ return rc;
+
+ rc = fwnode_property_read_u32(child_node, "y-origin", &shape->y_origin);
+ if (rc < 0)
+ return rc;
+
+ rc = fwnode_property_read_u32(child_node, "x-size", &shape->x_size);
+ if (rc < 0)
+ return rc;
+
+ rc = fwnode_property_read_u32(child_node, "y-size", &shape->y_size);
+ if (rc < 0)
+ return rc;
+
+ return 0;
+}
+
+static int ts_overlay_get_button_properties(struct device *dev,
+ struct fwnode_handle *child_node,
+ struct ts_overlay_button *btn)
+{
+ struct fwnode_handle *child_btn;
+ int rc;
+ int j = 0;
+
+ fwnode_for_each_child_node(child_node, child_btn) {
+ rc = ts_overlay_get_shape_properties(child_btn, &btn[j].shape);
+ if (rc < 0)
+ goto button_prop_cleanup;
+
+ rc = fwnode_property_read_u32(child_btn, "linux,code",
+ &btn[j].key);
+ if (rc < 0)
+ goto button_prop_cleanup;
+
+ dev_info(dev, "Added button at (%u, %u), size %ux%u, code=%u\n",
+ btn[j].shape.x_origin, btn[j].shape.y_origin,
+ btn[j].shape.x_size, btn[j].shape.y_size, btn[j].key);
+ j++;
+ }
+
+ return 0;
+
+button_prop_cleanup:
+ fwnode_handle_put(child_btn);
+ return rc;
+}
+
+void ts_overlay_set_button_caps(struct ts_overlay_map *map,
+ struct input_dev *dev)
+{
+ int i;
+
+ for (i = 0; i < map->button_count; i++)
+ input_set_capability(dev, EV_KEY, map->buttons[i].key);
+}
+EXPORT_SYMBOL(ts_overlay_set_button_caps);
+
+static int ts_overlay_count_buttons(struct device *dev)
+{
+ struct fwnode_handle *child_node;
+ struct fwnode_handle *child_button;
+ int count = 0;
+
+ child_node = device_get_named_child_node(dev, ts_overlay_names[BUTTON]);
+ if (!child_node)
+ return 0;
+
+ fwnode_for_each_child_node(child_node, child_button)
+ count++;
+ fwnode_handle_put(child_node);
+
+ return count;
+}
+
+static int ts_overlay_map_touchscreen(struct device *dev,
+ struct ts_overlay_map *map)
+{
+ struct fwnode_handle *child;
+ int rc = 0;
+
+ child = device_get_named_child_node(dev, ts_overlay_names[TOUCHSCREEN]);
+ if (!child)
+ goto touchscreen_ret;
+
+ map->touchscreen =
+ devm_kzalloc(dev, sizeof(*map->touchscreen), GFP_KERNEL);
+ if (!map->touchscreen) {
+ rc = -ENOMEM;
+ goto touchscreen_handle;
+ }
+ rc = ts_overlay_get_shape_properties(child, map->touchscreen);
+ if (rc < 0)
+ goto touchscreen_free;
+
+ map->overlay_touchscreen = true;
+ dev_info(dev, "Added overlay touchscreen at (%u, %u), size %u x %u\n",
+ map->touchscreen->x_origin, map->touchscreen->y_origin,
+ map->touchscreen->x_size, map->touchscreen->y_size);
+
+ rc = 0;
+ goto touchscreen_handle;
+
+touchscreen_free:
+ devm_kfree(dev, map->touchscreen);
+touchscreen_handle:
+ fwnode_handle_put(child);
+touchscreen_ret:
+ return rc;
+}
+
+static int ts_overlay_map_buttons(struct device *dev,
+ struct ts_overlay_map *map,
+ struct input_dev *input)
+{
+ struct fwnode_handle *child;
+ u32 button_count;
+ int rc = 0;
+
+ button_count = ts_overlay_count_buttons(dev);
+ if (button_count) {
+ map->buttons = devm_kcalloc(dev, button_count,
+ sizeof(*map->buttons), GFP_KERNEL);
+ if (!map->buttons) {
+ rc = -ENOMEM;
+ goto map_buttons_ret;
+ }
+ child = device_get_named_child_node(dev,
+ ts_overlay_names[BUTTON]);
+ if (unlikely(!child))
+ goto map_buttons_free;
+
+ rc = ts_overlay_get_button_properties(dev, child, map->buttons);
+ if (rc < 0)
+ goto map_buttons_free;
+
+ map->button_count = button_count;
+ }
+
+ return 0;
+
+map_buttons_free:
+ devm_kfree(dev, map->buttons);
+map_buttons_ret:
+ return rc;
+}
+
+static bool ts_overlay_defined_objects(struct device *dev)
+{
+ struct fwnode_handle *child;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(ts_overlay_names); i++) {
+ child = device_get_named_child_node(dev, ts_overlay_names[i]);
+ if (child) {
+ fwnode_handle_put(child);
+ return true;
+ }
+ fwnode_handle_put(child);
+ }
+
+ return false;
+}
+
+struct ts_overlay_map *ts_overlay_map_objects(struct device *dev,
+ struct input_dev *input)
+{
+ struct ts_overlay_map *map = NULL;
+ int rc;
+
+ if (!ts_overlay_defined_objects(dev))
+ return NULL;
+
+ map = devm_kzalloc(dev, sizeof(*map), GFP_KERNEL);
+ if (!map) {
+ rc = -ENOMEM;
+ goto objects_err;
+ }
+ rc = ts_overlay_map_touchscreen(dev, map);
+ if (rc < 0)
+ goto objects_free;
+
+ rc = ts_overlay_map_buttons(dev, map, input);
+ if (rc < 0)
+ goto objects_free;
+
+ return map;
+
+objects_free:
+ devm_kfree(dev, map);
+objects_err:
+ return ERR_PTR(rc);
+}
+EXPORT_SYMBOL(ts_overlay_map_objects);
+
+void ts_overlay_get_touchscreen_abs(struct ts_overlay_map *map, u16 *x, u16 *y)
+{
+ *x = map->touchscreen->x_size - 1;
+ *y = map->touchscreen->y_size - 1;
+}
+EXPORT_SYMBOL(ts_overlay_get_touchscreen_abs);
+
+static bool ts_overlay_shape_event(struct ts_overlay_shape *shape, u32 x, u32 y)
+{
+ if (!shape)
+ return false;
+
+ if (x >= shape->x_origin && x < (shape->x_origin + shape->x_size) &&
+ y >= shape->y_origin && y < (shape->y_origin + shape->y_size))
+ return true;
+
+ return false;
+}
+
+static bool ts_overlay_touchscreen_event(struct ts_overlay_shape *touchscreen,
+ u32 *x, u32 *y)
+{
+ if (ts_overlay_shape_event(touchscreen, *x, *y)) {
+ *x -= touchscreen->x_origin;
+ *y -= touchscreen->y_origin;
+ return true;
+ }
+
+ return false;
+}
+
+bool ts_overlay_mapped_touchscreen(struct ts_overlay_map *map)
+{
+ if (!map || !map->overlay_touchscreen)
+ return false;
+
+ return true;
+}
+EXPORT_SYMBOL(ts_overlay_mapped_touchscreen);
+
+bool ts_overlay_mapped_buttons(struct ts_overlay_map *map)
+{
+ if (!map || !map->button_count)
+ return false;
+
+ return true;
+}
+EXPORT_SYMBOL(ts_overlay_mapped_buttons);
+
+bool ts_overlay_mt_on_touchscreen(struct ts_overlay_map *map, u32 *x, u32 *y)
+{
+ if (!ts_overlay_mapped_touchscreen(map))
+ return true;
+
+ if (!ts_overlay_touchscreen_event(map->touchscreen, x, y))
+ return false;
+
+ return true;
+}
+EXPORT_SYMBOL(ts_overlay_mt_on_touchscreen);
+
+bool ts_overlay_button_press(struct ts_overlay_map *map,
+ struct input_dev *input, u32 x, u32 y, u32 slot)
+{
+ int i;
+
+ if (!ts_overlay_mapped_buttons(map))
+ return false;
+
+ for (i = 0; i < map->button_count; i++) {
+ if (ts_overlay_shape_event(&map->buttons[i].shape, x, y)) {
+ input_report_key(input, map->buttons[i].key, 1);
+ map->buttons[i].pressed = true;
+ map->buttons[i].slot = slot;
+ return true;
+ }
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(ts_overlay_button_press);
+
+bool ts_overlay_is_button_slot(struct ts_overlay_map *map, int slot)
+{
+ int i;
+
+ if (!map || !map->button_count)
+ return false;
+
+ for (i = 0; i < map->button_count; i++) {
+ if (map->buttons[i].pressed && map->buttons[i].slot == slot)
+ return true;
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(ts_overlay_is_button_slot);
+
+void ts_overlay_button_release(struct ts_overlay_map *map,
+ struct input_dev *input, u32 slot)
+{
+ int i;
+
+ if (!map || !map->button_count)
+ return;
+
+ for (i = 0; i < map->button_count; i++) {
+ if (map->buttons[i].pressed && map->buttons[i].slot == slot) {
+ input_report_key(input, map->buttons[i].key, 0);
+ map->buttons[i].pressed = false;
+ }
+ }
+}
+EXPORT_SYMBOL(ts_overlay_button_release);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Helper functions for overlay objects on touchscreens");
diff --git a/include/linux/input/ts-overlay.h b/include/linux/input/ts-overlay.h
new file mode 100644
index 000000000000..b75df0dec3ab
--- /dev/null
+++ b/include/linux/input/ts-overlay.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023 Javier Carrasco <javier.carrasco@wolfvision.net>
+ */
+
+#ifndef _TS_OVERLAY
+#define _TS_OVERLAY
+
+#include <linux/types.h>
+
+struct input_dev;
+struct device;
+
+struct ts_overlay_map {
+ struct ts_overlay_shape *touchscreen;
+ bool overlay_touchscreen;
+ struct ts_overlay_button *buttons;
+ u32 button_count;
+};
+
+struct ts_overlay_map *ts_overlay_map_objects(struct device *dev,
+ struct input_dev *input);
+
+void ts_overlay_get_touchscreen_abs(struct ts_overlay_map *map, u16 *x, u16 *y);
+
+bool ts_overlay_mapped_touchscreen(struct ts_overlay_map *map);
+
+bool ts_overlay_mapped_buttons(struct ts_overlay_map *map);
+
+bool ts_overlay_mt_on_touchscreen(struct ts_overlay_map *map, u32 *x, u32 *y);
+
+bool ts_overlay_button_press(struct ts_overlay_map *map,
+ struct input_dev *input, u32 x, u32 y, u32 slot);
+
+bool ts_overlay_is_button_slot(struct ts_overlay_map *map, int slot);
+
+void ts_overlay_button_release(struct ts_overlay_map *map,
+ struct input_dev *input, u32 slot);
+
+void ts_overlay_set_button_caps(struct ts_overlay_map *map,
+ struct input_dev *dev);
+
+#endif
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.3 01/30] Input: soc_button_array - add invalid acpi_index DMI quirk handling
From: Sasha Levin @ 2023-06-16 10:24 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Hans de Goede, Dmitry Torokhov, Sasha Levin, linux-input
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit 20a99a291d564a559cc2fd013b4824a3bb3f1db7 ]
Some devices have a wrong entry in their button array which points to
a GPIO which is required in another driver, so soc_button_array must
not claim it.
A specific example of this is the Lenovo Yoga Book X90F / X90L,
where the PNP0C40 home button entry points to a GPIO which is not
a home button and which is required by the lenovo-yogabook driver.
Add a DMI quirk table which can specify an ACPI GPIO resource index which
should be skipped; and add an entry for the Lenovo Yoga Book X90F / X90L
to this new DMI quirk table.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20230414072116.4497-1-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/misc/soc_button_array.c | 30 +++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index 09489380afda7..e79f5497948b8 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -108,6 +108,27 @@ static const struct dmi_system_id dmi_use_low_level_irq[] = {
{} /* Terminating entry */
};
+/*
+ * Some devices have a wrong entry which points to a GPIO which is
+ * required in another driver, so this driver must not claim it.
+ */
+static const struct dmi_system_id dmi_invalid_acpi_index[] = {
+ {
+ /*
+ * Lenovo Yoga Book X90F / X90L, the PNP0C40 home button entry
+ * points to a GPIO which is not a home button and which is
+ * required by the lenovo-yogabook driver.
+ */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "YETI-11"),
+ },
+ .driver_data = (void *)1l,
+ },
+ {} /* Terminating entry */
+};
+
/*
* Get the Nth GPIO number from the ACPI object.
*/
@@ -137,6 +158,8 @@ soc_button_device_create(struct platform_device *pdev,
struct platform_device *pd;
struct gpio_keys_button *gpio_keys;
struct gpio_keys_platform_data *gpio_keys_pdata;
+ const struct dmi_system_id *dmi_id;
+ int invalid_acpi_index = -1;
int error, gpio, irq;
int n_buttons = 0;
@@ -154,10 +177,17 @@ soc_button_device_create(struct platform_device *pdev,
gpio_keys = (void *)(gpio_keys_pdata + 1);
n_buttons = 0;
+ dmi_id = dmi_first_match(dmi_invalid_acpi_index);
+ if (dmi_id)
+ invalid_acpi_index = (long)dmi_id->driver_data;
+
for (info = button_info; info->name; info++) {
if (info->autorepeat != autorepeat)
continue;
+ if (info->acpi_index == invalid_acpi_index)
+ continue;
+
error = soc_button_lookup_gpio(&pdev->dev, info->acpi_index, &gpio, &irq);
if (error || irq < 0) {
/*
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 6.1 01/26] Input: soc_button_array - add invalid acpi_index DMI quirk handling
From: Sasha Levin @ 2023-06-16 10:25 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Hans de Goede, Dmitry Torokhov, Sasha Levin, linux-input
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit 20a99a291d564a559cc2fd013b4824a3bb3f1db7 ]
Some devices have a wrong entry in their button array which points to
a GPIO which is required in another driver, so soc_button_array must
not claim it.
A specific example of this is the Lenovo Yoga Book X90F / X90L,
where the PNP0C40 home button entry points to a GPIO which is not
a home button and which is required by the lenovo-yogabook driver.
Add a DMI quirk table which can specify an ACPI GPIO resource index which
should be skipped; and add an entry for the Lenovo Yoga Book X90F / X90L
to this new DMI quirk table.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20230414072116.4497-1-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/misc/soc_button_array.c | 30 +++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index 09489380afda7..e79f5497948b8 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -108,6 +108,27 @@ static const struct dmi_system_id dmi_use_low_level_irq[] = {
{} /* Terminating entry */
};
+/*
+ * Some devices have a wrong entry which points to a GPIO which is
+ * required in another driver, so this driver must not claim it.
+ */
+static const struct dmi_system_id dmi_invalid_acpi_index[] = {
+ {
+ /*
+ * Lenovo Yoga Book X90F / X90L, the PNP0C40 home button entry
+ * points to a GPIO which is not a home button and which is
+ * required by the lenovo-yogabook driver.
+ */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "YETI-11"),
+ },
+ .driver_data = (void *)1l,
+ },
+ {} /* Terminating entry */
+};
+
/*
* Get the Nth GPIO number from the ACPI object.
*/
@@ -137,6 +158,8 @@ soc_button_device_create(struct platform_device *pdev,
struct platform_device *pd;
struct gpio_keys_button *gpio_keys;
struct gpio_keys_platform_data *gpio_keys_pdata;
+ const struct dmi_system_id *dmi_id;
+ int invalid_acpi_index = -1;
int error, gpio, irq;
int n_buttons = 0;
@@ -154,10 +177,17 @@ soc_button_device_create(struct platform_device *pdev,
gpio_keys = (void *)(gpio_keys_pdata + 1);
n_buttons = 0;
+ dmi_id = dmi_first_match(dmi_invalid_acpi_index);
+ if (dmi_id)
+ invalid_acpi_index = (long)dmi_id->driver_data;
+
for (info = button_info; info->name; info++) {
if (info->autorepeat != autorepeat)
continue;
+ if (info->acpi_index == invalid_acpi_index)
+ continue;
+
error = soc_button_lookup_gpio(&pdev->dev, info->acpi_index, &gpio, &irq);
if (error || irq < 0) {
/*
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 5.10 01/14] Input: soc_button_array - add invalid acpi_index DMI quirk handling
From: Sasha Levin @ 2023-06-16 10:27 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Hans de Goede, Dmitry Torokhov, Sasha Levin, linux-input
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit 20a99a291d564a559cc2fd013b4824a3bb3f1db7 ]
Some devices have a wrong entry in their button array which points to
a GPIO which is required in another driver, so soc_button_array must
not claim it.
A specific example of this is the Lenovo Yoga Book X90F / X90L,
where the PNP0C40 home button entry points to a GPIO which is not
a home button and which is required by the lenovo-yogabook driver.
Add a DMI quirk table which can specify an ACPI GPIO resource index which
should be skipped; and add an entry for the Lenovo Yoga Book X90F / X90L
to this new DMI quirk table.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20230414072116.4497-1-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/misc/soc_button_array.c | 30 +++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index 31c02c2019c1c..67a134c8448d2 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -108,6 +108,27 @@ static const struct dmi_system_id dmi_use_low_level_irq[] = {
{} /* Terminating entry */
};
+/*
+ * Some devices have a wrong entry which points to a GPIO which is
+ * required in another driver, so this driver must not claim it.
+ */
+static const struct dmi_system_id dmi_invalid_acpi_index[] = {
+ {
+ /*
+ * Lenovo Yoga Book X90F / X90L, the PNP0C40 home button entry
+ * points to a GPIO which is not a home button and which is
+ * required by the lenovo-yogabook driver.
+ */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "YETI-11"),
+ },
+ .driver_data = (void *)1l,
+ },
+ {} /* Terminating entry */
+};
+
/*
* Get the Nth GPIO number from the ACPI object.
*/
@@ -137,6 +158,8 @@ soc_button_device_create(struct platform_device *pdev,
struct platform_device *pd;
struct gpio_keys_button *gpio_keys;
struct gpio_keys_platform_data *gpio_keys_pdata;
+ const struct dmi_system_id *dmi_id;
+ int invalid_acpi_index = -1;
int error, gpio, irq;
int n_buttons = 0;
@@ -154,10 +177,17 @@ soc_button_device_create(struct platform_device *pdev,
gpio_keys = (void *)(gpio_keys_pdata + 1);
n_buttons = 0;
+ dmi_id = dmi_first_match(dmi_invalid_acpi_index);
+ if (dmi_id)
+ invalid_acpi_index = (long)dmi_id->driver_data;
+
for (info = button_info; info->name; info++) {
if (info->autorepeat != autorepeat)
continue;
+ if (info->acpi_index == invalid_acpi_index)
+ continue;
+
error = soc_button_lookup_gpio(&pdev->dev, info->acpi_index, &gpio, &irq);
if (error || irq < 0) {
/*
--
2.39.2
^ permalink raw reply related
* [PATCH AUTOSEL 5.15 01/16] Input: soc_button_array - add invalid acpi_index DMI quirk handling
From: Sasha Levin @ 2023-06-16 10:27 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Hans de Goede, Dmitry Torokhov, Sasha Levin, linux-input
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit 20a99a291d564a559cc2fd013b4824a3bb3f1db7 ]
Some devices have a wrong entry in their button array which points to
a GPIO which is required in another driver, so soc_button_array must
not claim it.
A specific example of this is the Lenovo Yoga Book X90F / X90L,
where the PNP0C40 home button entry points to a GPIO which is not
a home button and which is required by the lenovo-yogabook driver.
Add a DMI quirk table which can specify an ACPI GPIO resource index which
should be skipped; and add an entry for the Lenovo Yoga Book X90F / X90L
to this new DMI quirk table.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20230414072116.4497-1-hdegoede@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/misc/soc_button_array.c | 30 +++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index 31c02c2019c1c..67a134c8448d2 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -108,6 +108,27 @@ static const struct dmi_system_id dmi_use_low_level_irq[] = {
{} /* Terminating entry */
};
+/*
+ * Some devices have a wrong entry which points to a GPIO which is
+ * required in another driver, so this driver must not claim it.
+ */
+static const struct dmi_system_id dmi_invalid_acpi_index[] = {
+ {
+ /*
+ * Lenovo Yoga Book X90F / X90L, the PNP0C40 home button entry
+ * points to a GPIO which is not a home button and which is
+ * required by the lenovo-yogabook driver.
+ */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "YETI-11"),
+ },
+ .driver_data = (void *)1l,
+ },
+ {} /* Terminating entry */
+};
+
/*
* Get the Nth GPIO number from the ACPI object.
*/
@@ -137,6 +158,8 @@ soc_button_device_create(struct platform_device *pdev,
struct platform_device *pd;
struct gpio_keys_button *gpio_keys;
struct gpio_keys_platform_data *gpio_keys_pdata;
+ const struct dmi_system_id *dmi_id;
+ int invalid_acpi_index = -1;
int error, gpio, irq;
int n_buttons = 0;
@@ -154,10 +177,17 @@ soc_button_device_create(struct platform_device *pdev,
gpio_keys = (void *)(gpio_keys_pdata + 1);
n_buttons = 0;
+ dmi_id = dmi_first_match(dmi_invalid_acpi_index);
+ if (dmi_id)
+ invalid_acpi_index = (long)dmi_id->driver_data;
+
for (info = button_info; info->name; info++) {
if (info->autorepeat != autorepeat)
continue;
+ if (info->acpi_index == invalid_acpi_index)
+ continue;
+
error = soc_button_lookup_gpio(&pdev->dev, info->acpi_index, &gpio, &irq);
if (error || irq < 0) {
/*
--
2.39.2
^ permalink raw reply related
* [PATCH] Input: pinephone-keyboard - Use devm_regulator_get_enable()
From: Christophe JAILLET @ 2023-06-17 7:05 UTC (permalink / raw)
To: Samuel Holland, Dmitry Torokhov
Cc: linux-kernel, kernel-janitors, Christophe JAILLET, linux-input
Use devm_regulator_get_enable() instead of hand writing it. It saves some
line of code.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/input/keyboard/pinephone-keyboard.c | 20 +-------------------
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/input/keyboard/pinephone-keyboard.c b/drivers/input/keyboard/pinephone-keyboard.c
index 038ff3549a7a..147b1f288a33 100644
--- a/drivers/input/keyboard/pinephone-keyboard.c
+++ b/drivers/input/keyboard/pinephone-keyboard.c
@@ -318,40 +318,22 @@ static void ppkb_close(struct input_dev *input)
ppkb_set_scan(client, false);
}
-static void ppkb_regulator_disable(void *regulator)
-{
- regulator_disable(regulator);
-}
-
static int ppkb_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
unsigned int phys_rows, phys_cols;
struct pinephone_keyboard *ppkb;
- struct regulator *vbat_supply;
u8 info[PPKB_MATRIX_SIZE + 1];
struct device_node *i2c_bus;
int ret;
int error;
- vbat_supply = devm_regulator_get(dev, "vbat");
- error = PTR_ERR_OR_ZERO(vbat_supply);
+ error = devm_regulator_get_enable(dev, "vbat");
if (error) {
dev_err(dev, "Failed to get VBAT supply: %d\n", error);
return error;
}
- error = regulator_enable(vbat_supply);
- if (error) {
- dev_err(dev, "Failed to enable VBAT: %d\n", error);
- return error;
- }
-
- error = devm_add_action_or_reset(dev, ppkb_regulator_disable,
- vbat_supply);
- if (error)
- return error;
-
ret = i2c_smbus_read_i2c_block_data(client, 0, sizeof(info), info);
if (ret != sizeof(info)) {
error = ret < 0 ? ret : -EIO;
--
2.34.1
^ permalink raw reply related
* [PATCH] Input: adp5588-keys - Use devm_regulator_get_enable()
From: Christophe JAILLET @ 2023-06-17 7:12 UTC (permalink / raw)
To: Michael Hennerich, Dmitry Torokhov
Cc: linux-kernel, kernel-janitors, Christophe JAILLET, linux-input
Use devm_regulator_get_enable() instead of hand writing it. It saves some
line of code.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/input/keyboard/adp5588-keys.c | 17 +----------------
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/input/keyboard/adp5588-keys.c b/drivers/input/keyboard/adp5588-keys.c
index 896a5a989ddc..61e8e43e9c2b 100644
--- a/drivers/input/keyboard/adp5588-keys.c
+++ b/drivers/input/keyboard/adp5588-keys.c
@@ -713,17 +713,11 @@ static int adp5588_fw_parse(struct adp5588_kpad *kpad)
return 0;
}
-static void adp5588_disable_regulator(void *reg)
-{
- regulator_disable(reg);
-}
-
static int adp5588_probe(struct i2c_client *client)
{
struct adp5588_kpad *kpad;
struct input_dev *input;
struct gpio_desc *gpio;
- struct regulator *vcc;
unsigned int revid;
int ret;
int error;
@@ -749,16 +743,7 @@ static int adp5588_probe(struct i2c_client *client)
if (error)
return error;
- vcc = devm_regulator_get(&client->dev, "vcc");
- if (IS_ERR(vcc))
- return PTR_ERR(vcc);
-
- error = regulator_enable(vcc);
- if (error)
- return error;
-
- error = devm_add_action_or_reset(&client->dev,
- adp5588_disable_regulator, vcc);
+ error = devm_regulator_get_enable(&client->dev, "vcc");
if (error)
return error;
--
2.34.1
^ permalink raw reply related
* [PATCH] HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651.
From: Mike Hommey @ 2023-06-17 23:09 UTC (permalink / raw)
To: linux-input; +Cc: Filipe Laíns, Jiri Kosina, Benjamin Tissoires
498ba20690357691103de0f766960355247c78be put restarting communication
behind that flag, and this was apparently necessary on the T651, but the
flag was not set for it.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
drivers/hid/hid-logitech-hidpp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index fdb66dc06582..4f227bc5c6b0 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4299,7 +4299,7 @@ static const struct hid_device_id hidpp_devices[] = {
{ /* wireless touchpad T651 */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_T651),
- .driver_data = HIDPP_QUIRK_CLASS_WTP },
+ .driver_data = HIDPP_QUIRK_CLASS_WTP | HIDPP_QUIRK_DELAYED_INIT },
{ /* Mouse Logitech Anywhere MX */
LDJ_DEVICE(0x1017), .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_1P0 },
{ /* Mouse logitech M560 */
--
2.41.0.6.ge371d37104
^ permalink raw reply related
* [PATCH] HID: Reorder fields in 'struct hid_field'
From: Christophe JAILLET @ 2023-06-18 8:08 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-kernel, kernel-janitors, Christophe JAILLET, linux-input
Group some variables based on their sizes to reduce hole and avoid padding.
On x86_64, this shrinks the size of 'struct hid_field'
from 136 to 128 bytes.
It saves a few bytes of memory and is more cache-line friendly.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Using pahole
Before:
======
struct hid_field {
unsigned int physical; /* 0 4 */
unsigned int logical; /* 4 4 */
unsigned int application; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_usage * usage; /* 16 8 */
unsigned int maxusage; /* 24 4 */
unsigned int flags; /* 28 4 */
unsigned int report_offset; /* 32 4 */
unsigned int report_size; /* 36 4 */
unsigned int report_count; /* 40 4 */
unsigned int report_type; /* 44 4 */
__s32 * value; /* 48 8 */
__s32 * new_value; /* 56 8 */
/* --- cacheline 1 boundary (64 bytes) --- */
__s32 * usages_priorities; /* 64 8 */
__s32 logical_minimum; /* 72 4 */
__s32 logical_maximum; /* 76 4 */
__s32 physical_minimum; /* 80 4 */
__s32 physical_maximum; /* 84 4 */
__s32 unit_exponent; /* 88 4 */
unsigned int unit; /* 92 4 */
bool ignored; /* 96 1 */
/* XXX 7 bytes hole, try to pack */
struct hid_report * report; /* 104 8 */
unsigned int index; /* 112 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_input * hidinput; /* 120 8 */
/* --- cacheline 2 boundary (128 bytes) --- */
__u16 dpad; /* 128 2 */
/* XXX 2 bytes hole, try to pack */
unsigned int slot_idx; /* 132 4 */
/* size: 136, cachelines: 3, members: 25 */
/* sum members: 119, holes: 4, sum holes: 17 */
/* last cacheline: 8 bytes */
};
After:
=====
struct hid_field {
unsigned int physical; /* 0 4 */
unsigned int logical; /* 4 4 */
unsigned int application; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_usage * usage; /* 16 8 */
unsigned int maxusage; /* 24 4 */
unsigned int flags; /* 28 4 */
unsigned int report_offset; /* 32 4 */
unsigned int report_size; /* 36 4 */
unsigned int report_count; /* 40 4 */
unsigned int report_type; /* 44 4 */
__s32 * value; /* 48 8 */
__s32 * new_value; /* 56 8 */
/* --- cacheline 1 boundary (64 bytes) --- */
__s32 * usages_priorities; /* 64 8 */
__s32 logical_minimum; /* 72 4 */
__s32 logical_maximum; /* 76 4 */
__s32 physical_minimum; /* 80 4 */
__s32 physical_maximum; /* 84 4 */
__s32 unit_exponent; /* 88 4 */
unsigned int unit; /* 92 4 */
struct hid_report * report; /* 96 8 */
unsigned int index; /* 104 4 */
bool ignored; /* 108 1 */
/* XXX 3 bytes hole, try to pack */
struct hid_input * hidinput; /* 112 8 */
__u16 dpad; /* 120 2 */
/* XXX 2 bytes hole, try to pack */
unsigned int slot_idx; /* 124 4 */
/* size: 128, cachelines: 2, members: 25 */
/* sum members: 119, holes: 3, sum holes: 9 */
};
---
include/linux/hid.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 39e21e3815ad..5be5e671c263 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -480,9 +480,9 @@ struct hid_field {
__s32 physical_maximum;
__s32 unit_exponent;
unsigned unit;
- bool ignored; /* this field is ignored in this event */
struct hid_report *report; /* associated report */
unsigned index; /* index into report->field[] */
+ bool ignored; /* this field is ignored in this event */
/* hidinput data */
struct hid_input *hidinput; /* associated input structure */
__u16 dpad; /* dpad input code */
--
2.34.1
^ permalink raw reply related
* [PATCH] HID: Reorder fields in 'struct hid_input'
From: Christophe JAILLET @ 2023-06-18 9:11 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-kernel, kernel-janitors, Christophe JAILLET, linux-input
Group some variables based on their sizes to reduce hole and avoid padding.
On x86_64, this shrinks the size of 'struct hid_input'
from 72 to 64 bytes.
It saves a few bytes of memory and is more cache-line friendly.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
Using pahole
Before:
======
struct hid_input {
struct list_head list; /* 0 16 */
struct hid_report * report; /* 16 8 */
struct input_dev * input; /* 24 8 */
const char * name; /* 32 8 */
bool registered; /* 40 1 */
/* XXX 7 bytes hole, try to pack */
struct list_head reports; /* 48 16 */
/* --- cacheline 1 boundary (64 bytes) --- */
unsigned int application; /* 64 4 */
/* size: 72, cachelines: 2, members: 7 */
/* sum members: 61, holes: 1, sum holes: 7 */
/* padding: 4 */
/* last cacheline: 8 bytes */
};
After:
=====
struct hid_input {
struct list_head list; /* 0 16 */
struct hid_report * report; /* 16 8 */
struct input_dev * input; /* 24 8 */
const char * name; /* 32 8 */
struct list_head reports; /* 40 16 */
unsigned int application; /* 56 4 */
bool registered; /* 60 1 */
/* size: 64, cachelines: 1, members: 7 */
/* padding: 3 */
};
---
include/linux/hid.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 5be5e671c263..d29c5de96a40 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -555,9 +555,9 @@ struct hid_input {
struct hid_report *report;
struct input_dev *input;
const char *name;
- bool registered;
struct list_head reports; /* the list of reports */
unsigned int application; /* application usage for this input */
+ bool registered;
};
enum hid_type {
--
2.34.1
^ permalink raw reply related
* Clarification about the hidraw documentation on HIDIOCGFEATURE
From: Xiaofan Chen @ 2023-06-19 0:27 UTC (permalink / raw)
To: linux-input; +Cc: Ihor Dutchak
Current documentation
https://docs.kernel.org/hid/hidraw.html
+++++++++++++++++++++++++++++++++++++++++++++++++++++
HIDIOCGFEATURE(len):
Get a Feature Report
This ioctl will request a feature report from the device using the
control endpoint. The first byte
of the supplied buffer should be set to the report number of the
requested report. For devices
which do not use numbered reports, set the first byte to 0. The
returned report buffer will contain
the report number in the first byte, followed by the report data read
from the device. For devices
which do not use numbered reports, the report data will begin at the
first byte of the returned buffer.
++++++++++++++++++++++++++++++++++++++++++++++++++++++
I have doubts about the last sentence. It seems to me that for
devices which do not use
numbered reports, the first byte will be 0 and the report data begins
in the second byte.
This is based on testing results using hidapi and hidapitester, which
use the ioctl.
int HID_API_EXPORT hid_get_feature_report(hid_device *dev, unsigned
char *data, size_t length)
{
int res;
register_device_error(dev, NULL);
res = ioctl(dev->device_handle, HIDIOCGFEATURE(length), data);
if (res < 0)
register_device_error_format(dev, "ioctl (GFEATURE): %s",
strerror(errno));
return res;
}
Reference discussion:
https://github.com/libusb/hidapi/issues/589
Test device is Jan Axelson's generic HID example which I have tested using
libusb and hidapi across platforms as well as using Windows HID API.
So I believe
the FW is good.
http://janaxelson.com/hidpage.htm#MyExampleCode (USB PIC MCU)
--
Xiaofan
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Block a rogue device on ASUS TUF A16
From: Mario Limonciello @ 2023-06-19 3:05 UTC (permalink / raw)
To: Friedrich Vock, linux-input, Natikar, Basavaraj,
S-k, Shyam-sundar
Cc: Jiri Kosina, Benjamin Tissoires
In-Reply-To: <7b2ec797-2fdd-9707-7f53-d0a24ed036fc@gmx.de>
On 6/15/23 07:41, Friedrich Vock wrote:
> Hi,
>
> sorry for taking so long to reply.
>
> On 02.06.23 20:43, Limonciello, Mario wrote:
>> + some AMD guys
>>
>> On 5/30/2023 10:40 AM, Friedrich Vock wrote:
>>> On these laptops, there seems to be a device that, when probed by
>>> i2c-hid, constantly sends bogus interrupts and interferes with the
>>> keyboard controller. When the device is enabled, it takes the keyboard
>>> around 8 seconds to register that keys are being pressed or released.
>>
>> Do you know what interrupt is firing constantly?
>> Presumably it is the GPIO controller master interrupt, right?
>> And it's for GPIO 7 (guessed from acpidump on one of the bug
>> reports).
>>
>> To confirm check /proc/interrupts.
> Seems likely that you guessed correctly. The corresponsing line in
> /proc/interrupts (with the interrupts counts omitted):
> 71: amd_gpio 7 ITE5570:00
OK.
>>
>> If it's not obvious which GPIO is firing there is also a dynamic
>> debug statement in pinctrl-amd.c that may be helpful to figure
>> this out.
>>
>> I would also suspect in Windows this doesn't happen. If possible
>> can you confirm that? Check in Device Manager what driver is bound
>> to this device. Is it "inbox" from Microsoft or is it an ASUS
>> specific driver?
>>
>> I wonder if the GPIO controller got programmed differently in
>> Windows for some reason. We may want to confirm the values for
>> GPIO registers from /sys/kernel/debug/gpio in Linux against those
>> that are programmed in Windows.
>>
>> This can be accomplished using R/W everything in Windows.
>
> Unfortunately I don't have Windows installed on this system. I know some
> people with the Ryzen 9 7940HS model which might, I'll ask them if they
> can give me the configuration on Windows and Linux.
OK, I suggest directing everyone over to the bugs I linked and we should
gather the relevant GPIO controller register dumps from Windows and
Linux on the same hardware there.
>
>>
>>>
>>> Nothing I tried seemed to make the device work, and preventing the
>>> device from being probed doesn't seem to break any functionality of
>>> the laptop.
>>>
>>> Signed-off-by: Friedrich Vock <friedrich.vock@gmx.de>
>>
>> There are a few bug reports that popped up around this issue that should
>> probably also be tagged.
>>
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217336
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217493
>>
>>> ---
>>> drivers/hid/i2c-hid/i2c-hid-core.c | 5 +++
>>> drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c | 48 ++++++++++++++++++++++++
>>> drivers/hid/i2c-hid/i2c-hid.h | 3 ++
>>> 3 files changed, 56 insertions(+)
>>>
>>> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
>>> b/drivers/hid/i2c-hid/i2c-hid-core.c
>>> index efbba0465eef..5f0686d058df 100644
>>> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
>>> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
>>> @@ -1035,6 +1035,11 @@ int i2c_hid_core_probe(struct i2c_client
>>> *client, struct i2chid_ops *ops,
>>>
>>> ihid->quirks = i2c_hid_lookup_quirk(hid->vendor, hid->product);
>>>
>>> + if (i2c_hid_device_blocked(hid->vendor, hid->product)) {
>>> + ret = -ENODEV;
>>> + goto err_irq;
>>> + }
>>> +
>> The thing I worry about here is that an unserviced interrupt can
>> prevent the
>> hardware from going into proper low power states; particularly at
>> runtime.
>>
>> I think we should better understand what's going on before going down
>> this
>> path of just ignoring it.
> Yeah, I guess I should've searched more for a proper explanation/fix
> before submitting hacks like this. Let's see if this can be fixed in a
> cleaner manner than preemptively disabling parts of the system.
Can you please have a try with linux-next or apply this series:
https://lore.kernel.org/linux-gpio/20230421120625.3366-1-mario.limonciello@amd.com/
That does change some of the configuration for the GPIO controller
registers to align how windows is handling debouncing.
I don't think it will change the outcome of your bug, but I'd love
to be surprised.
>>> ret = hid_add_device(hid);
>>> if (ret) {
>>> if (ret != -ENODEV)
>>> diff --git a/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c
>>> b/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c
>>> index 210f17c3a0be..d2c2806b64b4 100644
>>> --- a/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c
>>> +++ b/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c
>>> @@ -440,6 +440,38 @@ static const struct dmi_system_id
>>> i2c_hid_dmi_quirk_table[] = {
>>> { } /* Terminate list */
>>> };
>>>
>>> +static const struct hid_device_id i2c_hid_blocked_ite_device = {
>>> + HID_DEVICE(BUS_I2C, HID_GROUP_GENERIC, USB_VENDOR_ID_ITE, 0x8051)
>>> +};
>>> +
>>> +/*
>>> + * This list contains devices that can't be activated at all, for
>>> example
>>> + * because activating them breaks other important parts of the system.
>>> + */
>>> +static const struct dmi_system_id i2c_hid_dmi_block_table[] = {
>>> + /*
>>> + * On ASUS TUF Gaming A16 laptops, there is a device that will
>>> make the
>>> + * keyboard controller stop working correctly and flood the CPU
>>> with bogus
>>> + * interrupts.
>>> + */
>>> + {
>>> + .ident = "ASUS TUF Gaming A16 (Ryzen 7 7735HS)",
>>> + .matches = {
>>> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>>> + DMI_MATCH(DMI_PRODUCT_NAME, "FA617NS"),
>>> + },
>>> + .driver_data = (void *)&i2c_hid_blocked_ite_device,
>>> + },
>>> + {
>>> + .ident = "ASUS TUF Gaming A16 (Ryzen 9 7940HS)",
>>> + .matches = {
>>> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>>> + DMI_MATCH(DMI_PRODUCT_NAME, "FA617XS"),
>>> + },
>>> + .driver_data = (void *)&i2c_hid_blocked_ite_device,
>>> + },
>>> + { } /* Terminate list */
>> If this *does* end up being the best solution, I think it's better
>> to patch in the DMI to gpiolib-acpi.c similar to other quirks for
>> floating
>> GPIOs. Example:
>>
>> https://github.com/torvalds/linux/blob/master/drivers/gpio/gpiolib-acpi.c#L1654
>>
>>
>>> +};
>>>
>>> struct i2c_hid_desc *i2c_hid_get_dmi_i2c_hid_desc_override(uint8_t
>>> *i2c_name)
>>> {
>>> @@ -492,3 +524,19 @@ u32 i2c_hid_get_dmi_quirks(const u16 vendor,
>>> const u16 product)
>>>
>>> return quirks;
>>> }
>>> +
>>> +bool i2c_hid_device_blocked(const u16 vendor, const u16 product)
>>> +{
>>> + const struct dmi_system_id *system_id =
>>> + dmi_first_match(i2c_hid_dmi_block_table);
>>> +
>>> + if (system_id) {
>>> + const struct hid_device_id *device_id =
>>> + (struct hid_device_id *)(system_id->driver_data);
>>> +
>>> + if (device_id && device_id->vendor == vendor &&
>>> + device_id->product == product)
>>> + return true;
>>> + }
>>> + return false;
>>> +}
>>> diff --git a/drivers/hid/i2c-hid/i2c-hid.h
>>> b/drivers/hid/i2c-hid/i2c-hid.h
>>> index 2c7b66d5caa0..e17bdd758f39 100644
>>> --- a/drivers/hid/i2c-hid/i2c-hid.h
>>> +++ b/drivers/hid/i2c-hid/i2c-hid.h
>>> @@ -10,6 +10,7 @@ struct i2c_hid_desc
>>> *i2c_hid_get_dmi_i2c_hid_desc_override(uint8_t *i2c_name);
>>> char *i2c_hid_get_dmi_hid_report_desc_override(uint8_t *i2c_name,
>>> unsigned int *size);
>>> u32 i2c_hid_get_dmi_quirks(const u16 vendor, const u16 product);
>>> +bool i2c_hid_device_blocked(const u16 vendor, const u16 product);
>>> #else
>>> static inline struct i2c_hid_desc
>>> *i2c_hid_get_dmi_i2c_hid_desc_override(uint8_t *i2c_name)
>>> @@ -19,6 +20,8 @@ static inline char
>>> *i2c_hid_get_dmi_hid_report_desc_override(uint8_t *i2c_name,
>>> { return NULL; }
>>> static inline u32 i2c_hid_get_dmi_quirks(const u16 vendor, const
>>> u16 product)
>>> { return 0; }
>>> +static inline bool i2c_hid_device_blocked(const u16 vendor, const
>>> u16 product)
>>> +{ return false; }
>>> #endif
>>>
>>> /**
>>> --
>>> 2.40.1
>>>
>>>
^ permalink raw reply
* Re: [PATCH] HID: Reorder fields in 'struct hid_field'
From: Dan Carpenter @ 2023-06-19 5:18 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Jiri Kosina, Benjamin Tissoires, linux-kernel, kernel-janitors,
linux-input
In-Reply-To: <a804f2e91bc32cc5e17e012ed90972415606db4e.1687075665.git.christophe.jaillet@wanadoo.fr>
On Sun, Jun 18, 2023 at 10:08:07AM +0200, Christophe JAILLET wrote:
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 39e21e3815ad..5be5e671c263 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -480,9 +480,9 @@ struct hid_field {
> __s32 physical_maximum;
> __s32 unit_exponent;
> unsigned unit;
> - bool ignored; /* this field is ignored in this event */
> struct hid_report *report; /* associated report */
> unsigned index; /* index into report->field[] */
> + bool ignored; /* this field is ignored in this event */
> /* hidinput data */
> struct hid_input *hidinput; /* associated input structure */
> __u16 dpad; /* dpad input code */
You could move the dpad next to the ignored to save another 4 bytes.
I think it is still grouped logically that way but I don't really know
what dpad is so I might be wrong.
struct hid_report *report; /* associated report */
unsigned index; /* index into report->field[] */
bool ignored; /* this field is ignored in this event */
/* hidinput data */
__u16 dpad; /* dpad input code */
struct hid_input *hidinput; /* associated input structure */
regards,
dan carpenter
^ permalink raw reply
* RE: [PATCH] Input: adp5588-keys - Use devm_regulator_get_enable()
From: Hennerich, Michael @ 2023-06-19 6:05 UTC (permalink / raw)
To: Christophe JAILLET, Dmitry Torokhov
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-input@vger.kernel.org
In-Reply-To: <af343b5b0d740cc9f8863264c30e3da4215721d7.1686985911.git.christophe.jaillet@wanadoo.fr>
> -----Original Message-----
> From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> Sent: Samstag, 17. Juni 2023 09:12
> To: Hennerich, Michael <Michael.Hennerich@analog.com>; Dmitry Torokhov
> <dmitry.torokhov@gmail.com>
> Cc: linux-kernel@vger.kernel.org; kernel-janitors@vger.kernel.org; Christophe
> JAILLET <christophe.jaillet@wanadoo.fr>; linux-input@vger.kernel.org
> Subject: [PATCH] Input: adp5588-keys - Use devm_regulator_get_enable()
>
> Use devm_regulator_get_enable() instead of hand writing it. It saves some line
> of code.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Michael Hennerich <michael.hennerich@analog.com>
> ---
> drivers/input/keyboard/adp5588-keys.c | 17 +----------------
> 1 file changed, 1 insertion(+), 16 deletions(-)
>
> diff --git a/drivers/input/keyboard/adp5588-keys.c
> b/drivers/input/keyboard/adp5588-keys.c
> index 896a5a989ddc..61e8e43e9c2b 100644
> --- a/drivers/input/keyboard/adp5588-keys.c
> +++ b/drivers/input/keyboard/adp5588-keys.c
> @@ -713,17 +713,11 @@ static int adp5588_fw_parse(struct adp5588_kpad
> *kpad)
> return 0;
> }
>
> -static void adp5588_disable_regulator(void *reg) -{
> - regulator_disable(reg);
> -}
> -
> static int adp5588_probe(struct i2c_client *client) {
> struct adp5588_kpad *kpad;
> struct input_dev *input;
> struct gpio_desc *gpio;
> - struct regulator *vcc;
> unsigned int revid;
> int ret;
> int error;
> @@ -749,16 +743,7 @@ static int adp5588_probe(struct i2c_client *client)
> if (error)
> return error;
>
> - vcc = devm_regulator_get(&client->dev, "vcc");
> - if (IS_ERR(vcc))
> - return PTR_ERR(vcc);
> -
> - error = regulator_enable(vcc);
> - if (error)
> - return error;
> -
> - error = devm_add_action_or_reset(&client->dev,
> - adp5588_disable_regulator, vcc);
> + error = devm_regulator_get_enable(&client->dev, "vcc");
> if (error)
> return error;
>
> --
> 2.34.1
^ permalink raw reply
* Clarification about the hidraw documentation on HIDIOCGFEATURE
From: Xiaofan Chen @ 2023-06-19 6:09 UTC (permalink / raw)
To: linux-input; +Cc: Ihor Dutchak
In-Reply-To: <CAGjSPUA1A0RVrf1OmgUKL3prOBuNFvhPJXJ4n7YbKrPLZb5h9A@mail.gmail.com>
I know that thurrent documentation has been there since it was created by
Alan Ott many years ago. And he started the HIDAPI project around that
time as well. However, I am starting to doubt whether it is correct or not
based on the testing using HIDAPI.
Please help to clarify. Thanks.
https://docs.kernel.org/hid/hidraw.html
+++++++++++++++++++++++++++++++++++++++++++++++++++++
HIDIOCGFEATURE(len):
Get a Feature Report
This ioctl will request a feature report from the device using the
control endpoint. The first byte of the supplied buffer should be
set to the report number of the requested report. For devices
which do not use numbered reports, set the first byte to 0. The
returned report buffer will contain the report number in the first
byte, followed by the report data read from the device. For devices
which do not use numbered reports, the report data will begin at the
first byte of the returned buffer.
++++++++++++++++++++++++++++++++++++++++++++++++++++++
I have doubts about the last sentence. It seems to me that for
devices which do not use numbered reports, the first byte will
be 0 and the report data begins in the second byte.
This is based on testing results using hidapi and hidapitester, which
use the ioctl.
int HID_API_EXPORT hid_get_feature_report(hid_device *dev, unsigned
char *data, size_t length)
{
int res;
register_device_error(dev, NULL);
res = ioctl(dev->device_handle, HIDIOCGFEATURE(length), data);
if (res < 0)
register_device_error_format(dev, "ioctl (GFEATURE): %s",
strerror(errno));
return res;
}
Reference discussion:
https://github.com/libusb/hidapi/issues/589
Test device is Jan Axelson's generic HID example which I have tested using
libusb and hidapi across platforms as well as using Windows HID API.
So I believe the FW is good.
http://janaxelson.com/hidpage.htm#MyExampleCode (USB PIC MCU)
--
Xiaofan
^ permalink raw reply
* Re: [PATCH RFC 0/4] input: touchscreen: add initial support for Goodix Berlin touchscreen IC
From: Pavel Machek @ 2023-06-19 7:06 UTC (permalink / raw)
To: Hans de Goede
Cc: neil.armstrong, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bastien Nocera, Henrik Rydberg, linux-input,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <1a7bdcc1-c737-83c4-24af-eb0028ed45f4@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 336 bytes --]
Hi!
> > Sure, should I write it down here and/or update the commit message in a new revision ?
>
> Yes please add this to the commit msg for the next version.
Actually, putting this into comment in the driver itself might be
good.
BR,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651.
From: Benjamin Tissoires @ 2023-06-19 14:35 UTC (permalink / raw)
To: linux-input, Mike Hommey; +Cc: Filipe Laíns, Jiri Kosina
In-Reply-To: <20230617230957.6mx73th4blv7owqk@glandium.org>
On Sun, 18 Jun 2023 08:09:57 +0900, Mike Hommey wrote:
> 498ba20690357691103de0f766960355247c78be put restarting communication
> behind that flag, and this was apparently necessary on the T651, but the
> flag was not set for it.
>
>
Applied to hid/hid.git (for-6.4/upstream-fixes), thanks!
[1/1] HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651.
https://git.kernel.org/hid/hid/c/5fe251112646
Cheers,
--
Benjamin Tissoires <benjamin.tissoires@redhat.com>
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651.
From: Benjamin Tissoires @ 2023-06-19 14:38 UTC (permalink / raw)
To: linux-input, Mike Hommey; +Cc: Filipe Laíns, Jiri Kosina
In-Reply-To: <168718531736.2920085.7885355785622180367.b4-ty@redhat.com>
On Jun 19 2023, Benjamin Tissoires wrote:
>
> On Sun, 18 Jun 2023 08:09:57 +0900, Mike Hommey wrote:
> > 498ba20690357691103de0f766960355247c78be put restarting communication
> > behind that flag, and this was apparently necessary on the T651, but the
> > flag was not set for it.
> >
> >
Thanks for spotting this. I've amended the commit message to make
checkpatch.pl happier, and added the cc stable tags.
Cheers,
Benjamin
>
> Applied to hid/hid.git (for-6.4/upstream-fixes), thanks!
>
> [1/1] HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651.
> https://git.kernel.org/hid/hid/c/5fe251112646
>
> Cheers,
> --
> Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
^ permalink raw reply
* Re: Clarification about the hidraw documentation on HIDIOCGFEATURE
From: Xiaofan Chen @ 2023-06-19 15:14 UTC (permalink / raw)
To: linux-input; +Cc: Ihor Dutchak
In-Reply-To: <CAGjSPUAosFY7svBoqAU3xsDD-ij2Qa3nZ2nf+jF4i2yC7sWpWw@mail.gmail.com>
On Mon, Jun 19, 2023 at 2:09 PM Xiaofan Chen <xiaofanc@gmail.com> wrote:
>
> I know that thurrent documentation has been there since it was created by
> Alan Ott many years ago. And he started the HIDAPI project around that
> time as well. However, I am starting to doubt whether it is correct or not
> based on the testing using HIDAPI.
>
> Please help to clarify. Thanks.
>
> https://docs.kernel.org/hid/hidraw.html
> +++++++++++++++++++++++++++++++++++++++++++++++++++++
> HIDIOCGFEATURE(len):
>
> Get a Feature Report
>
> This ioctl will request a feature report from the device using the
> control endpoint. The first byte of the supplied buffer should be
> set to the report number of the requested report. For devices
> which do not use numbered reports, set the first byte to 0. The
> returned report buffer will contain the report number in the first
> byte, followed by the report data read from the device. For devices
> which do not use numbered reports, the report data will begin at the
> first byte of the returned buffer.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> I have doubts about the last sentence. It seems to me that for
> devices which do not use numbered reports, the first byte will
> be 0 and the report data begins in the second byte.
>
> This is based on testing results using hidapi and hidapitester, which
> use the ioctl.
> int HID_API_EXPORT hid_get_feature_report(hid_device *dev, unsigned
> char *data, size_t length)
> {
> int res;
>
> register_device_error(dev, NULL);
>
> res = ioctl(dev->device_handle, HIDIOCGFEATURE(length), data);
> if (res < 0)
> register_device_error_format(dev, "ioctl (GFEATURE): %s",
> strerror(errno));
>
> return res;
> }
>
> Reference discussion:
> https://github.com/libusb/hidapi/issues/589
>
> Test device is Jan Axelson's generic HID example which I have tested using
> libusb and hidapi across platforms as well as using Windows HID API.
> So I believe the FW is good.
> http://janaxelson.com/hidpage.htm#MyExampleCode (USB PIC MCU)
>
Modified testing code from the following Linux kernel
samples/hidraw/hid-example.c
https://github.com/libusb/hidapi/issues/589#issuecomment-1597356054
Results are shown here. We can clearly see that the "Fake Report ID" 0 is
in the first byte of the returned buffer, matching the output from
hidapi/hidapitester,
mcuee@UbuntuSwift3:~/build/hid/hidraw$ gcc -o myhid-example myhid-example.c
mcuee@UbuntuSwift3:~/build/hid/hidraw$ sudo ./myhid-example
Report Descriptor Size: 47
Report Descriptor:
6 a0 ff 9 1 a1 1 9 3 15 0 26 ff 0 75 8 95 3f 81 2 9 4 15 0 26 ff 0 75
8 95 3f 91 2 9 5 15 0 26 ff 0 75 8 95 3f b1 2 c0
Raw Name: Microchip Technology Inc. Generic HID
Raw Phys: usb-0000:00:14.0-1/input0
Raw Info:
bustype: 3 (USB)
vendor: 0x0925
product: 0x7001
ioctl HIDIOCSFEATURE returned: 64
ioctl HIDIOCGFEATURE returned: 64
Report data:
0 41 42 43 44 45 46 47 48 14 4 18 4 4d 72 31 50 51 52 53 54 55 56 57
58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e
6f 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
write() wrote 64 bytes
read() read 63 bytes:
21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37
38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e
4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
--
Xiaofan
^ permalink raw reply
* Re: [PATCH v4 00/17] *** Implement simple haptic HID support ***
From: Sean O'Brien @ 2023-06-19 16:51 UTC (permalink / raw)
To: acz; +Cc: benjamin.tissoires, dmitry.torokhov, jikos, linux-input, upstream
In-Reply-To: <CAB4aORW2-Bgvgro4SzSNPBUHBLG4=w9-uD3kQ+87ZZ6dvqBNPA@mail.gmail.com>
On Fri, Oct 7, 2022 at 8:30 PM Angela Czubak <acz@semihalf.com> wrote:
>
> This patch series introduces changes necessary to support devices
> using simple haptic HID pages.
> Implementation attempts to follow the discussion below:
> https://www.spinics.net/lists/linux-input/msg61091.html
>
> Introduce new haptic defines as specified in HID Usage Tables.
>
> Add new force feedback effect type in order to facilitate using
> simple haptic force feedback.
>
> Add INPUT_PROP_HAPTIC_TOUCHPAD to mark touchpad exposing simple haptic
> support.
>
> Add new struct hid_haptic_device so as to gather simple haptic related
> configuration and current state of the device.
>
> Add new functions to be triggered during HID input mapping and
> configuration in order to detect simple haptic devices.
>
> Modify HID input so that haptic output reports are parsed.
>
> Initialize a haptic device.
>
> Modify FF core so that effect IDs can be shared between multiple open file
> handles.
>
> Add shared release and press effects for a simple haptic device.
>
> Calculate pressure resolution if units are grams or newtons.
>
> Add support for kernel-driven mode of simple haptic device.
>
> Toggle ABS_PRESSURE generation by input-mt on request.
>
> Implement functions allowing switching between kernel-managed mode
> and autonomous mode.
>
> Add simple haptic support for hid-multitouch driver.
>
> Implement EVIOCFF(TAKE|RELEASE)CONTROL ioctls so that userspace can take
> and release control of shared release and press effects.
>
> v2:
> - Describe INPUT_PROP_HAPTIC_TOUCHPAD in
> Documentation/input/event-codes.rst
> - Do not extract mt_get_feature(), use hid_hw_wait() instead
> - Define HID_UNIT_GRAM and HID_UNIT_NEWTON
> - Calculate pressure sum in input-mt if INPUT_MT_TOTAL_FORCE flags set
> - Use u* instead of __u* in struct hid_haptic_device
> - Solve problems with report IDS >= 0xF as Dmitry suggests
>
> v3:
> - Get rid of INPUT_PROP_HAPTIC_TOUCHPAD property as haptic device does not
> gave to be a touchpad
> - Introduce notion of haptic forcepads; generate haptic feedback in kernel
> mode only for forcepads
> - Generate clicks based on maximum pressure across slots instead of the sum
> - Fix off-by-one bug in hid_haptic_upload_effect()
> - Fix resume/suspend: issue hid_haptic_resume() in mt_resume() and
> hid_haptic_suspend() in mt_suspend()
> - Add reset callback for HID i2c devices
> - Implement reset callback for HID multitouch haptic devices
> - Implement lid handler triggering touchpad recalibration for Redrix
>
> v4:
> - Fix mt_reset callback to end earlier if no input devices have been
> configured yet to avoid iterating over uninitialized hid->inputs list
>
> Angela Czubak (17):
> HID: add haptics page defines
> Input: add FF_HID effect type
> HID: haptic: introduce hid_haptic_device
> HID: input: allow mapping of haptic output
> HID: haptic: initialize haptic device
> Input: add shared effects
> HID: haptic: implement release and press effects
> HID: input: calculate resolution for pressure
> HID: haptic: add functions handling events
> Input: MT - add INPUT_MT_MAX_FORCE flags
> HID: haptic: add hid_haptic_switch_mode
> HID: multitouch: add haptic multitouch support
> Input: introduce EVIOCFF(TAKE|RELEASE)CONTROL
> HID: haptic: add hid_haptic_change_control
> HID: add HID device reset callback
> HID: haptic: implement HID haptic reset callback
> HID: multitouch: Add lid handler for touchpad on Redrix chromebook
>
> drivers/hid/Kconfig | 14 +
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-haptic.c | 753 +++++++++++++++++++++++++++++
> drivers/hid/hid-haptic.h | 152 ++++++
> drivers/hid/hid-input.c | 18 +-
> drivers/hid/hid-multitouch.c | 313 +++++++++++-
> drivers/hid/i2c-hid/i2c-hid-core.c | 21 +
> drivers/input/evdev.c | 6 +
> drivers/input/ff-core.c | 129 ++++-
> drivers/input/input-mt.c | 16 +-
> include/linux/hid.h | 31 ++
> include/linux/input.h | 5 +
> include/linux/input/mt.h | 1 +
> include/uapi/linux/input.h | 26 +-
> 14 files changed, 1469 insertions(+), 17 deletions(-)
> create mode 100644 drivers/hid/hid-haptic.c
> create mode 100644 drivers/hid/hid-haptic.h
Hello Jiri,
Will you be able to review this series?
Best,
Sean
^ permalink raw reply
* Re: [PATCH] HID: Reorder fields in 'struct hid_field'
From: Christophe JAILLET @ 2023-06-19 18:20 UTC (permalink / raw)
To: Dan Carpenter
Cc: Jiri Kosina, Benjamin Tissoires, linux-kernel, kernel-janitors,
linux-input
In-Reply-To: <d6026b7f-dc07-4d0c-9805-cc61d6b9a4b8@kadam.mountain>
Le 19/06/2023 à 07:18, Dan Carpenter a écrit :
> On Sun, Jun 18, 2023 at 10:08:07AM +0200, Christophe JAILLET wrote:
>> diff --git a/include/linux/hid.h b/include/linux/hid.h
>> index 39e21e3815ad..5be5e671c263 100644
>> --- a/include/linux/hid.h
>> +++ b/include/linux/hid.h
>> @@ -480,9 +480,9 @@ struct hid_field {
>> __s32 physical_maximum;
>> __s32 unit_exponent;
>> unsigned unit;
>> - bool ignored; /* this field is ignored in this event */
>> struct hid_report *report; /* associated report */
>> unsigned index; /* index into report->field[] */
>> + bool ignored; /* this field is ignored in this event */
>> /* hidinput data */
>> struct hid_input *hidinput; /* associated input structure */
>> __u16 dpad; /* dpad input code */
>
> You could move the dpad next to the ignored to save another 4 bytes.
> I think it is still grouped logically that way but I don't really know
> what dpad is so I might be wrong.
>
> struct hid_report *report; /* associated report */
> unsigned index; /* index into report->field[] */
> bool ignored; /* this field is ignored in this event */
> /* hidinput data */
> __u16 dpad; /* dpad input code */
> struct hid_input *hidinput; /* associated input structure */
>
> regards,
> dan carpenter
>
>
In fact, not really,
It would fill a hole better, but would generate some padding at the end
of the struct:
bool ignored; /* 108 1 */
/* XXX 1 byte hole, try to pack */
__u16 dpad; /* 110 2 */
struct hid_input * hidinput; /* 112 8 */
unsigned int slot_idx; /* 120 4 */
/* size: 128, cachelines: 2, members: 25 */
/* sum members: 119, holes: 2, sum holes: 5 */
/* padding: 4 */
};
CJ
^ permalink raw reply
* Re: [PATCH] HID: intel-ish-hid: ipc: Add Arrow Lake PCI device ID
From: Jiri Kosina @ 2023-06-19 19:09 UTC (permalink / raw)
To: Even Xu; +Cc: linux-input, benjamin.tissoires, srinivas.pandruvada
In-Reply-To: <1686788801-23388-1-git-send-email-even.xu@intel.com>
On Thu, 15 Jun 2023, Even Xu wrote:
> Add device ID of Arrow Lake-H into ishtp support list.
>
> Signed-off-by: Even Xu <even.xu@intel.com>
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> drivers/hid/intel-ish-hid/ipc/hw-ish.h | 1 +
> drivers/hid/intel-ish-hid/ipc/pci-ish.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/hid/intel-ish-hid/ipc/hw-ish.h b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> index fc108f1..e99f3a3 100644
> --- a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> +++ b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
> @@ -33,6 +33,7 @@
> #define ADL_N_DEVICE_ID 0x54FC
> #define RPL_S_DEVICE_ID 0x7A78
> #define MTL_P_DEVICE_ID 0x7E45
> +#define ARL_H_DEVICE_ID 0x7745
>
> #define REVISION_ID_CHT_A0 0x6
> #define REVISION_ID_CHT_Ax_SI 0x0
> diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> index 7120b30..55cb250 100644
> --- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> +++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> @@ -44,6 +44,7 @@ static const struct pci_device_id ish_pci_tbl[] = {
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, ADL_N_DEVICE_ID)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, RPL_S_DEVICE_ID)},
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL, MTL_P_DEVICE_ID)},
> + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, ARL_H_DEVICE_ID)},
> {0, }
> };
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: Clarification about the hidraw documentation on HIDIOCGFEATURE
From: Xiaofan Chen @ 2023-06-19 23:28 UTC (permalink / raw)
To: linux-input; +Cc: Ihor Dutchak
In-Reply-To: <CAGjSPUCBPSXTHji-aSs64QHNYjBms9-WhohBYuc9Tiom5KaSow@mail.gmail.com>
On Mon, Jun 19, 2023 at 11:14 PM Xiaofan Chen <xiaofanc@gmail.com> wrote:
>
> On Mon, Jun 19, 2023 at 2:09 PM Xiaofan Chen <xiaofanc@gmail.com> wrote:
> >
> > I know that thurrent documentation has been there since it was created by
> > Alan Ott many years ago. And he started the HIDAPI project around that
> > time as well. However, I am starting to doubt whether it is correct or not
> > based on the testing using HIDAPI.
> >
> > Please help to clarify. Thanks.
> >
> > https://docs.kernel.org/hid/hidraw.html
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > HIDIOCGFEATURE(len):
> >
> > Get a Feature Report
> >
> > This ioctl will request a feature report from the device using the
> > control endpoint. The first byte of the supplied buffer should be
> > set to the report number of the requested report. For devices
> > which do not use numbered reports, set the first byte to 0. The
> > returned report buffer will contain the report number in the first
> > byte, followed by the report data read from the device. For devices
> > which do not use numbered reports, the report data will begin at the
> > first byte of the returned buffer.
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > I have doubts about the last sentence. It seems to me that for
> > devices which do not use numbered reports, the first byte will
> > be 0 and the report data begins in the second byte.
> >
> > This is based on testing results using hidapi and hidapitester, which
> > use the ioctl.
> > int HID_API_EXPORT hid_get_feature_report(hid_device *dev, unsigned
> > char *data, size_t length)
> > {
> > int res;
> >
> > register_device_error(dev, NULL);
> >
> > res = ioctl(dev->device_handle, HIDIOCGFEATURE(length), data);
> > if (res < 0)
> > register_device_error_format(dev, "ioctl (GFEATURE): %s",
> > strerror(errno));
> >
> > return res;
> > }
> >
> > Reference discussion:
> > https://github.com/libusb/hidapi/issues/589
> >
> > Test device is Jan Axelson's generic HID example which I have tested using
> > libusb and hidapi across platforms as well as using Windows HID API.
> > So I believe the FW is good.
> > http://janaxelson.com/hidpage.htm#MyExampleCode (USB PIC MCU)
> >
>
> Modified testing code from the following Linux kernel
> samples/hidraw/hid-example.c
> https://github.com/libusb/hidapi/issues/589#issuecomment-1597356054
>
> Results are shown here. We can clearly see that the "Fake Report ID" 0 is
> in the first byte of the returned buffer, matching the output from
> hidapi/hidapitester,
>
> mcuee@UbuntuSwift3:~/build/hid/hidraw$ gcc -o myhid-example myhid-example.c
>
> mcuee@UbuntuSwift3:~/build/hid/hidraw$ sudo ./myhid-example
> Report Descriptor Size: 47
> Report Descriptor:
> 6 a0 ff 9 1 a1 1 9 3 15 0 26 ff 0 75 8 95 3f 81 2 9 4 15 0 26 ff 0 75
> 8 95 3f 91 2 9 5 15 0 26 ff 0 75 8 95 3f b1 2 c0
>
> Raw Name: Microchip Technology Inc. Generic HID
> Raw Phys: usb-0000:00:14.0-1/input0
> Raw Info:
> bustype: 3 (USB)
> vendor: 0x0925
> product: 0x7001
> ioctl HIDIOCSFEATURE returned: 64
> ioctl HIDIOCGFEATURE returned: 64
> Report data:
> 0 41 42 43 44 45 46 47 48 14 4 18 4 4d 72 31 50 51 52 53 54 55 56 57
> 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e
> 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f
>
> write() wrote 64 bytes
> read() read 63 bytes:
> 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37
> 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e
> 4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
>
Moreover the kernel codes here seem to prove that the documentation
is wrong for both HIDIOCGFEATURE and HIDIOCGINPUT.
https://github.com/torvalds/linux/blob/master/include/uapi/linux/hidraw.h
/* The first byte of SFEATURE and GFEATURE is the report number */
#define HIDIOCSFEATURE(len) _IOC(_IOC_WRITE|_IOC_READ, 'H', 0x06, len)
#define HIDIOCGFEATURE(len) _IOC(_IOC_WRITE|_IOC_READ, 'H', 0x07, len)
#define HIDIOCGRAWUNIQ(len) _IOC(_IOC_READ, 'H', 0x08, len)
/* The first byte of SINPUT and GINPUT is the report number */
#define HIDIOCSINPUT(len) _IOC(_IOC_WRITE|_IOC_READ, 'H', 0x09, len)
#define HIDIOCGINPUT(len) _IOC(_IOC_WRITE|_IOC_READ, 'H', 0x0A, len)
/* The first byte of SOUTPUT and GOUTPUT is the report number */
#define HIDIOCSOUTPUT(len) _IOC(_IOC_WRITE|_IOC_READ, 'H', 0x0B, len)
#define HIDIOCGOUTPUT(len) _IOC(_IOC_WRITE|_IOC_READ, 'H', 0x0C, len)
--
Xiaofan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox