* [RFC PATCH v2 5/7] of: hw_prober: Support Chromebook SKU ID based component selection
From: Chen-Yu Tsai @ 2023-11-09 10:06 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Hsin-Yi Wang, Dmitry Torokhov, andriy.shevchenko, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, petr.tesarik.ext, rafael, tglx, Jeff LaBundy,
linux-input, Chen-Yu Tsai, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold
In-Reply-To: <20231109100606.1245545-1-wenst@chromium.org>
In cases where the same Chromebook model is manufactured with different
components (MIPI DSI panels, MIPI CSI camera sensors, or trackpad /
touchscreens with conflicting addresses), a different SKU ID is
allocated to each specific combination. This SKU ID is exported by the
bootloader into the device tree, and can be used to "discover" which
combination is present on the current machine.
This change adds a hardware prober that will match the SKU ID against
a provided table, and enable the component for the matched entry based
on the given compatible string. In the MIPI DSI panel and MIPI CSI
camera sensor cases which have OF graphs, it will also update the
remote endpoint to point to the enabled component. This assumes a single
endpoint only.
This will provide a path to reducing the number of Chromebook device
trees.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/of/hw_prober.c | 160 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 160 insertions(+)
diff --git a/drivers/of/hw_prober.c b/drivers/of/hw_prober.c
index 442da6eff896..4345e5aed6d8 100644
--- a/drivers/of/hw_prober.c
+++ b/drivers/of/hw_prober.c
@@ -8,6 +8,7 @@
#include <linux/array_size.h>
#include <linux/i2c.h>
#include <linux/of.h>
+#include <linux/of_graph.h>
#include <linux/platform_device.h>
#define DRV_NAME "hw_prober"
@@ -108,9 +109,168 @@ static int i2c_component_prober(struct platform_device *pdev, const void *data)
return ret;
}
+static int cros_get_coreboot_sku_id(struct device *dev, u32 *sku_id)
+{
+ struct device_node *node = NULL;
+ int ret;
+
+ node = of_find_node_by_path("/firmware/coreboot");
+ if (!node)
+ return dev_err_probe(dev, -EINVAL, "Cannot find coreboot firmware node\n");
+
+ ret = of_property_read_u32(node, "sku-id", sku_id);
+ if (ret)
+ dev_err_probe(dev, ret, "Cannot get SKU ID\n");
+
+ of_node_put(node);
+ return ret;
+}
+
+struct cros_sku_option {
+ u32 sku_id_val;
+ u32 sku_id_mask;
+ const char *compatible;
+};
+
+struct cros_sku_component_data {
+ const struct cros_sku_option *options;
+ int num_options;
+};
+
+/*
+ * cros_sku_component_selector - Selectively enable a component based on SKU ID
+ *
+ * Based on the list of component options and SKU ID read back from the device
+ * tree, enable the matching component. Also update the OF graph if it exists,
+ * so that the enabled component's remote endpoint correctly points to it. This
+ * assumes a single local endpoint, which should be the case for panels and
+ * camera sensors.
+ */
+static int cros_sku_component_selector(struct platform_device *pdev, const void *data)
+{
+ const struct cros_sku_component_data *pdata = data;
+ const char *compatible;
+ struct device_node *node = NULL, *endpoint = NULL, *remote = NULL;
+ struct property *status_prop = NULL, *endpoint_prop = NULL;
+ struct of_changeset *ocs = NULL;
+ __be32 *val = NULL;
+ int ret, i;
+ u32 sku_id;
+
+ if (!data)
+ return dev_err_probe(&pdev->dev, -EINVAL, "No data given\n");
+
+ ret = cros_get_coreboot_sku_id(&pdev->dev, &sku_id);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < pdata->num_options; i++)
+ if ((sku_id & pdata->options[i].sku_id_mask) == pdata->options[i].sku_id_val) {
+ compatible = pdata->options->compatible;
+ break;
+ }
+
+ if (i == pdata->num_options)
+ return dev_err_probe(&pdev->dev, -EINVAL, "Unknown SKU ID: 0x%x\n", sku_id);
+
+ node = of_find_compatible_node(NULL, NULL, compatible);
+ if (!node)
+ return dev_err_probe(&pdev->dev, -ENODEV, "Cannot find matching device node\n");
+
+ /* device node not marked as fail; don't mess with the device tree */
+ if (!of_device_is_fail(node))
+ goto err_free;
+
+ dev_info(&pdev->dev, "Enabling %pOF for SKU 0x%x\n", node, sku_id);
+
+ ret = -ENOMEM;
+ ocs = kzalloc(sizeof(*ocs), GFP_KERNEL);
+ if (!ocs)
+ goto err_free;
+
+ status_prop = kzalloc(sizeof(*status_prop), GFP_KERNEL);
+ if (!status_prop)
+ goto err_free;
+
+ status_prop->name = "status";
+ status_prop->length = 5;
+ status_prop->value = "okay";
+
+ /* Create changeset to apply DT changes atomically */
+ of_changeset_init(ocs);
+
+ if (of_graph_is_present(node)) {
+ ret = -EINVAL;
+
+ /* This currently assumes a single port on the component. */
+ endpoint = of_graph_get_next_endpoint(node, NULL);
+ if (!endpoint) {
+ dev_err(&pdev->dev, "No endpoint found for %pOF\n", node);
+ goto err_destroy_ocs;
+ }
+
+ remote = of_graph_get_remote_endpoint(endpoint);
+ if (!remote) {
+ dev_err(&pdev->dev, "No remote endpoint node found for %pOF\n", endpoint);
+ goto err_destroy_ocs;
+ }
+
+ endpoint_prop = kzalloc(sizeof(*endpoint_prop), GFP_KERNEL);
+ if (!endpoint_prop)
+ goto err_destroy_ocs;
+
+ val = kzalloc(sizeof(*val), GFP_KERNEL);
+ if (!val)
+ goto err_destroy_ocs;
+
+ *val = cpu_to_be32(endpoint->phandle);
+ endpoint_prop->name = "remote-endpoint";
+ endpoint_prop->length = sizeof(*val);
+ endpoint_prop->value = val;
+
+ ret = of_changeset_update_property(ocs, node, endpoint_prop);
+ if (ret)
+ goto err_destroy_ocs;
+ }
+
+ ret = of_changeset_update_property(ocs, node, status_prop);
+ if (ret)
+ goto err_destroy_ocs;
+ ret = of_changeset_apply(ocs);
+ if (ret)
+ goto err_destroy_ocs;
+
+ of_node_put(node);
+
+ return 0;
+
+err_destroy_ocs:
+ of_node_put(remote);
+ of_node_put(endpoint);
+ kfree(val);
+ kfree(endpoint_prop);
+ of_changeset_destroy(ocs);
+err_free:
+ kfree(ocs);
+ kfree(status_prop);
+ of_node_put(node);
+ return ret;
+}
+
+static const struct cros_sku_option cros_krane_panel_options[] = {
+ { .sku_id_val = 0x00, .sku_id_mask = 0xf0, .compatible = "auo,kd101n80-45na" },
+ { .sku_id_val = 0xb0, .sku_id_mask = 0xf0, .compatible = "boe,tv101wum-nl6" },
+};
+
+static const struct cros_sku_component_data cros_krane_panel_data = {
+ .options = cros_krane_panel_options,
+ .num_options = ARRAY_SIZE(cros_krane_panel_options),
+};
+
static const struct hw_prober_entry hw_prober_platforms[] = {
{ .compatible = "google,hana", .prober = i2c_component_prober, .data = "touchscreen" },
{ .compatible = "google,hana", .prober = i2c_component_prober, .data = "trackpad" },
+ { .compatible = "google,krane", .prober = cros_sku_component_selector, .data = &cros_krane_panel_data },
};
static int hw_prober_probe(struct platform_device *pdev)
--
2.42.0.869.gea05f2083d-goog
^ permalink raw reply related
* [RFC PATCH v2 4/7] arm64: dts: mediatek: mt8173-elm-hana: Add G2touch G7500 touchscreen
From: Chen-Yu Tsai @ 2023-11-09 10:06 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Hsin-Yi Wang, Dmitry Torokhov, andriy.shevchenko, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, petr.tesarik.ext, rafael, tglx, Jeff LaBundy,
linux-input, Chen-Yu Tsai, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold
In-Reply-To: <20231109100606.1245545-1-wenst@chromium.org>
This introduces yet another second-source touchscreen found on Hana.
This is a G2touch G7500 touchscreen, which is compatible with HID over
I2C.
Add a device node for it. In keeping with the new scheme for second
source components, mark it as "failed-needs-probe-touchscreen".
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
index 052109b0fa3b..d3f1277ac9b2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
@@ -31,6 +31,15 @@ touchscreen3: touchscreen@20 {
interrupts = <88 IRQ_TYPE_LEVEL_LOW>;
status = "fail-needs-probe-touchscreen";
};
+
+ touchscreen4: touchscreen@40 {
+ compatible = "hid-over-i2c";
+ reg = <0x40>;
+ hid-descr-addr = <0x0001>;
+ interrupt-parent = <&pio>;
+ interrupts = <88 IRQ_TYPE_LEVEL_LOW>;
+ status = "fail-needs-probe-touchscreen";
+ };
};
&i2c4 {
--
2.42.0.869.gea05f2083d-goog
^ permalink raw reply related
* [RFC PATCH v2 3/7] arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail
From: Chen-Yu Tsai @ 2023-11-09 10:06 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Hsin-Yi Wang, Dmitry Torokhov, andriy.shevchenko, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, petr.tesarik.ext, rafael, tglx, Jeff LaBundy,
linux-input, Chen-Yu Tsai, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold
In-Reply-To: <20231109100606.1245545-1-wenst@chromium.org>
Instead of having them all available, mark them all as "fail-needs-probe-*"
and have the implementation try to probe which one is present.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
index bdcd35cecad9..052109b0fa3b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dtsi
@@ -15,6 +15,7 @@ touchscreen2: touchscreen@34 {
reg = <0x34>;
interrupt-parent = <&pio>;
interrupts = <88 IRQ_TYPE_LEVEL_LOW>;
+ status = "fail-needs-probe-touchscreen";
};
/*
@@ -28,6 +29,7 @@ touchscreen3: touchscreen@20 {
hid-descr-addr = <0x0020>;
interrupt-parent = <&pio>;
interrupts = <88 IRQ_TYPE_LEVEL_LOW>;
+ status = "fail-needs-probe-touchscreen";
};
};
@@ -44,6 +46,7 @@ trackpad2: trackpad@2c {
reg = <0x2c>;
hid-descr-addr = <0x0020>;
wakeup-source;
+ status = "fail-needs-probe-trackpad";
};
};
@@ -68,3 +71,11 @@ pins_wp {
};
};
};
+
+&touchscreen {
+ status = "fail-needs-probe-touchscreen";
+};
+
+&trackpad {
+ status = "fail-needs-probe-trackpad";
+};
--
2.42.0.869.gea05f2083d-goog
^ permalink raw reply related
* [RFC PATCH v2 2/7] of: Introduce hardware prober driver
From: Chen-Yu Tsai @ 2023-11-09 10:05 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Hsin-Yi Wang, Dmitry Torokhov, andriy.shevchenko, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, petr.tesarik.ext, rafael, tglx, Jeff LaBundy,
linux-input, Chen-Yu Tsai, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold
In-Reply-To: <20231109100606.1245545-1-wenst@chromium.org>
Some devices are designed and manufactured with some components having
multiple drop-in replacement options. These components are often
connected to the mainboard via ribbon cables, having the same signals
and pin assignments across all options. These may include the display
panel and touchscreen on laptops and tablets, and the trackpad on
laptops. Sometimes which component option is used in a particular device
can be detected by some firmware provided identifier, other times that
information is not available, and the kernel has to try to probe each
device.
This change attempts to make the "probe each device" case cleaner. The
current approach is to have all options added and enabled in the device
tree. The kernel would then bind each device and run each driver's probe
function. This works, but has been broken before due to the introduction
of asynchronous probing, causing multiple instances requesting "shared"
resources, such as pinmuxes, GPIO pins, interrupt lines, at the same
time, with only one instance succeeding. Work arounds for these include
moving the pinmux to the parent I2C controller, using GPIO hogs or
pinmux settings to keep the GPIO pins in some fixed configuration, and
requesting the interrupt line very late. Such configurations can be seen
on the MT8183 Krane Chromebook tablets, and the Qualcomm sc8280xp-based
Lenovo Thinkpad 13S.
Instead of this delicate dance between drivers and device tree quirks,
this change introduces a simple I2C component prober. For any given
class of devices on the same I2C bus, it will go through all of them,
doing a simple I2C read transfer and see which one of them responds.
It will then enable the device that responds.
This requires some minor modifications in the existing device tree.
The status for all the device nodes for the component options must be
set to "failed-needs-probe-xxx". This makes it clear that some mechanism
is needed to enable one of them, and also prevents the prober and device
drivers running at the same time.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/of/Kconfig | 13 ++++
drivers/of/Makefile | 1 +
drivers/of/hw_prober.c | 154 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 168 insertions(+)
create mode 100644 drivers/of/hw_prober.c
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index da9826accb1b..269d20d51936 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -102,4 +102,17 @@ config OF_OVERLAY
config OF_NUMA
bool
+config HW_PROBER
+ bool "Hardware Prober driver"
+ select I2C
+ select OF_DYNAMIC
+ help
+ Some devices will have multiple drop-in options for one component.
+ In many cases the different options are indistinguishable by the
+ kernel without actually probing each possible option.
+
+ This driver is meant to handle the probing of such components, and
+ update the running device tree such that the correct variant is
+ made available.
+
endif # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index eff624854575..ed3875cdc554 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
obj-$(CONFIG_OF_RESOLVE) += resolver.o
obj-$(CONFIG_OF_OVERLAY) += overlay.o
obj-$(CONFIG_OF_NUMA) += of_numa.o
+obj-$(CONFIG_HW_PROBER) += hw_prober.o
ifdef CONFIG_KEXEC_FILE
ifdef CONFIG_OF_FLATTREE
diff --git a/drivers/of/hw_prober.c b/drivers/of/hw_prober.c
new file mode 100644
index 000000000000..442da6eff896
--- /dev/null
+++ b/drivers/of/hw_prober.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * hw_prober.c - Hardware prober driver
+ *
+ * Copyright (c) 2023 Google LLC
+ */
+
+#include <linux/array_size.h>
+#include <linux/i2c.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#define DRV_NAME "hw_prober"
+
+/**
+ * struct hw_prober_entry - Holds an entry for the hardware prober
+ *
+ * @compatible: compatible string to match against the machine
+ * @prober: prober function to call when machine matches
+ * @data: extra data for the prober function
+ */
+struct hw_prober_entry {
+ const char *compatible;
+ int (*prober)(struct platform_device *pdev, const void *data);
+ const void *data;
+};
+
+/*
+ * Some devices, such as Google Hana Chromebooks, are produced by multiple
+ * vendors each using their preferred components. This prober assumes such
+ * drop-in parts are on dedicated I2C busses, have non-conflicting addresses,
+ * and can be directly probed by seeing which address responds without needing
+ * regulators or GPIOs being enabled or toggled.
+ */
+static int i2c_component_prober(struct platform_device *pdev, const void *data)
+{
+ const char *node_name = data;
+ struct device_node *node, *i2c_node;
+ struct i2c_adapter *i2c;
+ int ret = 0;
+
+ node = of_find_node_by_name(NULL, node_name);
+ if (!node)
+ return dev_err_probe(&pdev->dev, -ENODEV, "Could not find %s device node\n",
+ node_name);
+
+ i2c_node = of_get_next_parent(node);
+ if (strcmp(i2c_node->name, "i2c")) {
+ of_node_put(i2c_node);
+ return dev_err_probe(&pdev->dev, -EINVAL, "%s device isn't on I2C bus\n",
+ node_name);
+ }
+
+ for_each_child_of_node(i2c_node, node) {
+ if (!of_node_name_prefix(node, node_name))
+ continue;
+ if (!of_device_is_fail(node)) {
+ /* device tree has component already enabled */
+ of_node_put(node);
+ of_node_put(i2c_node);
+ return 0;
+ }
+ }
+
+ i2c = of_get_i2c_adapter_by_node(i2c_node);
+ if (!i2c) {
+ of_node_put(i2c_node);
+ return dev_err_probe(&pdev->dev, -EPROBE_DEFER, "Couldn't get I2C adapter\n");
+ }
+
+ for_each_child_of_node(i2c_node, node) {
+ struct property *prop;
+ union i2c_smbus_data data;
+ u32 addr;
+
+ if (!of_node_name_prefix(node, node_name))
+ continue;
+ if (of_property_read_u32(node, "reg", &addr))
+ continue;
+ if (i2c_smbus_xfer(i2c, addr, 0, I2C_SMBUS_READ, 0, I2C_SMBUS_BYTE, &data) < 0)
+ continue;
+
+ dev_info(&pdev->dev, "Enabling %pOF\n", node);
+
+ prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+ if (!prop) {
+ ret = -ENOMEM;
+ of_node_put(node);
+ break;
+ }
+
+ prop->name = "status";
+ prop->length = 5;
+ prop->value = "okay";
+
+ /* Found a device that is responding */
+ ret = of_update_property(node, prop);
+ if (ret)
+ kfree(prop);
+
+ of_node_put(node);
+ break;
+ }
+
+ i2c_put_adapter(i2c);
+ of_node_put(i2c_node);
+
+ return ret;
+}
+
+static const struct hw_prober_entry hw_prober_platforms[] = {
+ { .compatible = "google,hana", .prober = i2c_component_prober, .data = "touchscreen" },
+ { .compatible = "google,hana", .prober = i2c_component_prober, .data = "trackpad" },
+};
+
+static int hw_prober_probe(struct platform_device *pdev)
+{
+ for (int i = 0; i < ARRAY_SIZE(hw_prober_platforms); i++)
+ if (of_machine_is_compatible(hw_prober_platforms[i].compatible)) {
+ int ret;
+
+ ret = hw_prober_platforms[i].prober(pdev, hw_prober_platforms[i].data);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct platform_driver hw_prober_driver = {
+ .probe = hw_prober_probe,
+ .driver = {
+ .name = DRV_NAME,
+ },
+};
+
+static int __init hw_prober_driver_init(void)
+{
+ struct platform_device *pdev;
+ int ret;
+
+ ret = platform_driver_register(&hw_prober_driver);
+ if (ret)
+ return ret;
+
+ pdev = platform_device_register_simple(DRV_NAME, -1, NULL, 0);
+ if (!IS_ERR(pdev))
+ return 0;
+
+ platform_driver_unregister(&hw_prober_driver);
+
+ return PTR_ERR(pdev);
+}
+device_initcall(hw_prober_driver_init);
--
2.42.0.869.gea05f2083d-goog
^ permalink raw reply related
* [RFC PATCH v2 1/7] of: base: Add of_device_is_fail
From: Chen-Yu Tsai @ 2023-11-09 10:05 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Hsin-Yi Wang, Dmitry Torokhov, andriy.shevchenko, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, petr.tesarik.ext, rafael, tglx, Jeff LaBundy,
linux-input, Chen-Yu Tsai, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold
In-Reply-To: <20231109100606.1245545-1-wenst@chromium.org>
In some cases we want to check that a device is not only unavailable,
but specifically marked as "fail".
This will be used in a following change in the hardware prober driver.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/of/base.c | 20 ++++++++++++++++++++
include/linux/of.h | 6 ++++++
2 files changed, 26 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 8d93cb6ea9cd..2726e5dce1bf 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -486,6 +486,26 @@ static bool __of_device_is_fail(const struct device_node *device)
return !strcmp(status, "fail") || !strncmp(status, "fail-", 5);
}
+/**
+ * of_device_is_fail - check if a device has status "fail" or "fail-..."
+ *
+ * @device: Node to check status for
+ *
+ * Return: True if the status property is set to "fail" or "fail-..." (for any
+ * error code suffix), false otherwise
+ */
+bool of_device_is_fail(const struct device_node *device)
+{
+ unsigned long flags;
+ bool res;
+
+ raw_spin_lock_irqsave(&devtree_lock, flags);
+ res = __of_device_is_fail(device);
+ raw_spin_unlock_irqrestore(&devtree_lock, flags);
+ return res;
+}
+EXPORT_SYMBOL(of_device_is_fail);
+
/**
* of_device_is_big_endian - check if a device has BE registers
*
diff --git a/include/linux/of.h b/include/linux/of.h
index 6a9ddf20e79a..463fbf0072bd 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -350,6 +350,7 @@ extern int of_device_is_compatible(const struct device_node *device,
extern int of_device_compatible_match(const struct device_node *device,
const char *const *compat);
extern bool of_device_is_available(const struct device_node *device);
+extern bool of_device_is_fail(const struct device_node *device);
extern bool of_device_is_big_endian(const struct device_node *device);
extern const void *of_get_property(const struct device_node *node,
const char *name,
@@ -584,6 +585,11 @@ static inline bool of_device_is_available(const struct device_node *device)
return false;
}
+static inline bool of_device_is_fail(const struct device_node *device)
+{
+ return false;
+}
+
static inline bool of_device_is_big_endian(const struct device_node *device)
{
return false;
--
2.42.0.869.gea05f2083d-goog
^ permalink raw reply related
* [RFC PATCH v2 0/7] of: Introduce hardware prober driver
From: Chen-Yu Tsai @ 2023-11-09 10:05 UTC (permalink / raw)
To: Rob Herring, Frank Rowand, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Hsin-Yi Wang, Dmitry Torokhov, andriy.shevchenko, Jiri Kosina,
linus.walleij, broonie, gregkh, hdegoede, james.clark, james,
keescook, petr.tesarik.ext, rafael, tglx, Jeff LaBundy,
linux-input, Chen-Yu Tsai, devicetree, linux-arm-kernel,
linux-mediatek, linux-kernel, Douglas Anderson, Johan Hovold
Hi everyone,
This v2 series continues Doug's "of: device: Support 2nd sources of
probeable but undiscoverable devices" [1] series, but follows the scheme
suggested by Rob, marking all second source component device nodes
as "fail-needs-probe-XXX", and having a hardware prober driver enable
the one of them. I tried to include everyone from the original Cc: list.
Please let me know if you would like to be dropped from future
submissions.
For the I2C component (touchscreens and trackpads) case from the
original series, the hardware prober driver finds the particular
class of device in the device tree, gets its parent I2C adapter,
and tries to initiate a simple I2C read for each device under that
I2C bus. When it finds one that responds, it considers that one
present, marks it as "okay", and returns, letting the driver core
actually probe the device.
This works fine in most cases since these components are connected
via ribbon cable and always have the same resources. The driver as
implemented currently doesn't deal with regulators or GPIO pins,
since in the existing device trees they are either always on for
regulators, or have GPIO hogs or pinmux and pinconfig directly
tied to the pin controller.
Another case this driver could handle is selecting components based
on some identifier passed in by the firmware. On Chromebooks we have
a SKU ID which is inserted by the bootloader at
/firmware/coreboot/sku-id. When a new combination of components is
introduced, a new SKU ID is allocated to it. To have SKU ID based
device trees, we would need to have one per SKU ID. This ends up
increasing the number of device trees we have a lot. The recent
MT8186 devices already have 10+10 SKUs [2], with possibly more to come.
Instead, we could have just one device tree for each device, with
component options listed and marked as "fail-needs-probe-XXX", and
let the hardware prober enable one of them based on the given SKU ID.
The driver will also fix up OF graph remote endpoints to point to the
enabled component.
The MT8186 Corsola series [2] can also benefit from this, though I
haven't implemented anything yet.
Patch 1 adds of_device_is_fail() for the new driver to use.
Patch 2 implements the first case, probing the I2C bus for presence
of components. This initial version targets the Hana Chromebooks.
Patch 3 modifies the Hana device tree and marks the touchscreens
and trackpads as "fail-needs-probe-XXX", ready for the driver to
probe.
Patch 4 adds a missing touchscreen variant to Hana.
Patch 5 implements the second case, selectively enabling components
based on the SKU ID. This initial version targets the Krane ChromeOS
tablet, which has two possible MIPI DSI display panel options.
Patch 6 drops Krane's SKU-specific compatible strings from the bindings.
Patch 7 merges Krane's SKU-specific device trees into one, with the
device tree now containing two possible panels. This unfortunately
introduces a dtc warning:
arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dts:81.13-83.6:
Warning (graph_endpoint): /soc/dsi@14014000/panel2@0/port/endpoint:
graph connection to node '/soc/dsi@14014000/ports/port/endpoint'
is not bidirectional
Please take a look.
Johan, I'm not sure if this works as is for the Lenovo Thinkpad 13S
case, since it looks like the trackpad shares the I2C bus with the
keyboard.
Thanks
ChenYu
Background as given in Doug's cover letter:
Support for multiple "equivalent" sources for components (also known
as second sourcing components) is a standard practice that helps keep
cost down and also makes sure that if one component is unavailable due
to a shortage that we don't need to stop production for the whole
product.
Some components are very easy to second source. eMMC, for instance, is
fully discoverable and probable so you can stuff a wide variety of
similar eMMC chips on your board and things will work without a hitch.
Some components are more difficult to second source, specifically
because it's difficult for software to probe what component is present
on any given board. In cases like this software is provided
supplementary information to help it, like a GPIO strap or a SKU ID
programmed into an EEPROM. This helpful information can allow the
bootloader to select a different device tree. The various different
"SKUs" of different Chromebooks are examples of this.
Some components are somewhere in between. These in-between components
are the subject of this patch. Specifically, these components are
easily "probeable" but not easily "discoverable".
A good example of a probeable but undiscoverable device is an
i2c-connected touchscreen or trackpad. Two separate components may be
electrically compatible with each other and may have compatible power
sequencing requirements but may require different software. If
software is told about the different possible components (because it
can't discover them), it can safely probe them to figure out which
ones are present.
On systems using device tree, if we want to tell the OS about all of
the different components we need to list them all in the device
tree. This leads to a problem. The multiple sources for components
likely use the same resources (GPIOs, interrupts, regulators). If the
OS tries to probe all of these components at the same time then it
will detect a resource conflict and that's a fatal error.
The fact that Linux can't handle these probeable but undiscoverable
devices well has had a few consequences:
1. In some cases, we've abandoned the idea of second sourcing
components for a given board, which increases cost / generates
manufacturing headaches.
2. In some cases, we've been forced to add some sort of strapping /
EEPROM to indicate which component is present. This adds difficulty
to manufacturing / refurb processes.
3. In some cases, we've managed to make things work by the skin of our
teeth through slightly hacky solutions. Specifically, if we remove
the "pinctrl" entry from the various options then it won't
conflict. Regulators inherently can have more than one consumer, so
as long as there are no GPIOs involved in power sequencing and
probing devices then things can work. This is how
"sc8280xp-lenovo-thinkpad-x13s" works and also how
"mt8173-elm-hana" works.
End of background from Doug's cover letter.
[1] https://lore.kernel.org/all/20230921102420.RFC.1.I9dddd99ccdca175e3ceb1b9fa1827df0928c5101@changeid/
[2] https://lore.kernel.org/linux-mediatek/20231012230237.2676469-1-wenst@chromium.org/
Chen-Yu Tsai (7):
of: base: Add of_device_is_fail
of: Introduce hardware prober driver
arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads
as fail
arm64: dts: mediatek: mt8173-elm-hana: Add G2touch G7500 touchscreen
of: hw_prober: Support Chromebook SKU ID based component selection
dt-bindings: arm: mediatek: Remove SKU specific compatibles for Google
Krane
arm64: dts: mediatek: mt8183-kukui: Merge Krane device trees
.../devicetree/bindings/arm/mediatek.yaml | 3 -
arch/arm64/boot/dts/mediatek/Makefile | 3 +-
.../boot/dts/mediatek/mt8173-elm-hana.dtsi | 20 ++
.../dts/mediatek/mt8183-kukui-krane-sku0.dts | 24 --
.../mediatek/mt8183-kukui-krane-sku176.dts | 24 --
...ukui-krane.dtsi => mt8183-kukui-krane.dts} | 47 ++-
drivers/of/Kconfig | 13 +
drivers/of/Makefile | 1 +
drivers/of/base.c | 20 ++
drivers/of/hw_prober.c | 314 ++++++++++++++++++
include/linux/of.h | 6 +
11 files changed, 418 insertions(+), 57 deletions(-)
delete mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku0.dts
delete mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
rename arch/arm64/boot/dts/mediatek/{mt8183-kukui-krane.dtsi => mt8183-kukui-krane.dts} (86%)
create mode 100644 drivers/of/hw_prober.c
--
2.42.0.869.gea05f2083d-goog
^ permalink raw reply
* [git pull] Input updates for v6.7-rc0
From: Dmitry Torokhov @ 2023-11-09 8:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v6.7-rc0
to receive updates for the input subsystem. You will get:
- a number of input drivers has been converted to use facilities provided
by the device core to instantiate driver-specific attributes instead of
using devm_device_add_group() and similar APIs
- platform input devices have been converted to use remove() callback
returning void
- a fix for use-after-free when tearing down a Synaptics RMI device
- a few flexible arrays in input structures have been annotated with
__counted_by to help hardening efforts
- handling of vddio supply in cyttsp5 driver
- other miscellaneous fixups
Changelog:
---------
Dan Carpenter (1):
Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
Dmitry Torokhov (22):
Input: cros_ec_keyb - use device core to create driver-specific device attributes
Input: cyapa - use device core to create driver-specific device attributes
Input: iqs269a - use device core to create driver-specific device attributes
Input: kxtj9 - use device core to create driver-specific device attributes
Input: ad7877 - use device core to create driver-specific device attributes
Input: ad7879 - use device core to create driver-specific device attributes
Input: ads7846 - use device core to create driver-specific device attributes
Input: edt-ft5x06 - use device core to create driver-specific device attributes
Input: elants_i2c - use device core to create driver-specific device attributes
Input: exc3000 - use device core to create driver-specific device attributes
Input: hideep - use device core to create driver-specific device attributes
Input: hycon-hy46xx - use device core to create driver-specific device attributes
Input: ili210x - use device core to create driver-specific device attributes
Input: ilitek_ts_i2c - use device core to create driver-specific device attributes
Input: iqs5xx - use device core to create driver-specific device attributes
Input: melfas-mip4 - use device core to create driver-specific device attributes
Input: raydium_i2c_ts - use device core to create driver-specific device attributes
Input: rohm_bu21023 - use device core to create driver-specific device attributes
Input: s6sy761 - use device core to create driver-specific device attributes
Input: stmfts - use device core to create driver-specific device attributes
Input: tsc2004/5 - use device core to create driver-specific device attributes
Input: wdt87xx_i2c - use device core to create driver-specific device attributes
Fabio Estevam (1):
dt-bindings: input: fsl,scu-key: Document wakeup-source
Justin Stitt (2):
Input: synaptics-rmi4 - replace deprecated strncpy
Input: axp20x-pek - avoid needless newline removal
Kees Cook (4):
Input: evdev - annotate struct evdev_client with __counted_by
Input: leds - annotate struct input_leds with __counted_by
Input: mt - annotate struct input_mt with __counted_by
Input: Annotate struct ff_device with __counted_by
Li Zetao (1):
Input: walkera0701 - use module_parport_driver macro to simplify the code
Lin, Meng-Bo (2):
dt-bindings: input: cyttsp5: document vddio-supply
Input: cyttsp5 - add handling for vddio regulator
Rob Herring (1):
Input: tegra-kbc - use device_get_match_data()
Uwe Kleine-König (52):
Input: adp5520-keys - convert to platform remove callback returning void
Input: cros_ec_keyb - convert to platform remove callback returning void
Input: ep93xx_keypad - convert to platform remove callback returning void
Input: iqs62x-keys - convert to platform remove callback returning void
Input: matrix_keypad - convert to platform remove callback returning void
Input: omap-keypad - convert to platform remove callback returning void
Input: omap4-keypad - convert to platform remove callback returning void
Input: samsung-keypad - convert to platform remove callback returning void
Input: sh_keysc - convert to platform remove callback returning void
Input: spear-keyboard - convert to platform remove callback returning void
Input: stmpe-keypad - convert to platform remove callback returning void
Input: 88pm80x_onkey - convert to platform remove callback returning void
Input: da9052_onkey - convert to platform remove callback returning void
Input: da9055_onkey - convert to platform remove callback returning void
Input: ideapad_slidebar - convert to platform remove callback returning void
Input: m68kspkr - convert to platform remove callback returning void
Input: max8997_haptic - convert to platform remove callback returning void
Input: mc13783-pwrbutton - convert to platform remove callback returning void
Input: palmas-pwrbutton - convert to platform remove callback returning void
Input: pcap_keys - convert to platform remove callback returning void
Input: pcf50633-input - convert to platform remove callback returning void
Input: pcspkr - convert to platform remove callback returning void
Input: pm8941-pwrkey - convert to platform remove callback returning void
Input: soc_button_array - convert to platform remove callback returning void
Input: sparcspkr - convert to platform remove callback returning void
Input: wistron_btns - convert to platform remove callback returning void
Input: wm831x-on - convert to platform remove callback returning void
Input: navpoint - convert to platform remove callback returning void
Input: altera_ps2 - convert to platform remove callback returning void
Input: ams_delta_serio - convert to platform remove callback returning void
Input: apbps2 - convert to platform remove callback returning void
Input: arc_ps2 - convert to platform remove callback returning void
Input: ct82c710 - convert to platform remove callback returning void
Input: i8042-sparcio - convert to platform remove callback returning void
Input: i8042 - convert to platform remove callback returning void
Input: ioc3kbd - convert to platform remove callback returning void
Input: maceps2 - convert to platform remove callback returning void
Input: olpc_apsp - convert to platform remove callback returning void
Input: ps2-gpio - convert to platform remove callback returning void
Input: q40kbd - convert to platform remove callback returning void
Input: rpckbd - convert to platform remove callback returning void
Input: sun4i-ps2 - convert to platform remove callback returning void
Input: xilinx_ps2 - convert to platform remove callback returning void
Input: da9052_tsi - convert to platform remove callback returning void
Input: mainstone-wm97xx - convert to platform remove callback returning void
Input: mc13783_ts - convert to platform remove callback returning void
Input: pcap_ts - convert to platform remove callback returning void
Input: stmpe-ts - convert to platform remove callback returning void
Input: sun4i-ts - convert to platform remove callback returning void
Input: ti_am335x_tsc - convert to platform remove callback returning void
Input: wm831x-ts - convert to platform remove callback returning void
Input: wm97xx-core - convert to platform remove callback returning void
Diffstat:
--------
.../devicetree/bindings/input/fsl,scu-key.yaml | 2 ++
.../input/touchscreen/cypress,tt21000.yaml | 3 +++
drivers/input/evdev.c | 2 +-
drivers/input/input-leds.c | 2 +-
drivers/input/joystick/walkera0701.c | 13 +---------
drivers/input/keyboard/adp5520-keys.c | 6 ++---
drivers/input/keyboard/cros_ec_keyb.c | 16 ++++--------
drivers/input/keyboard/ep93xx_keypad.c | 6 ++---
drivers/input/keyboard/iqs62x-keys.c | 6 ++---
drivers/input/keyboard/matrix_keypad.c | 6 ++---
drivers/input/keyboard/omap-keypad.c | 6 ++---
drivers/input/keyboard/omap4-keypad.c | 6 ++---
drivers/input/keyboard/samsung-keypad.c | 6 ++---
drivers/input/keyboard/sh_keysc.c | 6 ++---
drivers/input/keyboard/spear-keyboard.c | 6 ++---
drivers/input/keyboard/stmpe-keypad.c | 6 ++---
drivers/input/keyboard/tegra-kbc.c | 7 ++----
drivers/input/misc/88pm80x_onkey.c | 5 ++--
drivers/input/misc/axp20x-pek.c | 11 +-------
drivers/input/misc/da9052_onkey.c | 6 ++---
drivers/input/misc/da9055_onkey.c | 6 ++---
drivers/input/misc/ideapad_slidebar.c | 6 ++---
drivers/input/misc/iqs269a.c | 10 ++------
drivers/input/misc/kxtj9.c | 29 +++++++++++++---------
drivers/input/misc/m68kspkr.c | 6 ++---
drivers/input/misc/max8997_haptic.c | 6 ++---
drivers/input/misc/mc13783-pwrbutton.c | 6 ++---
drivers/input/misc/palmas-pwrbutton.c | 6 ++---
drivers/input/misc/pcap_keys.c | 6 ++---
drivers/input/misc/pcf50633-input.c | 6 ++---
drivers/input/misc/pcspkr.c | 6 ++---
drivers/input/misc/pm8941-pwrkey.c | 6 ++---
drivers/input/misc/soc_button_array.c | 6 ++---
drivers/input/misc/sparcspkr.c | 12 +++------
drivers/input/misc/wistron_btns.c | 6 ++---
drivers/input/misc/wm831x-on.c | 6 ++---
drivers/input/mouse/cyapa.c | 14 +++--------
drivers/input/mouse/navpoint.c | 6 ++---
drivers/input/rmi4/rmi_bus.c | 2 +-
drivers/input/rmi4/rmi_f34.c | 2 +-
drivers/input/serio/altera_ps2.c | 6 ++---
drivers/input/serio/ams_delta_serio.c | 6 ++---
drivers/input/serio/apbps2.c | 6 ++---
drivers/input/serio/arc_ps2.c | 6 ++---
drivers/input/serio/ct82c710.c | 6 ++---
drivers/input/serio/i8042-sparcio.h | 6 ++---
drivers/input/serio/i8042.c | 6 ++---
drivers/input/serio/ioc3kbd.c | 6 ++---
drivers/input/serio/maceps2.c | 6 ++---
drivers/input/serio/olpc_apsp.c | 6 ++---
drivers/input/serio/ps2-gpio.c | 5 ++--
drivers/input/serio/q40kbd.c | 6 ++---
drivers/input/serio/rpckbd.c | 6 ++---
drivers/input/serio/sun4i-ps2.c | 6 ++---
drivers/input/serio/xilinx_ps2.c | 6 ++---
drivers/input/touchscreen/ad7877.c | 12 ++++-----
drivers/input/touchscreen/ad7879-i2c.c | 7 +++---
drivers/input/touchscreen/ad7879-spi.c | 7 +++---
drivers/input/touchscreen/ad7879.c | 10 +++++---
drivers/input/touchscreen/ad7879.h | 3 +++
drivers/input/touchscreen/ads7846.c | 18 +++++---------
drivers/input/touchscreen/cyttsp5.c | 19 ++++++++------
drivers/input/touchscreen/da9052_tsi.c | 6 ++---
drivers/input/touchscreen/edt-ft5x06.c | 10 ++------
drivers/input/touchscreen/elants_i2c.c | 15 +++--------
drivers/input/touchscreen/exc3000.c | 12 +++------
drivers/input/touchscreen/hideep.c | 15 +++--------
drivers/input/touchscreen/hycon-hy46xx.c | 10 ++------
drivers/input/touchscreen/ili210x.c | 15 ++++-------
drivers/input/touchscreen/ilitek_ts_i2c.c | 12 ++-------
drivers/input/touchscreen/iqs5xx.c | 10 +++-----
drivers/input/touchscreen/mainstone-wm97xx.c | 6 ++---
drivers/input/touchscreen/mc13783_ts.c | 6 ++---
drivers/input/touchscreen/melfas_mip4.c | 13 ++--------
drivers/input/touchscreen/pcap_ts.c | 6 ++---
drivers/input/touchscreen/raydium_i2c_ts.c | 16 +++---------
drivers/input/touchscreen/rohm_bu21023.c | 12 ++-------
drivers/input/touchscreen/s6sy761.c | 10 ++------
drivers/input/touchscreen/stmfts.c | 10 ++------
drivers/input/touchscreen/stmpe-ts.c | 6 ++---
drivers/input/touchscreen/sun4i-ts.c | 6 ++---
drivers/input/touchscreen/ti_am335x_tsc.c | 5 ++--
drivers/input/touchscreen/tsc2004.c | 7 +++---
drivers/input/touchscreen/tsc2005.c | 7 +++---
drivers/input/touchscreen/tsc200x-core.c | 18 ++++++--------
drivers/input/touchscreen/tsc200x-core.h | 1 +
drivers/input/touchscreen/wdt87xx_i2c.c | 16 +++---------
drivers/input/touchscreen/wm831x-ts.c | 6 ++---
drivers/input/touchscreen/wm97xx-core.c | 6 ++---
include/linux/input.h | 2 +-
include/linux/input/mt.h | 2 +-
91 files changed, 240 insertions(+), 471 deletions(-)
Thanks.
--
Dmitry
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS cdd5b5a9761fd66d17586e4f4ba6588c70e640ea
From: kernel test robot @ 2023-11-09 4:43 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: cdd5b5a9761fd66d17586e4f4ba6588c70e640ea Merge branch 'next' into for-linus
elapsed time: 3076m
configs tested: 139
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20231108 gcc
arc randconfig-002-20231108 gcc
arm allmodconfig gcc
arm allnoconfig gcc
arm defconfig gcc
arm64 allnoconfig gcc
arm64 defconfig gcc
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20231108 gcc
csky randconfig-002-20231108 gcc
i386 allmodconfig gcc
i386 allnoconfig gcc
i386 allyesconfig gcc
i386 buildonly-randconfig-001-20231108 gcc
i386 buildonly-randconfig-002-20231108 gcc
i386 buildonly-randconfig-003-20231108 gcc
i386 buildonly-randconfig-004-20231108 gcc
i386 buildonly-randconfig-005-20231108 gcc
i386 buildonly-randconfig-006-20231108 gcc
i386 defconfig gcc
i386 randconfig-001-20231108 gcc
i386 randconfig-002-20231108 gcc
i386 randconfig-003-20231108 gcc
i386 randconfig-004-20231108 gcc
i386 randconfig-005-20231108 gcc
i386 randconfig-006-20231108 gcc
i386 randconfig-011-20231108 gcc
i386 randconfig-012-20231108 gcc
i386 randconfig-013-20231108 gcc
i386 randconfig-014-20231108 gcc
i386 randconfig-015-20231108 gcc
i386 randconfig-016-20231108 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch allyesconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20231108 gcc
loongarch randconfig-002-20231108 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allmodconfig gcc
mips allnoconfig gcc
mips allyesconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20231108 gcc
nios2 randconfig-002-20231108 gcc
openrisc allmodconfig gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20231108 gcc
parisc randconfig-002-20231108 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc allyesconfig gcc
powerpc randconfig-001-20231108 gcc
powerpc randconfig-002-20231108 gcc
powerpc randconfig-003-20231108 gcc
powerpc64 randconfig-001-20231108 gcc
powerpc64 randconfig-002-20231108 gcc
powerpc64 randconfig-003-20231108 gcc
riscv defconfig gcc
riscv randconfig-001-20231108 gcc
riscv randconfig-002-20231108 gcc
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allnoconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-001-20231108 gcc
s390 randconfig-002-20231108 gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh randconfig-001-20231108 gcc
sh randconfig-002-20231108 gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc allyesconfig gcc
sparc defconfig gcc
sparc randconfig-001-20231108 gcc
sparc randconfig-002-20231108 gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20231108 gcc
sparc64 randconfig-002-20231108 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um randconfig-001-20231108 gcc
um randconfig-002-20231108 gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 buildonly-randconfig-001-20231108 gcc
x86_64 buildonly-randconfig-002-20231108 gcc
x86_64 buildonly-randconfig-003-20231108 gcc
x86_64 buildonly-randconfig-004-20231108 gcc
x86_64 buildonly-randconfig-005-20231108 gcc
x86_64 buildonly-randconfig-006-20231108 gcc
x86_64 defconfig gcc
x86_64 randconfig-001-20231109 gcc
x86_64 randconfig-002-20231109 gcc
x86_64 randconfig-003-20231109 gcc
x86_64 randconfig-004-20231109 gcc
x86_64 randconfig-005-20231109 gcc
x86_64 randconfig-006-20231109 gcc
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa randconfig-001-20231108 gcc
xtensa randconfig-002-20231108 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: Requesting your attention and expertise regarding a Tablet/Kernel issue
From: David Revoy @ 2023-11-09 0:32 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: José Expósito, Eric GOUYER, Illia Ostapyshyn, jkosina,
jason.gerecke, linux-input, linux-kernel
In-Reply-To: <CAO-hwJKNcwcDGEh33NZq4kSYtoxZzg9M2nzE_hVDYNFgA4g_dg@mail.gmail.com>
Hi Benjamin,
> Alright, I made quite some progress so far:
> - regressions tests have been written (branch wip/xp-pen of my fork on
> freedesktop[0])
> that branch can not go in directly as it just adds the tests, and
> thus is failing
> - I made the fixes through HID-BPF[1]
>
> Anyone using those 2 tablets and using Fedora should be able to just
> grab the artifact at [2], uncompress it and run `sudo ./install.sh --verbose`.
> This will install the bpf programs in /lib/firmware/hid/bpf/ and will
> automatically load them when the device is connected.
>
> For those not using Fedora, the binary might work (or not, not sure),
> but you can always decompress it, and check if running
> `udev-hid-bpf_0.1.0/bin/udev-hid-bpf --version` returns the correct
> version or just fails. If you get "udev-hid-bpf 0.1.0", then running
> `sudo ./install.sh --verbose` should work, as long as the kernel has
> CONFIG_HID_BPF set to 'Y'.
> [...]
> [0] https://gitlab.freedesktop.org/bentiss/hid/-/tree/wip/xp-pen?ref_type=heads
> [1] https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/27
> [2] https://gitlab.freedesktop.org/bentiss/udev-hid-bpf/-/jobs/51350589/artifacts/raw/udev-hid-bpf_0.1.0.tar.xz
Thank you for this package.
I was able to test it even though the link in (2) at the bottom of your email returned a blank page. I was able to find my way after manually visiting gitlab.freedesktop.org [1] and then manually downloading the article from 51350589. I unzipped it and ran `sudo ./install.sh --verbose`. Everything looks like it was successful [2]. I then rebooted my Fedora 38 'Linux workstation 6.5.8-200.fc38.x86_64' kernel (the one I blamed in my post) and tested both tablets.
Here are my observation:
XPPEN Artist Pro 24
===================
Nothing changed for this device (it's the one with two buttons and no 'eraser tip'). Nor my hwdb/udev rules or `xsetwacom set "UGTABLET 24 inch PenDisplay eraser" button 1 3` affects the upper button of the stylus: if I hold it hover the canvas, Krita switch the tool and cursor for an eraser. If I click on the canvas with the pen tip while holding the upper button pressed, I get the right-click Pop-up Palette (but not all the time, probably Krita has hard time to triage Eraser or Right-click).
XPPEN Artist Pro 16 (Gen2)
==========================
Something changed. `xsetwacom set "UGTABLET Artist Pro 16 (Gen2) eraser" button 1 3` successfully affected the upper button of the stylus. Now if I click it while hovering the canvas, Krita shows the right click Pop-up Palette.
On the downside; the real eraser tip when I flip the stylus bugs. When I flip the stylus on eraser hovering the canvas, Krita shows the Eraser icon and switch tool. As soon as I draw with the eraser tip, Krita will also show a right-click color palette and with also not a 100% consistency, as if the event were mixed.
[1] https://gitlab.freedesktop.org/bentiss/udev-hid-bpf/-/artifacts
[2] https://www.peppercarrot.com/extras/temp/2023-11-09_screenshot_005214_net.jpg
On Wednesday, November 8th, 2023 at 19:21, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
> On Wed, Nov 8, 2023 at 10:34 AM Benjamin Tissoires
> benjamin.tissoires@redhat.com wrote:
>
> > On Wed, Nov 8, 2023 at 10:23 AM José Expósito jose.exposito89@gmail.com wrote:
> >
> > > Hi Benjamin,
> > >
> > > On Wed, Nov 08, 2023 at 10:04:30AM +0100, Benjamin Tissoires wrote:
> > > [...]
> > >
> > > > > So, the behavior probably breaks the specs, but sincerely I'm happy to
> > > > > have the "eraser" button independent of the "rubber eraser", which
> > > > > makes the stylus a somewhat 4-buttons stylus (tip, button1, button2,
> > > > > rubber), and I would like to keep this.
> > > >
> > > > Yes, and I'd like to keep it that way, even if 6.6 and 6.5.8
> > > > apparently broke it.
> > > >
> > > > So, to me:
> > > > - 276e14e6c3993317257e1787e93b7166fbc30905 is wrong: this is a
> > > > firmware bug (reporting invert through eraser) and should not be
> > > > tackled at the generic level, thus it should be reverted
> > > > - both of these tablets are forwarding the useful information, but not
> > > > correctly, which confuses the kernel
> > > > - I should now be able to write regression tests
> > > > - I should be able to provide HID-BPF fixes for those tablets so that
> > > > we can keep them working with or without
> > > > 276e14e6c3993317257e1787e93b7166fbc30905
> > > > reverted (hopefully)
> > > > - problem is I still don't have the mechanics to integrate the HID-BPF
> > > > fixes directly in the kernel tree, so maybe I'll have to write a
> > > > driver for XP-Pen while these internals are set (it shouldn't
> > > > interfere with the HID-BPF out of the tree).
> > >
> > > I already added support for a few XP-Pen devices on the UCLogic driver
> > > and I was planning to start working on this one during the weekend in
> > > my DIGImend fork (to simplify testing).
> > >
> > > Let me know if you prefer to add it yourself or if you want me to ping
> > > you in the DIGImend discussion.
> >
> > So far, I really have to work on this now. It's a good use case for
> > HID-BPF and it's a regression that I'd like to be fixed ASAP.
> > I'd appreciate any reviews :)
>
>
> Alright, I made quite some progress so far:
> - regressions tests have been written (branch wip/xp-pen of my fork on
> freedesktop[0])
> that branch can not go in directly as it just adds the tests, and
> thus is failing
> - I made the fixes through HID-BPF[1]
>
> Anyone using those 2 tablets and using Fedora should be able to just
> grab the artifact at [2], uncompress it and run `sudo ./install.sh --verbose`.
> This will install the bpf programs in /lib/firmware/hid/bpf/ and will
> automatically load them when the device is connected.
>
> For those not using Fedora, the binary might work (or not, not sure),
> but you can always decompress it, and check if running
> `udev-hid-bpf_0.1.0/bin/udev-hid-bpf --version` returns the correct
> version or just fails. If you get "udev-hid-bpf 0.1.0", then running
> `sudo ./install.sh --verbose` should work, as long as the kernel has
> CONFIG_HID_BPF set to 'Y'.
>
> > Also, good to know that I can probably piggyback on hid-uclogic for
> > fixing those 2 devices in the kernel.
>
>
> Next step will be to fix them using a kernel driver, but it seems that
> the uclogic driver is doing more than just report descriptor fixups,
> so maybe I'll have to use a different driver.
> But the point is, in theory, if you are affected by those bugs, using
> the udev-hid-bpf should fix the issue, and this should also be
> resilient to further kernel updates.
>
> I'd appreciate testing when I got the full kernel series up and ready,
> of course.
>
> Cheers,
> Benjamin
>
> [0] https://gitlab.freedesktop.org/bentiss/hid/-/tree/wip/xp-pen?ref_type=heads
> [1] https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/27
> [2] https://gitlab.freedesktop.org/bentiss/udev-hid-bpf/-/jobs/51350589/artifacts/raw/udev-hid-bpf_0.1.0.tar.xz
^ permalink raw reply
* Re: Requesting your attention and expertise regarding a Tablet/Kernel issue
From: David Revoy @ 2023-11-08 23:18 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Illia Ostapyshyn, jkosina, jason.gerecke, jose.exposito89,
linux-input, linux-kernel, nils, peter.hutterer, ping.cheng,
bagasdotme
In-Reply-To: <CAO-hwJKVwZK00yZFjuyyR9Xt4Y2-r8eLJNZfnyeopHxoZQ0eGA@mail.gmail.com>
> BTW, David, were you able to do a revert of 276e14e6c3?
I'm sorry Benjamin: I did some research on how to build a kernel [1], on how to revert a commit (easy, I know a bit of Git), and started following it step by step. Result: I failed and concluded that it probably requires too much computer knowledge compared to what I can do now. I'm afraid I won't be able to build a custom kernel for testing.
[1] https://docs.fedoraproject.org/en-US/quick-docs/kernel-build-custom/#_building_a_vanilla_upstream_kernel
On Tuesday, November 7th, 2023 at 08:59, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
> On Mon, Nov 6, 2023 at 9:06 PM Illia Ostapyshyn
> ostapyshyn@sra.uni-hannover.de wrote:
>
> > On 11/6/23 17:59, Benjamin Tissoires wrote:
> >
> > > If the pen has 2 buttons, and an eraser side, it would be a serious
> > > design flow for XPPEN to report both as eraser.
> > >
> > > Could you please use sudo hid-recorder from hid-tools[1] on any kernel
> > > version and send us the logs here?
> > > I'll be able to replay the events locally, and understand why the
> > > kernel doesn't work properly.
> > >
> > > And if there is a design flaw that can be fixed, we might even be able
> > > to use hid-bpf to change it :)
> >
> > My wild guess is that XP-Pen 16 Artist Pro reports an Eraser usage
> > without Invert for the upper button and Eraser with Invert for the
> > eraser tip. A device-specific driver could work with that, but there
> > seems to be no way to incorporate two different erasers (thus, allowing
> > userspace to map them to different actions arbitrarily) in the generic
> > driver currently.
>
>
> That's exactly why I want to see the exact event flow. We can not do
> "wild guesses" unfortunately (not meaning any offenses).
> And I am very suspicious about the fact that the stylus reports 2
> identical erasers. Because in the past David seemed to be able to have
> 2 distincts behaviors for the 2 "buttons" (physical button and eraser
> tail).
>
> > > Generally speaking, relying on X to fix your hardware is going to be a
> > > dead end. When you switch to wayland, you'll lose all of your fixes,
> > > which isn't great.
> >
> > > AFAIU, the kernel now "merges" both buttons, which is a problem. It
> > > seems to be a serious regression. This case is also worrying because I
> > > added regression tests on hid, but I don't have access to all of the
> > > various tablets, so I implemented them from the Microsoft
> > > specification[0]. We need a special case for you here.
> >
> > The issue preventing David from mapping HID_DG_ERASER to BTN_STYLUS2 is
> > that the hidinput_hid_event is not compatible with hidinput_setkeycode.
> > If usage->code is no longer BTN_TOUCH after remapping, it won't be
> > released when Eraser reports 0. A simple fix is:
>
>
> I must confess, being the one who refactored everything, I still don't
> believe this is as simple as it may seem. I paged out all of the
> special cases, and now, without seeing the event flow I just can not
> understand why this would fix the situation.
>
> And BTW, if you have a tool affected by 276e14e6c3, I'd be curious to
> get a hid-recorder sample for it so I can get regression tests for it.
>
> > --- a/drivers/hid/hid-input.c
> > +++ b/drivers/hid/hid-input.c
> > @@ -1589,7 +1589,7 @@ void hidinput_hid_event(struct hid_device *hid,
> > struct hid_field field, struct
> > / value is off, tool is not rubber, ignore */
> > return;
> > else if (*quirks & HID_QUIRK_NOINVERT &&
> > - !test_bit(BTN_TOUCH, input->key)) {
> > + !test_bit(usage->code, input->key)) {
>
>
> I don't want to be rude, but this feels very much like black magic,
> especially because there is a comment just below and it is not
> updated. So either the explanation was wrong, or it's not explaining
> the situation (I also understand that this is not a formal submission,
> so maybe that's the reason why the comment is not updated).
>
> > /*
> > * There is no invert to release the tool, let hid_input
> > * send BTN_TOUCH with scancode and release the tool after.
> >
> > This change alone fixes David's problem and the right-click mapping in
> > hwdb works again. However, the tool switches to rubber for the remapped
> > eraser (here BTN_STYLUS2) events, both for devices with and without
> > Invert. This does no harm but is not useful either. A cleaner solution
> > for devices without Invert would be to omit the whole tool switching
> > logic in this case:
> >
> > @@ -1577,6 +1577,9 @@ void hidinput_hid_event(struct hid_device *hid,
> > struct hid_field *field, struct
> >
> > switch (usage->hid) {
> > case HID_DG_ERASER:
> > + if (*quirks & HID_QUIRK_NOINVERT && usage->code != BTN_TOUCH)
> > + break;
> > +
> > report->tool_active |= !!value;
> >
> > Remapping Invert does not work anyway as the Invert tool is hardcoded in
> > hidinput_hid_event. Even worse, I guess (not tested) trying to do so
> > would mask BTN_TOOL_RUBBER from dev->keybit and could cause weird
> > behavior similar to one between 87562fcd1342 and 276e14e6c3. This
> > raises the question: should users be able to remap Invert after all?
>
>
> The kernel is supposed to transfer what the device is. So if it says
> this is an eraser, we should not try to change it. Users can then
> tweak their own device if they wish through hid-bpf or through
> libinput quirks, but when you install a fresh kernel without tweaks,
> we should be as accurate as possible.
>
> My main concern is that now we have a device which exports 2 different
> interactions as being the same. So either the firmware is wrong, and
> we need to quirk it, or the kernel is wrong and merges both, and this
> needs fixes as well.
>
> Once every interaction on the device gets its own behavior, userspace
> can do whatever they want. It's not the kernel's concern anymore.
>
> BTW, David, were you able to do a revert of 276e14e6c3?
>
> Cheers,
> Benjamin
^ permalink raw reply
* Re: Requesting your attention and expertise regarding a Tablet/Kernel issue
From: ostapyshyn @ 2023-11-08 22:31 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Nils Fuhler, davidrevoy, folays, jason.gerecke, jkosina,
jose.exposito89, linux-input, linux-kernel, ostapyshyn
In-Reply-To: <CAO-hwJ+b4q+8g=Cg5MRJQT2EsxkFZrK_XgJqmHWm=GBHskhDqQ@mail.gmail.com>
On 11/8/23 21:34, Benjamin Tissoires wrote:
> Again, you convinced me that this commit was wrong. If people needs to
> also use an ioctl to "fix" it, then there is something wrong.
I don't think we're on the same page here. Nobody needs to use an ioctl
to fix 276e14e6c3. Rather, the _exact opposite_: the bug reporter used
an ioctl to remap Eraser to BTN_STYLUS2. It stopped working after
276e14e6c3 and broke his workflow. He reported it as a regression,
starting this whole thread.
> Sorry but I tend to disagree. Relying on the ioctl EVIOCSKEYCODE for
> tuning the behavior of a state machine is just plain wrong. When
> people do that, they are doing it at the wrong level and introducing
> further bugs.
>
> The whole pen and touch HID protocols rely on a state machine. You
> just can not change the meaning of it because your hardware maker
> produced a faulty hardware.
>
> [...]
>
> In the same way, if you remap Tip Switch to KEY-A, you won't get
> clicks from your pen. Assuming you can do that with any event on any
> HID device is just plain wrong.
> That ioctl is OK-ish for "remapping" simple things like keys. In our
> case, the whole firmware follows a state machine, so we can not change
> it. It has to be remapped in a later layer, in libinput, your
> compositor, or in your end user application.
I don't disagree. Forbidding EVIOCSKEYCODE ioctls for pen and touch HID
is a legitimate way to resolve this (an appealing one too -- accounting
for it in hidinput_hid_event might be a hellish task).
Should we forbid remapping Eraser too? If your answer is yes, then we
can finish this conversation here and leave the code as it is now,
because __the regression__ is a user not being able to use an ioctl to
remap Eraser after 276e14e6c3. Otherwise, if we do make an exemption for
David's Eraser, the fix is as simple as replacing BTN_TOUCH with
usage->code on line 1594 of hid-input.c.
> How many of such devices do we have? Are they all UGTablet like the
> XP-PEN? Are they behaving properly on Windows without a proprietary
> driver?
>
> [...]
>
> I might buy the "invertless" devices are a thing if I can get more
> data about it. So far there are only 2 of them, and they add extra
> complexity in the code when we can just patch the devices to do the
> right thing.
There might or might not be more devices like this in the wild. It looks
like BarrelSwitch2 was added only 2013 [1], which is why so many styli
use Eraser for the second button. Setting two bits for a single button
just to adhere to Microsoft's *recommendation* is nice for compatibility,
but I can imagine vendors taking a shortcut and omitting Invert
altogether. The HID specification alone just lists the usages and says
nothing about how they relate to each other.
XP-Pen Artist 24 does work on Windows with the generic driver. The
Eraser engages as soon as the button is pressed, without touching the
screen.
> New hardware isn't supposed to be supported on an old kernel and is
> not considered as a regression. However, David mentioned that the
> device was "working" on 6.5.0 but broke in 6.5.8 with the patch
> mentioned above. This is a regression that needs to be tackled.
> Especially because it was introduced in 6.6 but backported into 6.5.
To make sure we're talking about the same thing:
1. "Broke" in this context means that the ioctl remapping from Eraser to
right-click stopped working.
2. XPPen 16 Pro Gen2 is a whole different topic, untouched by 276e14e6c3.
[1] https://www.usb.org/sites/default/files/hutrr46e.txt
^ permalink raw reply
* Re: Requesting your attention and expertise regarding a Tablet/Kernel issue
From: David Revoy @ 2023-11-08 22:28 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Illia Ostapyshyn, jkosina, jason.gerecke, jose.exposito89,
linux-input, linux-kernel, nils, peter.hutterer, ping.cheng,
bagasdotme
In-Reply-To: <CAO-hwJLpKTb9yxvxaPDLZkF9kDF8u2VRJUf9yiQd+neOyxPeug@mail.gmail.com>
Hi Benjamin,
Thanks for all the information.
> Could you please use sudo hid-recorder from hid-tools[1] on any kernel
> version and send us the logs here?
> I'll be able to replay the events locally, and understand why the
> kernel doesn't work properly.
> [1] https://gitlab.freedesktop.org/libevdev/hid-tools
Yes, I can. I've done it for the two tablets and you can find the file output hosted here:
https://www.peppercarrot.com/extras/?dir=mailing-list/hid-records
I followed the diagnostic method (for gestures) and file naming suggested in the short videos on this page:
https://digimend.github.io/support/howto/trbl/diagnostics/
I hope that it will be useful, even after the detailed feedback from Eric Gouyer (folays@gmail.com) on the ML (thank you).
> Generally speaking, relying on X to fix your hardware is going to be a
> dead end. When you switch to wayland, you'll lose all of your fixes,
> which isn't great.
You are right. I hope that the Wayland session will offer possible command line tools to customise devices. But that's another topic. :)
On Monday, November 6th, 2023 at 17:59, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
> Hi David,
>
> On Mon, Nov 6, 2023 at 2:18 PM David Revoy davidrevoy@protonmail.com wrote:
>
> > Hi Illia, Jiri, Bagas,
> >
> > Thanks to Jiri for forwarding my request for help to this mailing list.
> >
> > I apologise in advance to Bagas and you all for not being able to properly configure my email client to follow the correct etiquette (Protonmail, unsuitable for kernel development, but we've made some progress with them on Mastodon on the encryption issue 1).
>
>
> Hopefully you'll be able to figure out a way to have your emails
> posted to the lkml soon. It's very valuable to have them in
> lore.kernel.org to get the thread context.
>
> > Thanks to Illia for the detailed explanation. Thanks also for fixing it, and for explaining how the fix broke my workflow, and for your kind words about the situation. I appreciate it.
> >
> > However, after reading your reply, I still have my doubts about the preference to put an eraser on the top button of the pen by default. But after a few days and re-reading your first sentence "The XP-Pen hardware reports the Eraser usage for the upper stylus button.", I think I understood it: this is an internal signal that is sent by the device itself, and is therefore a specification that has to be followed, right? In this case, it makes sense for a generic driver to follow such a signal if it is sent by the hardware.
>
>
> Yes, you are correct. The device talks a given protocol (HID) and is
> supposed to use the specification from Microsoft[0] on how to behave
> properly. As such, it has to convey the "eraser" state by adding
> dedicated information in the event stream.
>
> In your case, I think we (the kernel and your stylus) simply talk past
> each other and we lose information.
>
> > Having said that, behaving like this still makes no sense in one case: I'm thinking of my other display tablet, the XPPEN 16 Artist Pro (Gen2). In this case, the stylus has the top button as an eraser, and an eraser tip as well, as you can see in this photo 2. Was it also a decision by XPPEN to include this signal in the hardware, knowing that they already had an eraser tip? In this case, please let me know, as it sounds like a hardware problem at the design stage and I have probably a way of passing on the information to their technical team.
>
>
> If the pen has 2 buttons, and an eraser side, it would be a serious
> design flow for XPPEN to report both as eraser.
>
> Could you please use sudo hid-recorder from hid-tools1 on any kernel
> version and send us the logs here?
> I'll be able to replay the events locally, and understand why the
> kernel doesn't work properly.
>
> And if there is a design flaw that can be fixed, we might even be able
> to use hid-bpf to change it :)
>
> > > You can still remap the eraser button to a right click using xsetwacom:
> > > xsetwacom set "UGTABLET 24 inch PenDisplay eraser" "Button" "1" "3"
> >
> > Unfortunately, it doesn't work.
> >
> > Firstly, such tablets are often connected to a computer that already has a display. So each device (pen/eraser) needs to be mapped to the correct display and set to the correct 'Area' for calibration. A better syntax in my case to test your workaround is written like this:
> >
> > tableteraser="UGTABLET 24 inch PenDisplay eraser"
> > xsetwacom set "$tableteraser" MapToOutput "DisplayPort-2"
> > xsetwacom set "$tableteraser" Area 100 120 32794 32797
> > xsetwacom set "$tableteraser" "Button" "1" "3"
> >
> > Secondly, forwarding the eraser button 1 to button 3 (a right click) in xsetwacom doesn't work.
> >
> > Pressing the button switches the device to an eraser and no right click happens. You'll need to hold down the button and click with the tip of the pen to create a right-click event.
> >
> > In a digital painting session in Krita, the software will switch your device to an eraser tool preset while you hold down the button, and the feedback on the canvas will be the eraser cursor. You'll then have to click "with the eraser" to get the right-click that triggers the pop-up palette 3.
> >
> > I'd also like to mention that if you haven't correctly mapped and calibrated your eraser device with xsetwacom, as I did in the code snippet above, the cursor will by default jump to a different location when you hold down the eraser button. It can be on a different display.
> >
> > Finally, in the case of the XPPEN 16 Artist Pro (Gen2) with a real eraser device (Photo, 2), the setting 'xsetwacom set "$tableteraser" "Button" "1" "3"' will affect both erasers. Flipping the stylus on the eraser side and entering in 'hover' mode will return a correct eraser, but as soon as you start erasing with the tip, a right click will also be entered.
> >
> > > You can also do this with "xinput set-button-map", which works for libinput as well.
> >
> > $ xinput list
> > ⎡ Virtual core pointer
> > ⎜ ↳ UGTABLET 24 inch PenDisplay Mouse id=8 [slave pointer (2)]
> > ⎜ ↳ UGTABLET 24 inch PenDisplay stylus id=10 [slave pointer (2)]
> > ⎜ ↳ UGTABLET 24 inch PenDisplay eraser id=17 [slave pointer (2)]
> > [...]
> > $ xinput get-button-map 17
> > 1 2 3 4 5 6 7 8
> > $ xinput set-button-map 17 3 3 3 3 3 3 3 3
> > $ xinput get-button-map 17
> > 3 3 3 3 3 3 3 3
> >
> > Even after that, it doesn't work. My original article 4 mentions in the last paragraph that I have tested almost all methods, and this was one of them. Even a udev rule doesn't fix it. For reference, xinput produces the same behaviour as xsetwacom: you have to hold the button (it triggers an eraser device switch) then click with the tip to get a right-click...
>
>
> Generally speaking, relying on X to fix your hardware is going to be a
> dead end. When you switch to wayland, you'll lose all of your fixes,
> which isn't great.
>
> > > We have tested this with several XP-Pen devices, including Artist 24.
> >
> > Sorry if my tests show something different. Maybe there is something wrong with my GNU/Linux operating system (Fedora 38 KDE spin). Let me know if you have any idea why I get these results and guide me with what distro I should switch to get a similar observation than you do (and also to report the issue to the Fedora team).
> >
> > ---
> >
> > All in all (and in the case that my observations and tests are correct), I still stand by the points that I made in my blog post:
> >
> > - I don't have any way to customise the hardcoded eraser buttons in userspace and it is a problem: for devices without a touchscreen or mouse, not having access to a right-click by default on the device is a handicap. Many actions on the D.E. and applications use the right click. The preference to replace it with an 'eraser switch' action by default is IMHO highly debatable here.
>
>
> AFAIU, the kernel now "merges" both buttons, which is a problem. It
> seems to be a serious regression. This case is also worrying because I
> added regression tests on hid, but I don't have access to all of the
> various tablets, so I implemented them from the Microsoft
> specification[0]. We need a special case for you here.
>
> > - In the case of a pen that already has an eraser tip on the other side of the device 2, it makes no sense to exchange the right-click top button for another way to erase. Also in userspace, there seems to be no way to distinguish between the two buttons (the eraser tip and the eraser button). All actions from xsetwacom, xinput/libinput target the two eraser devices, and they target them unsuccessfully too.
>
>
> Again, we can't do more than what the device reports. Well, we can
> always quirk it in some cases, but ideally we don't have to do
> anything. MS spec [0], only shows a single button pen with an eraser
> tail or a pen with 2 buttons, one of them being the eraser one. I'm
> not sure if they decided to prevent dual button pens with eraser tail,
> but Wacom definitely has some, and they work.
>
> Without the actual data from your pen, I can not tell much, because I
> don't follow which path we are taking on the kernel side. Please
> report with your hid-recorder logs, so I can understand why this is
> happening and how we can fix it.
>
> > ------- Original Message -------
> > On Friday, November 3rd, 2023 at 21:05, Illia Ostapyshyn ostapyshyn@sra.uni-hannover.de wrote:
> >
> > > Hello David, Hello Jiri,
> > >
> > > The XP-Pen hardware reports the Eraser usage for the upper stylus button.
> > > Generally, styli report Invert usages when erasing, as described in 1.
> > > XP-Pen digitizers, however, tend to omit them.
> > >
> > > The generic driver maps the Eraser usage to BTN_TOUCH and the Invert
> > > usage to BTN_TOOL_RUBBER. Pens conforming to 1 send the Invert usage
> > > first (switching the tool to BTN_TOOL_RUBBER) followed by Eraser, which
> > > appears in userspace as a BTN_TOUCH event with the rubber tool set.
> > >
> > > Due to an oversight, devices not reporting Invert had the BTN_TOOL_RUBBER
> > > event masked. This has caused the kernel to send only BTN_TOUCH events
> > > without the tool switch when erasing.
> > >
> > > The situation got worse with refactoring done in 87562fcd1342. An eraser
> > > without Invert caused the hidinput_hid_event state machine to get stuck
> > > with BTN_TOOL_RUBBER internally (due to it being masked). For the
> > > userspace, this looked as if the pen was never hovering again, rendering
> > > it unusable until the next reset. 276e14e6c3 fixes this by adding
> > > support for digitizers that do not report Invert usages when erasing.
>
>
> AFAICT 276e14e6c3 already had the hid tests integrated at
> tools/testing/selftests/hid/tests/test_tablet.py
>
> It would have been great to add the cases you are mentioning here,
> because there is a strong chance I'll break things once again when we
> try to fix that regression.
>
> > > ---
> > >
> > > David, we are sorry that our patch broke your workflow. However,
> > > forwarding hardware events as-is to the userspace has always been the
> > > intended behavior, with a kernel bug preventing it so far. You can still
> > > remap the eraser button to a right click using xsetwacom:
> > >
> > > xsetwacom set "UGTABLET 24 inch PenDisplay eraser" "Button" "1" "3"
> > >
> > > Replace the device name with the corresponding eraser device from
> > > "xsetwacom list devices". You can also do this with "xinput set-button-map",
> > > which works for libinput as well. We have tested this with several
> > > XP-Pen devices, including Artist 24.
> > >
> > > 1 https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-pen-states
>
>
> Cheers,
> Benjamin
>
> [0] https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-pen-states
> 1 https://gitlab.freedesktop.org/libevdev/hid-tools
^ permalink raw reply
* Re: [PATCH 0/7] HID: i2c-hid: Rework wait for reset to match Windows
From: Julian Sax @ 2023-11-08 20:41 UTC (permalink / raw)
To: Hans de Goede
Cc: Jiri Kosina, Benjamin Tissoires, Douglas Anderson, ahormann,
Bruno Jesus, Dietrich, kloxdami, Tim Aldridge, Rene Wagner,
Federico Ricchiuto, linux-input
In-Reply-To: <20231104111743.14668-1-hdegoede@redhat.com>
Am 04.11.23 um 12:17 schrieb Hans de Goede:
> Julian, I've added you to the Cc because you developed the code
> for touchpads where the HID report descriptors are missing and are
> provided by the kernel through a DMI quirk. The behavior for these
> touchpads should be unchanged, but if you can test on a laptop
> with such a touchpad that would be great.
>
Hi Hans,
I just tested the touchpad with these patches, everything still works fine.
Regards,
Julian
^ permalink raw reply
* Re: Requesting your attention and expertise regarding a Tablet/Kernel issue
From: Benjamin Tissoires @ 2023-11-08 20:34 UTC (permalink / raw)
To: Nils Fuhler
Cc: davidrevoy, folays, jason.gerecke, jkosina, jose.exposito89,
linux-input, linux-kernel, ostapyshyn
In-Reply-To: <20231108194051.279435-2-nils@nilsfuhler.de>
On Wed, Nov 8, 2023 at 8:41 PM Nils Fuhler <nils@nilsfuhler.de> wrote:
>
> Benjamin Tissoires <benjamin.tissoires@redhat.com> writes:
>
> > So, to me:
> > - 276e14e6c3993317257e1787e93b7166fbc30905 is wrong: this is a
> > firmware bug (reporting invert through eraser) and should not be
> > tackled at the generic level, thus it should be reverted
>
> Surely that can't be the solution. [1] is not a specification but a
> suggestion that many manufacturers seem to follow. Apparently, there
> are devices that directly report "erasing" for the upper button,
> skipping the whole "intent to erase" business. A questionable decision,
> but clearly intended.
How many of such devices do we have? Are they all UGTablet like the
XP-PEN? Are they behaving properly on Windows without a proprietary
driver?
We can try to make the code work based on suppositions, but this is
the first time I see such a behavior, so I'd prefer fix it when I see
it rather than adding complexity in the driver where changing anything
is hard. I'm writing regression tests for that exact same purpose.
>
> The evdev input protocol represents the erasing action as BTN_TOUCH with
> BTN_TOOL_RUBBER being active. Previously, it was assumed that there is
> an Invert usage that would toggle BTN_TOOL_RUBBER. XP-Pen Artist 24
> (and possibly other devices) does not have Invert in its report
> descriptor, resulting in missing BTN_TOOL_RUBBER. BTN_TOUCH without an
> active tool has no meaning in the input stream.
>
> 276e14e6c3 adds a quirk for this and sends the required BTN_TOOL_RUBBER
> events *only* for styli not doing it themselves via Invert. In fact,
> 276e14e6c3 does not even affect the "two-eraser" XP-Pen Artist Pro 16
> Gen 2 and all other devices having Invert in their report descriptors.
> The quirk is not set, the behavior is unchanged [2].
Yes. That quirk only affects the device clearly not following the
specification. Which is why it wasn't noticed that it was wrong.
>
> As Illia already described, the *real problem* is the missing
> compatibility of the whole hidinput_hid_event state machine with
> hidinput_setkeycode, invoked from userspace via the EVIOCSKEYCODE ioctl.
> In David's case, this is done by hwdb.
Sorry but I tend to disagree. Relying on the ioctl EVIOCSKEYCODE for
tuning the behavior of a state machine is just plain wrong. When
people do that, they are doing it at the wrong level and introducing
further bugs.
The whole pen and touch HID protocols rely on a state machine. You
just can not change the meaning of it because your hardware maker
produced a faulty hardware.
The correct solution is to submit a fix here, so that everyone gets
the benefit of it. But that fix can now be a HID-BPF program, which
will be eventually integrated in the kernel tree as soon as I manage
to get enough time to work on it.
>
> This has been the case at least since the refactoring and even affects
> styli *completely* adhering to [1]: remapping Invert to something other
> than BTN_TOOL_RUBBER borks the device. If you replay the recording [3]
> (with or without 276e14e6c3) and remap [4] 0xd003c (Invert) to something
> other than BTN_TOOL_RUBBER, you can observe that:
In the same way, if you remap Tip Switch to KEY-A, you won't get
clicks from your pen. Assuming you can do that with any event on any
HID device is just plain wrong.
That ioctl is OK-ish for "remapping" simple things like keys. In our
case, the whole firmware follows a state machine, so we can not change
it. It has to be remapped in a later layer, in libinput, your
compositor, or in your end user application.
>
> (1) Remapped Invert does not trigger the event it was remapped to -- this
> is due to hardcoded BTN_TOOL_RUBBER and BTN_TOUCH in hidinput_hid_event
>
> (2) After triggering Invert once, BTN_TOOL_PEN and BTN_TOUCH never appear
> in the event stream again -- remapping Invert masks BTN_TOOL_RUBBER,
> causing it to get permanently stuck in report->tool.
>
> 276e14e6c3 does extend this issue onto Eraser remappings for devices
> without Invert, resulting in this regression. However, the solution is
> to fix 276e14e6c3 (and the whole function, while we're at it), not to
> revert it.
Again, you convinced me that this commit was wrong. If people needs to
also use an ioctl to "fix" it, then there is something wrong.
>
> > - both of these tablets are forwarding the useful information, but not
> > correctly, which confuses the kernel
> > - I should now be able to write regression tests
> > - I should be able to provide HID-BPF fixes for those tablets so that
> > we can keep them working with or without
> > 276e14e6c3993317257e1787e93b7166fbc30905
> > reverted (hopefully)
> > - problem is I still don't have the mechanics to integrate the HID-BPF
> > fixes directly in the kernel tree, so maybe I'll have to write a
> > driver for XP-Pen while these internals are set (it shouldn't
> > interfere with the HID-BPF out of the tree).
>
> As you can see, there is no need for rewriting anything. The generic
> solution for "invertless" digitizers is already in place and has no
> impact on other devices. IMHO, it would be wiser to fix the regression
> by making hidinput_hid_event compatible with EVIOCSKEYCODE, than to miss
> the point of what is actually broken and write device-specific drivers.
EVIOCSKEYCODE is called by userspace *after* the kernel parsed the
device and is ready to accept events. There is no way we can make this
consistent with the event stream. If you need to call that ioctl to
fix your device, it's a bug in the kernel, and it needs to be fixed
there before being presented to the userspace.
I might buy the "invertless" devices are a thing if I can get more
data about it. So far there are only 2 of them, and they add extra
complexity in the code when we can just patch the devices to do the
right thing.
>
> [1] https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-pen-states
>
> [2] David confirms it in his blog post: "I now know it is there for a
> long time, because even with the "old" kernel, my newer XPPen 16 Pro
> (gen2) also reacts this way."
> https://www.davidrevoy.com/article995/how-a-kernel-update-broke-my-stylus-need-help
New hardware isn't supposed to be supported on an old kernel and is
not considered as a regression. However, David mentioned that the
device was "working" on 6.5.0 but broke in 6.5.8 with the patch
mentioned above. This is a regression that needs to be tackled.
Especially because it was introduced in 6.6 but backported into 6.5.
Cheers,
Benjamin
>
> [3] https://dl.uni-h.de/?t=6b2cabd8f15ac8ff281b52e25920c0a9
>
> [4] https://github.com/iostapyshyn/evmap is a handy EVIOCSKEYCODE wrapper
> for remapping.
>
^ permalink raw reply
* Re: [PATCH v5 3/3] Input: cap11xx - remove unnecessary IRQ parsing
From: Rob Herring @ 2023-11-08 19:53 UTC (permalink / raw)
To: Jiri Valek - 2N
Cc: krzysztof.kozlowski+dt, dmitry.torokhov, devicetree, linux-input,
linux-kernel, u.kleine-koenig
In-Reply-To: <20231108155647.1812835-4-jiriv@axis.com>
On Wed, Nov 8, 2023 at 9:57 AM Jiri Valek - 2N <jiriv@axis.com> wrote:
>
> Separate IRQ parsing is not necessary, I2C core do the job.
>
> Signed-off-by: Jiri Valek - 2N <jiriv@axis.com>
> ---
> drivers/input/keyboard/cap11xx.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
> index 4711ea985627..ccca9936ef25 100644
> --- a/drivers/input/keyboard/cap11xx.c
> +++ b/drivers/input/keyboard/cap11xx.c
> @@ -518,7 +518,7 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
> struct device *dev = &i2c_client->dev;
> struct cap11xx_priv *priv;
> const struct cap11xx_hw_model *cap;
> - int i, error, irq;
> + int i, error;
> unsigned int val, rev;
>
> if (id->driver_data >= ARRAY_SIZE(cap11xx_devices)) {
> @@ -624,13 +624,7 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
> if (error)
> return error;
>
> - irq = irq_of_parse_and_map(dev->of_node, 0);
Probably can drop the include of of_irq.h as well.
^ permalink raw reply
* Re: Requesting your attention and expertise regarding a Tablet/Kernel issue
From: Nils Fuhler @ 2023-11-08 19:40 UTC (permalink / raw)
To: benjamin.tissoires
Cc: davidrevoy, folays, jason.gerecke, jkosina, jose.exposito89,
linux-input, linux-kernel, ostapyshyn, nils
In-Reply-To: <CAO-hwJK_xp1A=dEOV-2v3KJAf0bRLDWNcrFQeBpgEuxT-qSBnw@mail.gmail.com>
Benjamin Tissoires <benjamin.tissoires@redhat.com> writes:
> So, to me:
> - 276e14e6c3993317257e1787e93b7166fbc30905 is wrong: this is a
> firmware bug (reporting invert through eraser) and should not be
> tackled at the generic level, thus it should be reverted
Surely that can't be the solution. [1] is not a specification but a
suggestion that many manufacturers seem to follow. Apparently, there
are devices that directly report "erasing" for the upper button,
skipping the whole "intent to erase" business. A questionable decision,
but clearly intended.
The evdev input protocol represents the erasing action as BTN_TOUCH with
BTN_TOOL_RUBBER being active. Previously, it was assumed that there is
an Invert usage that would toggle BTN_TOOL_RUBBER. XP-Pen Artist 24
(and possibly other devices) does not have Invert in its report
descriptor, resulting in missing BTN_TOOL_RUBBER. BTN_TOUCH without an
active tool has no meaning in the input stream.
276e14e6c3 adds a quirk for this and sends the required BTN_TOOL_RUBBER
events *only* for styli not doing it themselves via Invert. In fact,
276e14e6c3 does not even affect the "two-eraser" XP-Pen Artist Pro 16
Gen 2 and all other devices having Invert in their report descriptors.
The quirk is not set, the behavior is unchanged [2].
As Illia already described, the *real problem* is the missing
compatibility of the whole hidinput_hid_event state machine with
hidinput_setkeycode, invoked from userspace via the EVIOCSKEYCODE ioctl.
In David's case, this is done by hwdb.
This has been the case at least since the refactoring and even affects
styli *completely* adhering to [1]: remapping Invert to something other
than BTN_TOOL_RUBBER borks the device. If you replay the recording [3]
(with or without 276e14e6c3) and remap [4] 0xd003c (Invert) to something
other than BTN_TOOL_RUBBER, you can observe that:
(1) Remapped Invert does not trigger the event it was remapped to -- this
is due to hardcoded BTN_TOOL_RUBBER and BTN_TOUCH in hidinput_hid_event
(2) After triggering Invert once, BTN_TOOL_PEN and BTN_TOUCH never appear
in the event stream again -- remapping Invert masks BTN_TOOL_RUBBER,
causing it to get permanently stuck in report->tool.
276e14e6c3 does extend this issue onto Eraser remappings for devices
without Invert, resulting in this regression. However, the solution is
to fix 276e14e6c3 (and the whole function, while we're at it), not to
revert it.
> - both of these tablets are forwarding the useful information, but not
> correctly, which confuses the kernel
> - I should now be able to write regression tests
> - I should be able to provide HID-BPF fixes for those tablets so that
> we can keep them working with or without
> 276e14e6c3993317257e1787e93b7166fbc30905
> reverted (hopefully)
> - problem is I still don't have the mechanics to integrate the HID-BPF
> fixes directly in the kernel tree, so maybe I'll have to write a
> driver for XP-Pen while these internals are set (it shouldn't
> interfere with the HID-BPF out of the tree).
As you can see, there is no need for rewriting anything. The generic
solution for "invertless" digitizers is already in place and has no
impact on other devices. IMHO, it would be wiser to fix the regression
by making hidinput_hid_event compatible with EVIOCSKEYCODE, than to miss
the point of what is actually broken and write device-specific drivers.
[1] https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-pen-states
[2] David confirms it in his blog post: "I now know it is there for a
long time, because even with the "old" kernel, my newer XPPen 16 Pro
(gen2) also reacts this way."
https://www.davidrevoy.com/article995/how-a-kernel-update-broke-my-stylus-need-help
[3] https://dl.uni-h.de/?t=6b2cabd8f15ac8ff281b52e25920c0a9
[4] https://github.com/iostapyshyn/evmap is a handy EVIOCSKEYCODE wrapper
for remapping.
^ permalink raw reply
* Re: Requesting your attention and expertise regarding a Tablet/Kernel issue
From: Benjamin Tissoires @ 2023-11-08 18:21 UTC (permalink / raw)
To: José Expósito
Cc: Eric GOUYER, Illia Ostapyshyn, David Revoy, jkosina,
jason.gerecke, linux-input, linux-kernel
In-Reply-To: <CAO-hwJLjtjdr2gtrOWJFPZ-38YzKB8XfhDKWf_2jUPeiaP3EcA@mail.gmail.com>
On Wed, Nov 8, 2023 at 10:34 AM Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> On Wed, Nov 8, 2023 at 10:23 AM José Expósito <jose.exposito89@gmail.com> wrote:
> >
> > Hi Benjamin,
> >
> > On Wed, Nov 08, 2023 at 10:04:30AM +0100, Benjamin Tissoires wrote:
> [...]
> > >
> > > >
> > > > So, the behavior probably breaks the specs, but sincerely I'm happy to
> > > > have the "eraser" button independent of the "rubber eraser", which
> > > > makes the stylus a somewhat 4-buttons stylus (tip, button1, button2,
> > > > rubber), and I would like to keep this.
> > >
> > > Yes, and I'd like to keep it that way, even if 6.6 and 6.5.8
> > > apparently broke it.
> > >
> > > So, to me:
> > > - 276e14e6c3993317257e1787e93b7166fbc30905 is wrong: this is a
> > > firmware bug (reporting invert through eraser) and should not be
> > > tackled at the generic level, thus it should be reverted
> > > - both of these tablets are forwarding the useful information, but not
> > > correctly, which confuses the kernel
> > > - I should now be able to write regression tests
> > > - I should be able to provide HID-BPF fixes for those tablets so that
> > > we can keep them working with or without
> > > 276e14e6c3993317257e1787e93b7166fbc30905
> > > reverted (hopefully)
> > > - problem is I still don't have the mechanics to integrate the HID-BPF
> > > fixes directly in the kernel tree, so maybe I'll have to write a
> > > driver for XP-Pen while these internals are set (it shouldn't
> > > interfere with the HID-BPF out of the tree).
> >
> > I already added support for a few XP-Pen devices on the UCLogic driver
> > and I was planning to start working on this one during the weekend in
> > my DIGImend fork (to simplify testing).
> >
> > Let me know if you prefer to add it yourself or if you want me to ping
> > you in the DIGImend discussion.
> >
>
> So far, I really have to work on this now. It's a good use case for
> HID-BPF and it's a regression that I'd like to be fixed ASAP.
> I'd appreciate any reviews :)
Alright, I made quite some progress so far:
- regressions tests have been written (branch wip/xp-pen of my fork on
freedesktop[0])
that branch can not go in directly as it just adds the tests, and
thus is failing
- I made the fixes through HID-BPF[1]
Anyone using those 2 tablets and using Fedora should be able to just
grab the artifact at [2], uncompress it and run `sudo ./install.sh
--verbose`.
This will install the bpf programs in /lib/firmware/hid/bpf/ and will
automatically load them when the device is connected.
For those not using Fedora, the binary might work (or not, not sure),
but you can always decompress it, and check if running
`udev-hid-bpf_0.1.0/bin/udev-hid-bpf --version` returns the correct
version or just fails. If you get "udev-hid-bpf 0.1.0", then running
`sudo ./install.sh --verbose` should work, as long as the kernel has
CONFIG_HID_BPF set to 'Y'.
>
> Also, good to know that I can probably piggyback on hid-uclogic for
> fixing those 2 devices in the kernel.
>
Next step will be to fix them using a kernel driver, but it seems that
the uclogic driver is doing more than just report descriptor fixups,
so maybe I'll have to use a different driver.
But the point is, in theory, if you are affected by those bugs, using
the udev-hid-bpf should fix the issue, and this should also be
resilient to further kernel updates.
I'd appreciate testing when I got the full kernel series up and ready,
of course.
Cheers,
Benjamin
[0] https://gitlab.freedesktop.org/bentiss/hid/-/tree/wip/xp-pen?ref_type=heads
[1] https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/27
[2] https://gitlab.freedesktop.org/bentiss/udev-hid-bpf/-/jobs/51350589/artifacts/raw/udev-hid-bpf_0.1.0.tar.xz
^ permalink raw reply
* [PATCH v5 2/3] Input: cap11xx - add advanced sensitivity settings
From: Jiri Valek - 2N @ 2023-11-08 15:56 UTC (permalink / raw)
To: krzysztof.kozlowski+dt, dmitry.torokhov
Cc: jiriv, devicetree, linux-input, linux-kernel, robh+dt,
u.kleine-koenig
In-Reply-To: <20231108155647.1812835-1-jiriv@axis.com>
Add support for advanced sensitivity settings that allows more precise
tunig of touch buttons. Input-treshold allows to set the sensitivity for
each channel separately. Also add signal guard feature for CAP129x chips.
Signed-off-by: Jiri Valek - 2N <jiriv@axis.com>
---
drivers/input/keyboard/cap11xx.c | 242 +++++++++++++++++++++++++------
1 file changed, 196 insertions(+), 46 deletions(-)
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index 1b4937dce672..4711ea985627 100644
--- a/drivers/input/keyboard/cap11xx.c
+++ b/drivers/input/keyboard/cap11xx.c
@@ -14,6 +14,7 @@
#include <linux/regmap.h>
#include <linux/i2c.h>
#include <linux/gpio/consumer.h>
+#include <linux/bitfield.h>
#define CAP11XX_REG_MAIN_CONTROL 0x00
#define CAP11XX_REG_MAIN_CONTROL_GAIN_SHIFT (6)
@@ -24,6 +25,7 @@
#define CAP11XX_REG_NOISE_FLAG_STATUS 0x0a
#define CAP11XX_REG_SENOR_DELTA(X) (0x10 + (X))
#define CAP11XX_REG_SENSITIVITY_CONTROL 0x1f
+#define CAP11XX_REG_SENSITIVITY_CONTROL_DELTA_SENSE_MASK 0x70
#define CAP11XX_REG_CONFIG 0x20
#define CAP11XX_REG_SENSOR_ENABLE 0x21
#define CAP11XX_REG_SENSOR_CONFIG 0x22
@@ -32,6 +34,7 @@
#define CAP11XX_REG_CALIBRATION 0x26
#define CAP11XX_REG_INT_ENABLE 0x27
#define CAP11XX_REG_REPEAT_RATE 0x28
+#define CAP11XX_REG_SIGNAL_GUARD_ENABLE 0x29
#define CAP11XX_REG_MT_CONFIG 0x2a
#define CAP11XX_REG_MT_PATTERN_CONFIG 0x2b
#define CAP11XX_REG_MT_PATTERN 0x2d
@@ -47,6 +50,8 @@
#define CAP11XX_REG_SENSOR_BASE_CNT(X) (0x50 + (X))
#define CAP11XX_REG_LED_POLARITY 0x73
#define CAP11XX_REG_LED_OUTPUT_CONTROL 0x74
+#define CAP11XX_REG_CALIB_SENSITIVITY_CONFIG 0x80
+#define CAP11XX_REG_CALIB_SENSITIVITY_CONFIG2 0x81
#define CAP11XX_REG_LED_DUTY_CYCLE_1 0x90
#define CAP11XX_REG_LED_DUTY_CYCLE_2 0x91
@@ -78,12 +83,20 @@ struct cap11xx_led {
struct cap11xx_priv {
struct regmap *regmap;
+ struct device *dev;
struct input_dev *idev;
+ const struct cap11xx_hw_model *model;
+ u8 id;
struct cap11xx_led *leds;
int num_leds;
/* config */
+ u8 analog_gain;
+ u8 sensitivity_delta_sense;
+ u8 signal_guard_inputs_mask;
+ u32 thresholds[8];
+ u32 calib_sensitivities[8];
u32 keycodes[];
};
@@ -181,6 +194,178 @@ static const struct regmap_config cap11xx_regmap_config = {
.volatile_reg = cap11xx_volatile_reg,
};
+static int
+cap11xx_write_calib_sens_config_1(struct cap11xx_priv *priv)
+{
+ return regmap_write(priv->regmap,
+ CAP11XX_REG_CALIB_SENSITIVITY_CONFIG,
+ (priv->calib_sensitivities[3] << 6) |
+ (priv->calib_sensitivities[2] << 4) |
+ (priv->calib_sensitivities[1] << 2) |
+ priv->calib_sensitivities[0]);
+}
+
+static int
+cap11xx_write_calib_sens_config_2(struct cap11xx_priv *priv)
+{
+ return regmap_write(priv->regmap,
+ CAP11XX_REG_CALIB_SENSITIVITY_CONFIG2,
+ (priv->calib_sensitivities[7] << 6) |
+ (priv->calib_sensitivities[6] << 4) |
+ (priv->calib_sensitivities[5] << 2) |
+ priv->calib_sensitivities[4]);
+}
+
+static int
+cap11xx_init_keys(struct cap11xx_priv *priv)
+{
+ struct device_node *node = priv->dev->of_node;
+ struct device *dev = priv->dev;
+ int i, error;
+ u32 u32_val;
+
+ if (!node) {
+ dev_err(dev, "Corresponding DT entry is not available\n");
+ return -ENODEV;
+ }
+
+ if (!of_property_read_u32(node, "microchip,sensor-gain", &u32_val)) {
+ if (priv->model->no_gain) {
+ dev_warn(dev,
+ "This model doesn't support 'sensor-gain'\n");
+ } else if (is_power_of_2(u32_val) && u32_val <= 8) {
+ priv->analog_gain = (u8)ilog2(u32_val);
+
+ error = regmap_update_bits(priv->regmap,
+ CAP11XX_REG_MAIN_CONTROL,
+ CAP11XX_REG_MAIN_CONTROL_GAIN_MASK,
+ priv->analog_gain << CAP11XX_REG_MAIN_CONTROL_GAIN_SHIFT);
+ if (error)
+ return error;
+ } else {
+ dev_err(dev, "Invalid sensor-gain value %u\n", u32_val);
+ return -EINVAL;
+ }
+ }
+
+ if (of_property_read_bool(node, "microchip,irq-active-high")) {
+ if (priv->id == CAP1106 ||
+ priv->id == CAP1126 ||
+ priv->id == CAP1188) {
+ error = regmap_update_bits(priv->regmap,
+ CAP11XX_REG_CONFIG2,
+ CAP11XX_REG_CONFIG2_ALT_POL,
+ 0);
+ if (error)
+ return error;
+ } else {
+ dev_warn(dev,
+ "This model doesn't support 'irq-active-high'\n");
+ }
+ }
+
+ if (!of_property_read_u32(node,
+ "microchip,sensitivity-delta-sense", &u32_val)) {
+ if (!is_power_of_2(u32_val) || u32_val > 128) {
+ dev_err(dev, "Invalid sensitivity-delta-sense value %u\n", u32_val);
+ return -EINVAL;
+ }
+
+ priv->sensitivity_delta_sense = (u8)ilog2(u32_val);
+ u32_val = ~(FIELD_PREP(CAP11XX_REG_SENSITIVITY_CONTROL_DELTA_SENSE_MASK,
+ priv->sensitivity_delta_sense));
+
+ error = regmap_update_bits(priv->regmap,
+ CAP11XX_REG_SENSITIVITY_CONTROL,
+ CAP11XX_REG_SENSITIVITY_CONTROL_DELTA_SENSE_MASK,
+ u32_val);
+ if (error)
+ return error;
+ }
+
+ if (!of_property_read_u32_array(node, "microchip,input-treshold",
+ priv->thresholds, priv->model->num_channels)) {
+ for (i = 0; i < priv->model->num_channels; i++) {
+ if (priv->thresholds[i] > 127) {
+ dev_err(dev, "Invalid input-treshold value %u\n",
+ priv->thresholds[i]);
+ return -EINVAL;
+ }
+
+ error = regmap_write(priv->regmap,
+ CAP11XX_REG_SENSOR_THRESH(i),
+ priv->thresholds[i]);
+ if (error)
+ return error;
+ }
+ }
+
+ if (!of_property_read_u32_array(node, "microchip,calib-sensitivity",
+ priv->calib_sensitivities, priv->model->num_channels)) {
+ if (priv->id == CAP1293 || priv->id == CAP1298) {
+ for (i = 0; i < priv->model->num_channels; i++) {
+ if (!is_power_of_2(priv->calib_sensitivities[i]) ||
+ priv->calib_sensitivities[i] > 4) {
+ dev_err(dev, "Invalid calib-sensitivity value %u\n",
+ priv->calib_sensitivities[i]);
+ return -EINVAL;
+ }
+ priv->calib_sensitivities[i] = ilog2(priv->calib_sensitivities[i]);
+ }
+
+ error = cap11xx_write_calib_sens_config_1(priv);
+ if (error)
+ return error;
+
+ if (priv->id == CAP1298) {
+ error = cap11xx_write_calib_sens_config_2(priv);
+ if (error)
+ return error;
+ }
+ } else {
+ dev_warn(dev,
+ "This model doesn't support 'calib-sensitivity'\n");
+ }
+ }
+
+ for (i = 0; i < priv->model->num_channels; i++) {
+ if (!of_property_read_u32_index(node, "microchip,signal-guard",
+ i, &u32_val)) {
+ if (u32_val > 1)
+ return -EINVAL;
+ if (u32_val)
+ priv->signal_guard_inputs_mask |= 0x01 << i;
+ }
+ }
+
+ if (priv->signal_guard_inputs_mask) {
+ if (priv->id == CAP1293 || priv->id == CAP1298) {
+ error = regmap_write(priv->regmap,
+ CAP11XX_REG_SIGNAL_GUARD_ENABLE,
+ priv->signal_guard_inputs_mask);
+ if (error)
+ return error;
+ } else {
+ dev_warn(dev,
+ "This model doesn't support 'signal-guard'\n");
+ }
+ }
+
+ /* Provide some useful defaults */
+ for (i = 0; i < priv->model->num_channels; i++)
+ priv->keycodes[i] = KEY_A + i;
+
+ of_property_read_u32_array(node, "linux,keycodes",
+ priv->keycodes, priv->model->num_channels);
+
+ /* Disable autorepeat. The Linux input system has its own handling. */
+ error = regmap_write(priv->regmap, CAP11XX_REG_REPEAT_RATE, 0);
+ if (error)
+ return error;
+
+ return 0;
+}
+
static irqreturn_t cap11xx_thread_func(int irq_num, void *data)
{
struct cap11xx_priv *priv = data;
@@ -332,11 +517,9 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
const struct i2c_device_id *id = i2c_client_get_device_id(i2c_client);
struct device *dev = &i2c_client->dev;
struct cap11xx_priv *priv;
- struct device_node *node;
const struct cap11xx_hw_model *cap;
- int i, error, irq, gain = 0;
+ int i, error, irq;
unsigned int val, rev;
- u32 gain32;
if (id->driver_data >= ARRAY_SIZE(cap11xx_devices)) {
dev_err(dev, "Invalid device ID %lu\n", id->driver_data);
@@ -355,6 +538,8 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
if (!priv)
return -ENOMEM;
+ priv->dev = dev;
+
priv->regmap = devm_regmap_init_i2c(i2c_client, &cap11xx_regmap_config);
if (IS_ERR(priv->regmap))
return PTR_ERR(priv->regmap);
@@ -384,50 +569,15 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
return error;
dev_info(dev, "CAP11XX detected, model %s, revision 0x%02x\n",
- id->name, rev);
- node = dev->of_node;
-
- if (!of_property_read_u32(node, "microchip,sensor-gain", &gain32)) {
- if (cap->no_gain)
- dev_warn(dev,
- "This version doesn't support sensor gain\n");
- else if (is_power_of_2(gain32) && gain32 <= 8)
- gain = ilog2(gain32);
- else
- dev_err(dev, "Invalid sensor-gain value %d\n", gain32);
- }
+ id->name, rev);
- if (id->driver_data == CAP1106 ||
- id->driver_data == CAP1126 ||
- id->driver_data == CAP1188) {
- if (of_property_read_bool(node, "microchip,irq-active-high")) {
- error = regmap_update_bits(priv->regmap,
- CAP11XX_REG_CONFIG2,
- CAP11XX_REG_CONFIG2_ALT_POL,
- 0);
- if (error)
- return error;
- }
- }
+ priv->model = cap;
+ priv->id = id->driver_data;
- /* Provide some useful defaults */
- for (i = 0; i < cap->num_channels; i++)
- priv->keycodes[i] = KEY_A + i;
-
- of_property_read_u32_array(node, "linux,keycodes",
- priv->keycodes, cap->num_channels);
-
- if (!cap->no_gain) {
- error = regmap_update_bits(priv->regmap,
- CAP11XX_REG_MAIN_CONTROL,
- CAP11XX_REG_MAIN_CONTROL_GAIN_MASK,
- gain << CAP11XX_REG_MAIN_CONTROL_GAIN_SHIFT);
- if (error)
- return error;
- }
+ dev_info(dev, "CAP11XX device detected, model %s, revision 0x%02x\n",
+ id->name, rev);
- /* Disable autorepeat. The Linux input system has its own handling. */
- error = regmap_write(priv->regmap, CAP11XX_REG_REPEAT_RATE, 0);
+ error = cap11xx_init_keys(priv);
if (error)
return error;
@@ -439,7 +589,7 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
priv->idev->id.bustype = BUS_I2C;
priv->idev->evbit[0] = BIT_MASK(EV_KEY);
- if (of_property_read_bool(node, "autorepeat"))
+ if (of_property_read_bool(dev->of_node, "autorepeat"))
__set_bit(EV_REP, priv->idev->evbit);
for (i = 0; i < cap->num_channels; i++)
@@ -474,7 +624,7 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
if (error)
return error;
- irq = irq_of_parse_and_map(node, 0);
+ irq = irq_of_parse_and_map(dev->of_node, 0);
if (!irq) {
dev_err(dev, "Unable to parse or map IRQ\n");
return -ENXIO;
--
2.25.1
^ permalink raw reply related
* [PATCH v5 3/3] Input: cap11xx - remove unnecessary IRQ parsing
From: Jiri Valek - 2N @ 2023-11-08 15:56 UTC (permalink / raw)
To: krzysztof.kozlowski+dt, dmitry.torokhov
Cc: jiriv, devicetree, linux-input, linux-kernel, robh+dt,
u.kleine-koenig
In-Reply-To: <20231108155647.1812835-1-jiriv@axis.com>
Separate IRQ parsing is not necessary, I2C core do the job.
Signed-off-by: Jiri Valek - 2N <jiriv@axis.com>
---
drivers/input/keyboard/cap11xx.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/input/keyboard/cap11xx.c b/drivers/input/keyboard/cap11xx.c
index 4711ea985627..ccca9936ef25 100644
--- a/drivers/input/keyboard/cap11xx.c
+++ b/drivers/input/keyboard/cap11xx.c
@@ -518,7 +518,7 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
struct device *dev = &i2c_client->dev;
struct cap11xx_priv *priv;
const struct cap11xx_hw_model *cap;
- int i, error, irq;
+ int i, error;
unsigned int val, rev;
if (id->driver_data >= ARRAY_SIZE(cap11xx_devices)) {
@@ -624,13 +624,7 @@ static int cap11xx_i2c_probe(struct i2c_client *i2c_client)
if (error)
return error;
- irq = irq_of_parse_and_map(dev->of_node, 0);
- if (!irq) {
- dev_err(dev, "Unable to parse or map IRQ\n");
- return -ENXIO;
- }
-
- error = devm_request_threaded_irq(dev, irq, NULL, cap11xx_thread_func,
+ error = devm_request_threaded_irq(dev, i2c_client->irq, NULL, cap11xx_thread_func,
IRQF_ONESHOT, dev_name(dev), priv);
if (error)
return error;
--
2.25.1
^ permalink raw reply related
* [PATCH v5 1/3] dt-bindings: input: microchip,cap11xx: add advanced sensitivity settings
From: Jiri Valek - 2N @ 2023-11-08 15:56 UTC (permalink / raw)
To: krzysztof.kozlowski+dt, dmitry.torokhov
Cc: jiriv, devicetree, linux-input, linux-kernel, robh+dt,
u.kleine-koenig
In-Reply-To: <20231108155647.1812835-1-jiriv@axis.com>
Add support for advanced sensitivity settings and signal guard feature.
Signed-off-by: Jiri Valek - 2N <jiriv@axis.com>
---
.../bindings/input/microchip,cap11xx.yaml | 76 ++++++++++++++++++-
1 file changed, 73 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
index 5b5d4f7d3482..aa97702c43ef 100644
--- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
+++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
@@ -45,13 +45,13 @@ properties:
Enables the Linux input system's autorepeat feature on the input device.
linux,keycodes:
- minItems: 6
- maxItems: 6
+ minItems: 3
+ maxItems: 8
description: |
Specifies an array of numeric keycode values to
be used for the channels. If this property is
omitted, KEY_A, KEY_B, etc are used as defaults.
- The array must have exactly six entries.
+ The number of entries must correspond to the number of channels.
microchip,sensor-gain:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -70,6 +70,55 @@ properties:
open drain. This property allows using the active
high push-pull output.
+ microchip,sensitivity-delta-sense:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 32
+ enum: [1, 2, 4, 8, 16, 32, 64, 128]
+ description:
+ Optional parameter. Controls the sensitivity multiplier of a touch detection.
+ At the more sensitive settings, touches are detected for a smaller delta
+ capacitance corresponding to a “lighter” touch.
+
+ microchip,signal-guard:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 3
+ maxItems: 8
+ items:
+ minimum: 0
+ maximum: 1
+ description: |
+ Optional parameter supported only for CAP129x.
+ 0 - off
+ 1 - on
+ The signal guard isolates the signal from virtual grounds.
+ If enabled then the behavior of the channel is changed to signal guard.
+ The number of entries must correspond to the number of channels.
+
+ microchip,input-treshold:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 3
+ maxItems: 8
+ items:
+ minimum: 0
+ maximum: 127
+ description:
+ Optional parameter. Specifies the delta threshold that is used to
+ determine if a touch has been detected.
+ The number of entries must correspond to the number of channels.
+
+ microchip,calib-sensitivity:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 3
+ maxItems: 8
+ items:
+ minimum: 1
+ maximum: 4
+ description:
+ Optional parameter supported only for CAP129x. Specifies an array of
+ numeric values that controls the gain used by the calibration routine to
+ enable sensor inputs to be more sensitive for proximity detection.
+ The number of entries must correspond to the number of channels.
+
patternProperties:
"^led@[0-7]$":
type: object
@@ -99,10 +148,29 @@ allOf:
contains:
enum:
- microchip,cap1106
+ - microchip,cap1203
+ - microchip,cap1206
+ - microchip,cap1293
+ - microchip,cap1298
then:
patternProperties:
"^led@[0-7]$": false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - microchip,cap1106
+ - microchip,cap1126
+ - microchip,cap1188
+ - microchip,cap1203
+ - microchip,cap1206
+ then:
+ properties:
+ microchip,signal-guard: false
+ microchip,calib-sensitivity: false
+
required:
- compatible
- interrupts
@@ -122,6 +190,8 @@ examples:
reg = <0x28>;
autorepeat;
microchip,sensor-gain = <2>;
+ microchip,sensitivity-delta-sense = <16>;
+ microchip,input-treshold = <21>, <18>, <46>, <46>, <46>, <21>;
linux,keycodes = <103>, /* KEY_UP */
<106>, /* KEY_RIGHT */
--
2.25.1
^ permalink raw reply related
* [PATCH v5 0/3] Input: cap11xx add advanced sensitivity settings
From: Jiri Valek - 2N @ 2023-11-08 15:56 UTC (permalink / raw)
To: krzysztof.kozlowski+dt, dmitry.torokhov
Cc: jiriv, devicetree, linux-input, linux-kernel, robh+dt,
u.kleine-koenig
PATCH 1 - add documentation for new options
PATCH 2 - add support for advanced settings into driver
PATCH 3 - remove unnecessary IRQ parsing
Changes in v2:
- Removed "sensitivity-base-shift" parameter (not HW propertie) in PATCH 2.
- Used IRQ from I2C subsystem instead of parsing it again.
- Fixed some documentation issues in PATCH 1
Changes in v3:
- Remove incorrectly used "Reviewed-by" tag in PATCH 1 and 2
Changes in v4:
- Remove unused variable in PATCH 2
Changes in v5:
- Revert IRQ parsing in PATCH 2 and move to separate PATCH 3
- Fix 'if' condition for properties in PATCH 1
Jiri Valek - 2N (3):
dt-bindings: input: microchip,cap11xx: add advanced sensitivity
settings
Input: cap11xx - add advanced sensitivity settings
Input: cap11xx - remove unnecessary IRQ parsing
.../bindings/input/microchip,cap11xx.yaml | 76 +++++-
drivers/input/keyboard/cap11xx.c | 248 ++++++++++++++----
2 files changed, 269 insertions(+), 55 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH] Input: synaptics: enable InterTouch for ThinkPad L14 G1
From: José Pekkarinen @ 2023-11-08 7:22 UTC (permalink / raw)
To: dmitry.torokhov, rydberg, skhan
Cc: rrangel, linux-input, amandhoot12, linux-kernel,
linux-kernel-mentees
In-Reply-To: <77a53e59cc4151c95942f37c88db8c75@foxhound.fi>
On 2023-10-31 14:39, José Pekkarinen wrote:
> On 2023-10-16 18:51, José Pekkarinen wrote:
>> On 2023-10-08 11:01, José Pekkarinen wrote:
>>> Observed on dmesg of my laptop I see the following
>>> output:
>>>
>>> [ 19.898700] psmouse serio1: synaptics: queried max coordinates: x
>>> [..5678], y [..4694]
>>> [ 19.936057] psmouse serio1: synaptics: queried min coordinates: x
>>> [1266..], y [1162..]
>>> [ 19.936076] psmouse serio1: synaptics: Your touchpad (PNP: LEN0411
>>> PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi
>>> are not used, you might want to try setting
>>> psmouse.synaptics_intertouch to 1 and report this to
>>> linux-input@vger.kernel.org.
>>> [ 20.008901] psmouse serio1: synaptics: Touchpad model: 1, fw:
>>> 10.32, id: 0x1e2a1, caps: 0xf014a3/0x940300/0x12e800/0x500000, board
>>> id: 3471, fw id: 2909640
>>> [ 20.008925] psmouse serio1: synaptics: serio: Synaptics
>>> pass-through port at isa0060/serio1/input0
>>> [ 20.053344] input: SynPS/2 Synaptics TouchPad as
>>> /devices/platform/i8042/serio1/input/input7
>>> [ 20.397608] mousedev: PS/2 mouse device common for all mice
>>>
>>> This patch will add its pnp id to the smbus list to
>>> produce the setup of intertouch for the device. After
>>> applying, the ouput will look like:
>>>
>>> [ 19.168664] psmouse serio1: synaptics: queried max coordinates: x
>>> [..5678], y [..4694]
>>> [ 19.206311] psmouse serio1: synaptics: queried min coordinates: x
>>> [1266..], y [1162..]
>>> [ 19.206325] psmouse serio1: synaptics: Trying to set up SMBus
>>> access
>>> [ 19.209545] psmouse serio1: synaptics: SMbus companion is not
>>> ready yet
>>> [ 19.283845] psmouse serio1: synaptics: Touchpad model: 1, fw:
>>> 10.32, id: 0x1e2a1, caps: 0xf014a3/0x940300/0x12e800/0x500000, board
>>> id: 3471, fw id: 2909640
>>> [ 19.283863] psmouse serio1: synaptics: serio: Synaptics
>>> pass-through port at isa0060/serio1/input0
>>> [ 19.328959] input: SynPS/2 Synaptics TouchPad as
>>> /devices/platform/i8042/serio1/input/input8
>>> [ 19.706164] mousedev: PS/2 mouse device common for all mice
>>>
>>> Signed-off-by: José Pekkarinen <jose.pekkarinen@foxhound.fi>
>>> ---
>>> drivers/input/mouse/synaptics.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/input/mouse/synaptics.c
>>> b/drivers/input/mouse/synaptics.c
>>> index ada299ec5bba..376a041c80b2 100644
>>> --- a/drivers/input/mouse/synaptics.c
>>> +++ b/drivers/input/mouse/synaptics.c
>>> @@ -183,6 +183,7 @@ static const char * const smbus_pnp_ids[] = {
>>> "LEN009b", /* T580 */
>>> "LEN0402", /* X1 Extreme Gen 2 / P1 Gen 2 */
>>> "LEN040f", /* P1 Gen 3 */
>>> + "LEN0411", /* L14 Gen 1 */
>>> "LEN200f", /* T450s */
>>> "LEN2044", /* L470 */
>>> "LEN2054", /* E480 */
>>
>> Any comments here?
>>
>> Thanks!
>>
>> José.
>> _______________________________________________
>> Linux-kernel-mentees mailing list
>> Linux-kernel-mentees@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
>
> Ping.
>
> José.
> _______________________________________________
> Linux-kernel-mentees mailing list
> Linux-kernel-mentees@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
Sorry to bother again, I didn't hear anything from this. Can
you please take a look?
José.
^ permalink raw reply
* [PATCH v2] HID: intel-ish-hid: ipc: Rework EHL OOB wakeup
From: Kai-Heng Feng @ 2023-11-08 12:19 UTC (permalink / raw)
To: srinivas.pandruvada, jikos, benjamin.tissoires
Cc: linux-pm, linux-pci, Kai-Heng Feng, Jian Hui Lee, Even Xu,
linux-input, linux-kernel
Since PCI core and ACPI core already handles PCI PME wake and GPE wake
when the device has wakeup capability, use device_init_wakeup() to let
them do the wakeup setting work.
Also add a shutdown callback which uses pci_prepare_to_sleep() to let
PCI and ACPI set OOB wakeup for S5.
Cc: Jian Hui Lee <jianhui.lee@canonical.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
v2:
Rebase on ("HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit")
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 67 ++++++-------------------
1 file changed, 15 insertions(+), 52 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index 710fda5f19e1..65e7eeb2fa64 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -119,50 +119,6 @@ static inline bool ish_should_leave_d0i3(struct pci_dev *pdev)
return !pm_resume_via_firmware() || pdev->device == CHV_DEVICE_ID;
}
-static int enable_gpe(struct device *dev)
-{
-#ifdef CONFIG_ACPI
- acpi_status acpi_sts;
- struct acpi_device *adev;
- struct acpi_device_wakeup *wakeup;
-
- adev = ACPI_COMPANION(dev);
- if (!adev) {
- dev_err(dev, "get acpi handle failed\n");
- return -ENODEV;
- }
- wakeup = &adev->wakeup;
-
- /*
- * Call acpi_disable_gpe(), so that reference count
- * gpe_event_info->runtime_count doesn't overflow.
- * When gpe_event_info->runtime_count = 0, the call
- * to acpi_disable_gpe() simply return.
- */
- acpi_disable_gpe(wakeup->gpe_device, wakeup->gpe_number);
-
- acpi_sts = acpi_enable_gpe(wakeup->gpe_device, wakeup->gpe_number);
- if (ACPI_FAILURE(acpi_sts)) {
- dev_err(dev, "enable ose_gpe failed\n");
- return -EIO;
- }
-
- return 0;
-#else
- return -ENODEV;
-#endif
-}
-
-static void enable_pme_wake(struct pci_dev *pdev)
-{
- if ((pci_pme_capable(pdev, PCI_D0) ||
- pci_pme_capable(pdev, PCI_D3hot) ||
- pci_pme_capable(pdev, PCI_D3cold)) && !enable_gpe(&pdev->dev)) {
- pci_pme_active(pdev, true);
- dev_dbg(&pdev->dev, "ish ipc driver pme wake enabled\n");
- }
-}
-
/**
* ish_probe() - PCI driver probe callback
* @pdev: pci device
@@ -233,7 +189,7 @@ static int ish_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
/* Enable PME for EHL */
if (pdev->device == EHL_Ax_DEVICE_ID)
- enable_pme_wake(pdev);
+ device_init_wakeup(dev, true);
ret = ish_init(ishtp);
if (ret)
@@ -256,6 +212,19 @@ static void ish_remove(struct pci_dev *pdev)
ish_device_disable(ishtp_dev);
}
+
+/**
+ * ish_shutdown() - PCI driver shutdown callback
+ * @pdev: pci device
+ *
+ * This function sets up wakeup for S5
+ */
+static void ish_shutdown(struct pci_dev *pdev)
+{
+ if (pdev->device == EHL_Ax_DEVICE_ID)
+ pci_prepare_to_sleep(pdev);
+}
+
static struct device __maybe_unused *ish_resume_device;
/* 50ms to get resume response */
@@ -378,13 +347,6 @@ static int __maybe_unused ish_resume(struct device *device)
struct pci_dev *pdev = to_pci_dev(device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
- /* add this to finish power flow for EHL */
- if (dev->pdev->device == EHL_Ax_DEVICE_ID) {
- pci_set_power_state(pdev, PCI_D0);
- enable_pme_wake(pdev);
- dev_dbg(dev->devc, "set power state to D0 for ehl\n");
- }
-
ish_resume_device = device;
dev->resume_flag = 1;
@@ -400,6 +362,7 @@ static struct pci_driver ish_driver = {
.id_table = ish_pci_tbl,
.probe = ish_probe,
.remove = ish_remove,
+ .shutdown = ish_shutdown,
.driver.pm = &ish_pm_ops,
};
--
2.34.1
^ permalink raw reply related
* Re: Requesting your attention and expertise regarding a Tablet/Kernel issue
From: Benjamin Tissoires @ 2023-11-08 9:34 UTC (permalink / raw)
To: José Expósito
Cc: Eric GOUYER, Illia Ostapyshyn, David Revoy, jkosina,
jason.gerecke, linux-input, linux-kernel
In-Reply-To: <ZUtTpKyP0oxWhnn8@fedora>
On Wed, Nov 8, 2023 at 10:23 AM José Expósito <jose.exposito89@gmail.com> wrote:
>
> Hi Benjamin,
>
> On Wed, Nov 08, 2023 at 10:04:30AM +0100, Benjamin Tissoires wrote:
[...]
> >
> > >
> > > So, the behavior probably breaks the specs, but sincerely I'm happy to
> > > have the "eraser" button independent of the "rubber eraser", which
> > > makes the stylus a somewhat 4-buttons stylus (tip, button1, button2,
> > > rubber), and I would like to keep this.
> >
> > Yes, and I'd like to keep it that way, even if 6.6 and 6.5.8
> > apparently broke it.
> >
> > So, to me:
> > - 276e14e6c3993317257e1787e93b7166fbc30905 is wrong: this is a
> > firmware bug (reporting invert through eraser) and should not be
> > tackled at the generic level, thus it should be reverted
> > - both of these tablets are forwarding the useful information, but not
> > correctly, which confuses the kernel
> > - I should now be able to write regression tests
> > - I should be able to provide HID-BPF fixes for those tablets so that
> > we can keep them working with or without
> > 276e14e6c3993317257e1787e93b7166fbc30905
> > reverted (hopefully)
> > - problem is I still don't have the mechanics to integrate the HID-BPF
> > fixes directly in the kernel tree, so maybe I'll have to write a
> > driver for XP-Pen while these internals are set (it shouldn't
> > interfere with the HID-BPF out of the tree).
>
> I already added support for a few XP-Pen devices on the UCLogic driver
> and I was planning to start working on this one during the weekend in
> my DIGImend fork (to simplify testing).
>
> Let me know if you prefer to add it yourself or if you want me to ping
> you in the DIGImend discussion.
>
So far, I really have to work on this now. It's a good use case for
HID-BPF and it's a regression that I'd like to be fixed ASAP.
I'd appreciate any reviews :)
Also, good to know that I can probably piggyback on hid-uclogic for
fixing those 2 devices in the kernel.
Cheers,
Benjamin
^ permalink raw reply
* Re: Requesting your attention and expertise regarding a Tablet/Kernel issue
From: José Expósito @ 2023-11-08 9:23 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Eric GOUYER, Illia Ostapyshyn, David Revoy, jkosina,
jason.gerecke, linux-input, linux-kernel
In-Reply-To: <CAO-hwJK_xp1A=dEOV-2v3KJAf0bRLDWNcrFQeBpgEuxT-qSBnw@mail.gmail.com>
Hi Benjamin,
On Wed, Nov 08, 2023 at 10:04:30AM +0100, Benjamin Tissoires wrote:
> Thanks Eric and Illia for the logs and the explanations.
>
> On Wed, Nov 8, 2023 at 6:23 AM Eric GOUYER <folays@gmail.com> wrote:
> >
> > Sorry, below I re-send my email which bounced due to exceeding 100k
> > (hid-recorder traces included), so I re-send it without them, for some
> > book-keeping.
> >
> > I had originally replied-to-all, so mainteners involved should have
> > received those traces just before (I hope).
> >
> > Best Regards,
> >
> > -----8<-----8<-----8<-----8<
> >
> > Hello, I have the same tablet than OP (David) :
> > - XP-Pen Artist Pro 16 Gen 2
> > - on Ubuntu 23.10 linux-image-generic 6.5.0.10.12
> >
> > I am not (yet ?) encountering the problem described above since I guess
> > that my kernel is before the suspected regression.
> >
> > Here below I included much detail, but you can TL;DR + jump at the five
> > hid-recorder traces below.
> >
> > > On Mon, Nov 6, 2023 at 9:06 PM Illia Ostapyshyn
> > > <ostapyshyn@sra.uni-hannover.de> wrote:
> > > >
> > > > On 11/6/23 17:59, Benjamin Tissoires wrote:
> > > >
> > > > > If the pen has 2 buttons, and an eraser side, it would be a
> > > > > serious design flow for XPPEN to report both as eraser.
> > > > >
> > > > > Could you please use sudo hid-recorder from hid-tools[1] on any
> > > > > kernel version and send us the logs here?
> > > > > I'll be able to replay the events locally, and understand why the
> > > > > kernel doesn't work properly.
> > > > >
> > > > > And if there is a design flaw that can be fixed, we might even be
> > > > > able to use hid-bpf to change it :)
> > > >
> > > > My wild guess is that XP-Pen 16 Artist Pro reports :
> > > > - (1) an Eraser usage without Invert for the upper button
> > > > - (2) and Eraser with Invert for the eraser tip.
> >
> > I think you will agree with below traces that :
> > - (1) : correct (it reports invert=0 eraser=1 tipSwitch=1)
> > - (2) : no, for the rubber tip, it reports invert=1 eraser=0 tipSwitch=1
> >
> > > > A device-specific driver could work with that, but
> > > > there seems to be no way to incorporate two different erasers
> > > > (thus, allowing userspace to map them to different actions
> > > > arbitrarily) in the generic driver currently.
> > >
> > > That's exactly why I want to see the exact event flow. We can not do
> > > "wild guesses" unfortunately (not meaning any offenses).
> > > And I am very suspicious about the fact that the stylus reports 2
> > > identical erasers. Because in the past David seemed to be able to have
> > > 2 distincts behaviors for the 2 "buttons" (physical button and eraser
> > > tail).
> >
> > The Pen, hardware-wise, has the following possibilities :
> > - The (main) pressure tip
> > - The "bottom" button (nearest of the main pressure tip)
> > - The "top" button (farthest of the main tip
> > - The "back" pressure tip (it has pressure!) somewhat called rubber
> >
> > All of those works I think -natively- on my kernel version, without
> > external 3rd-party kernel modules.
> >
> > It works especially on Blender, where I can :
> > - click (or paint) with main pressure-tip
> > - middle-click (to pan viewport) with "bottom" button + move main tip
> > - right-click with "top" button
> > - erase with backside pressure-tip
> >
> > I installed a .deb from the official website [1] which does not contain
> > kernel modules, and seems to only contains :
> > - a udev rule to, I think, chmod 0666 to input character devices
> > - a Qt app to configure some behavior, only userland-side.
> >
> > I think I observed that before running the Qt app, there was only 3
> > xinput devices, and after launching it, there were 4 more (7 total).
> >
> > Blender would not receive pen input without lanching the Qt app.
> > Indeed, the "first" 3 /dev/input/event* associated to the pen are
> > chmod'ed too restrictively (0660) for an underprivileged user.
>
> This is wrong (not your fault, of course). There is no way Blender
> should directly talk to the input nodes. It should use the events from
> the compositor, not randomly getting values from input nodes. sigh...
>
> >
> > Anyway, after running the Qt App, 4 *ANOTHER* /dev/input/event* pops,
> > correctly chmod'ed (thanks to the udev rules), and Blender works.
>
> I got a quick look, and those events are coming from uinput. So their
> Qt App is just a horrible user space driver to fix their tablet. Ouch.
>
> >
> > My best guess would be that the first 3 very-native /dev/input/
> > devices are somewhat "raw", and that the Qt app feeds those inputs to
> > the Qt app's configured pressure curve + remap the button to the input
> > as chosen by the user.
>
> The "raw" nodes are giving all of the information, but not correctly.
> So they are using a separate userspace driver to "fix" it.
>
> >
> > Here is the dmesg before launching the Qt App :
> > -----8<-----8<-----8<-----8<
> > usb 3-9: new full-speed USB device number 64 using xhci_hcd
> > usb 3-9: New USB device found, idVendor=28bd, idProduct=095b,
> > bcdDevice= 0.00
> > usb 3-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> > usb 3-9: Product: Artist Pro 16 (Gen2)
> > usb 3-9: Manufacturer: UGTABLET
> > usb 3-9: SerialNumber: 00000
> > input: UGTABLET Artist Pro 16 (Gen2) Mouse as
> > /devices/pci0000:00/0000:00:02.1/0000:04:00.0/0000:05:08.0/0000:07:00.0/
> > 0000:08:0c.0/0000:69:00.0/usb3/3-9/3-9:1.0/0003:28BD:095B.009E/input/input196
> > input: UGTABLET Artist Pro 16 (Gen2) Keyboard as
> > /devices/pci0000:00/0000:00:02.1/0000:04:00.0/0000:05:08.0/0000:07:00.0/
> > 0000:08:0c.0/0000:69:00.0/usb3/3-9/3-9:1.0/0003:28BD:095B.009E/input/input197
> > hid-generic 0003:28BD:095B.009E: input,hidraw4: USB HID v1.00 Mouse
> > [UGTABLET Artist Pro 16 (Gen2)] on usb-0000:69:00.0-9/input0
> > input: UGTABLET Artist Pro 16 (Gen2) as
> > /devices/pci0000:00/0000:00:02.1/0000:04:00.0/0000:05:08.0/0000:07:00.0/
> > 0000:08:0c.0/0000:69:00.0/usb3/3-9/3-9:1.1/0003:28BD:095B.009F/input/input198
> > hid-generic 0003:28BD:095B.009F: input,hidraw7: USB HID v1.00 Device
> > [UGTABLET Artist Pro 16 (Gen2)] on usb-0000:69:00.0-9/input1
> > hid-generic 0003:28BD:095B.00A0: hiddev0,hidraw12: USB HID v1.00 Device
> > [UGTABLET Artist Pro 16 (Gen2)] on usb-0000:69:00.0-9/input2
> > -----8<-----8<-----8<-----8<
> >
> > This make "sudo xinput" reports 3 new devices :
> > UGTABLET Artist Pro 16 (Gen2) Mouse id=x [slave pointer (n)]
> > UGTABLET Artist Pro 16 (Gen2) Keyboard id=y [slave keyboard (n+1)]
> > UGTABLET Artist Pro 16 (Gen2) id=z [slave keyboard (n+1)]
> > (sorry I've masked the id to prevent confusion, I did not run "xinput"
> > at the same time/power cycle than "dmesg")
> >
> > Running the Qt App makes "sudo xinput" report 4 new devices :
> > XP-Pen Mouse id=xc [slave pointer (n)]
> > XP-Pen Eraser id=xa [slave keyboard (n+1)]
> > XP-Pen Pen id=xb [slave keyboard (n+1)] << only this chmod'ed 0666
> > XP-Pen Mouse id=xd [slave keyboard (n+1)]
> >
> > And... it suffices to make Blender works without configuring anything.
> >
> > Anyway, besides this user experience / userland Qt app, here are some
> > five hid-recorder traces ;
>
> Many thanks for attaching them and for digging into them.
>
> > I re-used the terminology appearing in the traces :
> > - "barrel" : the "bottom" button nearest of the main tip
> > - "erase" : the farther "top" button, just above "barrel"
> > - "back" : the "rubber" secondary pressure tip at the back of the pen
> >
> > (1) hidraw7_inRange_contact_move_lift_outOfRange
> > I "contact" the main tip, move it, and lift it out or range.
> >
> > (2) hidraw7_inRange_contact_barrelPress\
> > _move_barrelRelease_lift_outOfRange
> > I "contact" the main tip, press "barrel" (which is the button nearest
> > of the tip), move the pen, release the button, move it out of range.
> >
> > (3) hidraw7_inRange_contact_erasePress\
> > _move_eraseRelease_lift_outOfRange
> > The same than above, except that I instead use the "erase" button,
> > i.e. the button just above ("vertically speaking") of the "main" button.
> >
> > (4) hidraw7_inRange_contact_BOTHbarrelAnderasePress_move_\
> > BOTHbarrelAnderaseRelease_lift_outOfRange
> > That's just plain stupid, and uncomfortable to do, but it's just to
> > show an example of the capability of the hardware ;
> > In this one, I'm doing the same than above, except I stupidly press BOTH
> > buttons.
> > It means that I "contact" the main tip, press both barrel+erase, move
> > the pen, release both button, lift it out of range.
> >
> > (5) hidraw7_inRange_contact_backPress_move_backRelease_lift_outOfRange
> > Back to non-stupid tests, here I am using the "rubber" (which has
> > pressure !), i.e. I use the back of the pen.
> > I contact it, press the rubber to have some pressure, move it, release
> > the pressure, move the pen ouf of contact and out of range.
> >
> > Reading those traces, I think I observed some (to me) very logical
> > behavior ;
> >
> > I agree that the Pen is possibly not acting in respect of the
> > specification, by the fact that... the spec does not differentiate the
> > "eraser" 2nd button, versus the "backside" rubber pressure tip.
> >
> > The traces shows that :
> > - In range [0 - 1] is correctly reported, both for main tip + rubber tip
> > - Tip Pressure [0 - n] is correctly reported, for both pressure tips
>
> Yep, that part is correct and follows the specification
>
> >
> > - Tip Switch [0 - 1] is correctly set to ONE for all traces, when the
> > in-range tip goes to contact. (either main tip or rubber tip)
>
> This is half wrong (spec-wise):
> - tip switch should only be used when the actual tip is in contact.
> - when using the rubber tip, we should get an eraser event :(
>
> >
> > - Barrel Switch [0 - 1] is correctly set to ONE only when pressing
> > button down, and of course only when using the main tip
>
> This is correct (as in it follows the spec)
>
> >
> > - Invert [0 - 1] is set to ONE when (and only) using the back rubber
> > tip, and the ERASE button (2nd button) does NOT set it, so "INVERT"
>
> In your case, the invert usage is correct.
> In Illia's case, the invert usage is forwarded by the eraser usage, so
> this is just plain wrong there.
>
> >
> > - Eraser [0 - 1] is set to ONE ONLY when pressing the 2nd top button,
> > and of :
> > - ONLY when using the main itp
> > - and if you were to instead use the "back" of the pen (rubber tip),
> > then you will have invert=1 + eraser=0
>
> This is not correct (again, according to the specification). XP-Pen
> should report SecondaryBarrelSwitch (0x5a in the HID usage table[0])
> And again, in Illia's case, this button should be reported as an
> invert, and eraser when the tip touches the tablet.
>
> >
> > The main extract of those is, I think, that :
> > - eraser "top" button is completely independent of the back "rubber"
>
> Yes
>
> > - eraser "top" button NEVER concerns itself to set invert=1
>
> yes
>
> > - backside "rubber" pressure tip will set invert=1, but leave eraser=0
>
> yes, but that's not correct, it should report eraser=1 when you touch
> the rubber on the surface.
>
> >
> > So, the behavior probably breaks the specs, but sincerely I'm happy to
> > have the "eraser" button independent of the "rubber eraser", which
> > makes the stylus a somewhat 4-buttons stylus (tip, button1, button2,
> > rubber), and I would like to keep this.
>
> Yes, and I'd like to keep it that way, even if 6.6 and 6.5.8
> apparently broke it.
>
> So, to me:
> - 276e14e6c3993317257e1787e93b7166fbc30905 is wrong: this is a
> firmware bug (reporting invert through eraser) and should not be
> tackled at the generic level, thus it should be reverted
> - both of these tablets are forwarding the useful information, but not
> correctly, which confuses the kernel
> - I should now be able to write regression tests
> - I should be able to provide HID-BPF fixes for those tablets so that
> we can keep them working with or without
> 276e14e6c3993317257e1787e93b7166fbc30905
> reverted (hopefully)
> - problem is I still don't have the mechanics to integrate the HID-BPF
> fixes directly in the kernel tree, so maybe I'll have to write a
> driver for XP-Pen while these internals are set (it shouldn't
> interfere with the HID-BPF out of the tree).
I already added support for a few XP-Pen devices on the UCLogic driver
and I was planning to start working on this one during the weekend in
my DIGImend fork (to simplify testing).
Let me know if you prefer to add it yourself or if you want me to ping
you in the DIGImend discussion.
José Expósito
>
> Cheers,
> Benjamin
>
> >
> > Best Regards,
> >
> > [1] https://www.xp-pen.fr/download-1027.html ; the .deb Qt app
> >
> > --
> > Eric GOUYER
> >
>
> [0] https://usb.org/document-library/hid-usage-tables-14
>
^ 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