* Re: [PATCH] HID: steam: use hid_device.driver_data instead of hid_set_drvdata()
From: Rodrigo Rivas Costa @ 2018-06-01 18:27 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Pierre-Loup A. Griffais,
Clément VUCHENER, lkml, linux-input
In-Reply-To: <20180522201006.14003-1-rodrigorivascosta@gmail.com>
Hi, all!
Could you check my previous patch to see if it makes any sense?
My machine currently crashes without it, but I'm not sure why. If you
think it is worth it I can try and bisect it.
Regards
--
Rodrigo Rivas Costa.
On Tue, May 22, 2018 at 10:10:06PM +0200, Rodrigo Rivas Costa wrote:
> When creating the low-level hidraw device, the reference to steam_device
> was stored using hid_set_drvdata(). But this value is not guaranteed to
> be kept when set before calling probe. If this pointer is reset, it
> crashes when opening the emulated hidraw device.
>
> It looks like hid_set_drvdata() is for users "avobe" this hid_device,
> while hid_device.driver_data it for users "below" this one.
>
> In this case, we are creating a virtual hidraw device, so we must use
> hid_device.driver_data.
>
> Signed-off-by: Rodrigo Rivas Costa <rodrigorivascosta@gmail.com>
> ---
>
> This patch is to be applied over hid/for-4.18/hid-steam. Is this the
> proper way to signal it?
>
> I don't know exactly when the problem started. I am pretty sure that it
> worked with 4.16.2, but it failed with 4.16.9. Or maybe it is caused by
> upgrading the firmware of the controller, although the protocol seems
> identical.
>
> drivers/hid/hid-steam.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hid/hid-steam.c b/drivers/hid/hid-steam.c
> index cb86cc834201..0422ec2b13d2 100644
> --- a/drivers/hid/hid-steam.c
> +++ b/drivers/hid/hid-steam.c
> @@ -573,7 +573,7 @@ static bool steam_is_valve_interface(struct hid_device *hdev)
>
> static int steam_client_ll_parse(struct hid_device *hdev)
> {
> - struct steam_device *steam = hid_get_drvdata(hdev);
> + struct steam_device *steam = hdev->driver_data;
>
> return hid_parse_report(hdev, steam->hdev->dev_rdesc,
> steam->hdev->dev_rsize);
> @@ -590,7 +590,7 @@ static void steam_client_ll_stop(struct hid_device *hdev)
>
> static int steam_client_ll_open(struct hid_device *hdev)
> {
> - struct steam_device *steam = hid_get_drvdata(hdev);
> + struct steam_device *steam = hdev->driver_data;
> int ret;
>
> ret = hid_hw_open(steam->hdev);
> @@ -605,7 +605,7 @@ static int steam_client_ll_open(struct hid_device *hdev)
>
> static void steam_client_ll_close(struct hid_device *hdev)
> {
> - struct steam_device *steam = hid_get_drvdata(hdev);
> + struct steam_device *steam = hdev->driver_data;
>
> mutex_lock(&steam->mutex);
> steam->client_opened = false;
> @@ -623,7 +623,7 @@ static int steam_client_ll_raw_request(struct hid_device *hdev,
> size_t count, unsigned char report_type,
> int reqtype)
> {
> - struct steam_device *steam = hid_get_drvdata(hdev);
> + struct steam_device *steam = hdev->driver_data;
>
> return hid_hw_raw_request(steam->hdev, reportnum, buf, count,
> report_type, reqtype);
> @@ -710,7 +710,7 @@ static int steam_probe(struct hid_device *hdev,
> ret = PTR_ERR(steam->client_hdev);
> goto client_hdev_fail;
> }
> - hid_set_drvdata(steam->client_hdev, steam);
> + steam->client_hdev->driver_data = steam;
>
> /*
> * With the real steam controller interface, do not connect hidraw.
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH] i8042: Increment wakeup_count for the respective port.
From: Ravi Chandra Sadineni @ 2018-06-01 18:00 UTC (permalink / raw)
To: dmitry.torokhov, chenhong3, ravisadineni, ravisadineni, dtor
Cc: tbroch, linux-kernel, linux-input, rajatja, bleung
Call pm_wakeup_event on every irq. This should help us in identifying if
i8042 port was a potential wake reason for the last resume.
Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org>
---
drivers/input/serio/i8042.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 824f4c1c1f310..96e27766d553d 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -573,6 +573,9 @@ static irqreturn_t i8042_interrupt(int irq, void *dev_id)
port = &i8042_ports[port_no];
serio = port->exists ? port->serio : NULL;
+ if (serio && device_may_wakeup(&serio->dev))
+ pm_wakeup_event(&serio->dev, 0);
+
filter_dbg(port->driver_bound, data, "<- i8042 (interrupt, %d, %d%s%s)\n",
port_no, irq,
dfl & SERIO_PARITY ? ", bad parity" : "",
--
2.17.0.921.gf22659ad46-goog
^ permalink raw reply related
* Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches
From: Benjamin Tissoires @ 2018-06-01 14:16 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jiri Kosina, Henrik Rydberg, Jason Gerecke, Dennis Kempin,
Andrew de los Reyes, open list:HID CORE LAYER, lkml
In-Reply-To: <20170811004500.13740-1-dmitry.torokhov@gmail.com>
On Fri, Aug 11, 2017 at 2:44 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> According to Microsoft specification [1] for Precision Touchpads (and
> Touchscreens) the devices use "confidence" reports to signal accidental
> touches, or contacts that are "too large to be a finger". Instead of
> simply marking contact inactive in this case (which causes issues if
> contact was originally proper and we lost confidence in it later, as
> this results in accidental clicks, drags, etc), let's report such
> contacts as MT_TOOL_PALM and let userspace decide what to do.
> Additionally, let's report contact size for such touches as maximum
> allowed for major/minor, which should help userspace that is not yet
> aware of MT_TOOL_PALM to still perform palm rejection.
>
> An additional complication, is that some firmwares do not report
> non-confident touches as active. To cope with this we delay release of
> such contact (i.e. if contact was active we first report it as still
> active MT+TOOL_PALM and then synthesize the release event in a separate
> frame).
I am not sure I agree with this part. The spec says that "Once a
device has determined that a contact is unintentional, it should clear
the confidence bit for that contact report and all subsequent
reports."
So in theory the spec says that if a touch has been detected as a
palm, the flow of events should not stop (tested on the PTP of the
Dell XPS 9360).
However, I interpret a firmware that send (confidence 1, tip switch 1)
and then (confidence 0, tip switch 0) a simple release, and the
confidence bit should not be relayed.
Do you have any precise example of reports where you need that feature?
Cheers,
Benjamin
>
> [1] https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/hid/hid-multitouch.c | 86 +++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 77 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 440b999304a5..c28defe50a10 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -114,6 +114,8 @@ struct mt_device {
> struct timer_list release_timer; /* to release sticky fingers */
> struct mt_fields *fields; /* temporary placeholder for storing the
> multitouch fields */
> + unsigned long *pending_palm_slots; /* slots where we reported palm
> + and need to release */
> unsigned long mt_io_flags; /* mt flags (MT_IO_FLAGS_*) */
> int cc_index; /* contact count field index in the report */
> int cc_value_index; /* contact count value index in the field */
> @@ -543,8 +545,12 @@ static int mt_touch_input_mapping(struct hid_device *hdev, struct hid_input *hi,
> case HID_DG_CONFIDENCE:
> if ((cls->name == MT_CLS_WIN_8 ||
> cls->name == MT_CLS_WIN_8_DUAL) &&
> - field->application == HID_DG_TOUCHPAD)
> + field->application == HID_DG_TOUCHPAD) {
> cls->quirks |= MT_QUIRK_CONFIDENCE;
> + input_set_abs_params(hi->input,
> + ABS_MT_TOOL_TYPE,
> + MT_TOOL_FINGER, MT_TOOL_PALM, 0, 0);
> + }
> mt_store_field(usage, td, hi);
> return 1;
> case HID_DG_TIPSWITCH:
> @@ -657,6 +663,7 @@ static void mt_complete_slot(struct mt_device *td, struct input_dev *input)
>
> if (td->curvalid || (td->mtclass.quirks & MT_QUIRK_ALWAYS_VALID)) {
> int active;
> + int tool;
> int slotnum = mt_compute_slot(td, input);
> struct mt_slot *s = &td->curdata;
> struct input_mt *mt = input->mt;
> @@ -671,24 +678,56 @@ static void mt_complete_slot(struct mt_device *td, struct input_dev *input)
> return;
> }
>
> + active = s->touch_state || s->inrange_state;
> +
> if (!(td->mtclass.quirks & MT_QUIRK_CONFIDENCE))
> s->confidence_state = 1;
> - active = (s->touch_state || s->inrange_state) &&
> - s->confidence_state;
> +
> + if (likely(s->confidence_state)) {
> + tool = MT_TOOL_FINGER;
> + } else {
> + tool = MT_TOOL_PALM;
> + if (!active &&
> + input_mt_is_active(&mt->slots[slotnum])) {
> + /*
> + * The non-confidence was reported for
> + * previously valid contact that is also no
> + * longer valid. We can't simply report
> + * lift-off as userspace will not be aware
> + * of non-confidence, so we need to split
> + * it into 2 events: active MT_TOOL_PALM
> + * and a separate liftoff.
> + */
> + active = true;
> + set_bit(slotnum, td->pending_palm_slots);
> + }
> + }
>
> input_mt_slot(input, slotnum);
> - input_mt_report_slot_state(input, MT_TOOL_FINGER, active);
> + input_mt_report_slot_state(input, tool, active);
> if (active) {
> /* this finger is in proximity of the sensor */
> int wide = (s->w > s->h);
> int major = max(s->w, s->h);
> int minor = min(s->w, s->h);
>
> - /*
> - * divided by two to match visual scale of touch
> - * for devices with this quirk
> - */
> - if (td->mtclass.quirks & MT_QUIRK_TOUCH_SIZE_SCALING) {
> + if (unlikely(!s->confidence_state)) {
> + /*
> + * When reporting palm, set contact to maximum
> + * size to help userspace that does not
> + * recognize MT_TOOL_PALM to reject contacts
> + * that are too large.
> + */
> + major = input_abs_get_max(input,
> + ABS_MT_TOUCH_MAJOR);
> + minor = input_abs_get_max(input,
> + ABS_MT_TOUCH_MINOR);
> + } else if (td->mtclass.quirks &
> + MT_QUIRK_TOUCH_SIZE_SCALING) {
> + /*
> + * divided by two to match visual scale of touch
> + * for devices with this quirk
> + */
> major = major >> 1;
> minor = minor >> 1;
> }
> @@ -711,6 +750,25 @@ static void mt_complete_slot(struct mt_device *td, struct input_dev *input)
> td->num_received++;
> }
>
> +static void mt_release_pending_palms(struct mt_device *td,
> + struct input_dev *input)
> +{
> + int slotnum;
> + bool need_sync = false;
> +
> + for_each_set_bit(slotnum, td->pending_palm_slots, td->maxcontacts) {
> + clear_bit(slotnum, td->pending_palm_slots);
> +
> + input_mt_slot(input, slotnum);
> + input_mt_report_slot_state(input, MT_TOOL_PALM, false);
> +
> + need_sync = true;
> + }
> +
> + if (need_sync)
> + input_sync(input);
> +}
> +
> /*
> * this function is called when a whole packet has been received and processed,
> * so that it can decide what to send to the input layer.
> @@ -719,6 +777,9 @@ static void mt_sync_frame(struct mt_device *td, struct input_dev *input)
> {
> input_mt_sync_frame(input);
> input_sync(input);
> +
> + mt_release_pending_palms(td, input);
> +
> td->num_received = 0;
> if (test_bit(MT_IO_FLAGS_ACTIVE_SLOTS, &td->mt_io_flags))
> set_bit(MT_IO_FLAGS_PENDING_SLOTS, &td->mt_io_flags);
> @@ -903,6 +964,13 @@ static int mt_touch_input_configured(struct hid_device *hdev,
> if (td->is_buttonpad)
> __set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
>
> + td->pending_palm_slots = devm_kcalloc(&hi->input->dev,
> + BITS_TO_LONGS(td->maxcontacts),
> + sizeof(long),
> + GFP_KERNEL);
> + if (!td->pending_palm_slots)
> + return -ENOMEM;
> +
> ret = input_mt_init_slots(input, td->maxcontacts, td->mt_flags);
> if (ret)
> return ret;
> --
> 2.14.0.434.g98096fd7a8-goog
>
^ permalink raw reply
* Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches
From: Benjamin Tissoires @ 2018-06-01 9:31 UTC (permalink / raw)
To: Peter Hutterer
Cc: Dmitry Torokhov, Jiri Kosina, Henrik Rydberg, Jason Gerecke,
Dennis Kempin, Andrew de los Reyes, open list:HID CORE LAYER,
lkml
In-Reply-To: <20180530231208.GA19976@jelly>
On Thu, May 31, 2018 at 1:12 AM, Peter Hutterer
<peter.hutterer@who-t.net> wrote:
> Hi Dmitry,
>
> On Thu, Aug 10, 2017 at 05:44:59PM -0700, Dmitry Torokhov wrote:
>> According to Microsoft specification [1] for Precision Touchpads (and
>> Touchscreens) the devices use "confidence" reports to signal accidental
>> touches, or contacts that are "too large to be a finger". Instead of
>> simply marking contact inactive in this case (which causes issues if
>> contact was originally proper and we lost confidence in it later, as
>> this results in accidental clicks, drags, etc), let's report such
>> contacts as MT_TOOL_PALM and let userspace decide what to do.
>> Additionally, let's report contact size for such touches as maximum
>> allowed for major/minor, which should help userspace that is not yet
>> aware of MT_TOOL_PALM to still perform palm rejection.
>>
>> An additional complication, is that some firmwares do not report
>> non-confident touches as active. To cope with this we delay release of
>> such contact (i.e. if contact was active we first report it as still
>> active MT+TOOL_PALM and then synthesize the release event in a separate
>> frame).
>>
>> [1] https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection
>>
>> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> This one popped up again in a bug report [1] and it looks like it never
> got merged. fwiw, libinput does support ABS_MT_TOOL_PALM for touchpads as of
> 1.8.0 and just releasing the touch causes fake taps. So you have the green
> light from me to merge this :)
>
> Cheers,
> Peter
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=106716
I can probably integrate this one in the hid-multitouch revamp I am
making, to avoid other the pain of rebasing.
Cheers,
Benjamin
>
>> ---
>> drivers/hid/hid-multitouch.c | 86 +++++++++++++++++++++++++++++++++++++++-----
>> 1 file changed, 77 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
>> index 440b999304a5..c28defe50a10 100644
>> --- a/drivers/hid/hid-multitouch.c
>> +++ b/drivers/hid/hid-multitouch.c
>> @@ -114,6 +114,8 @@ struct mt_device {
>> struct timer_list release_timer; /* to release sticky fingers */
>> struct mt_fields *fields; /* temporary placeholder for storing the
>> multitouch fields */
>> + unsigned long *pending_palm_slots; /* slots where we reported palm
>> + and need to release */
>> unsigned long mt_io_flags; /* mt flags (MT_IO_FLAGS_*) */
>> int cc_index; /* contact count field index in the report */
>> int cc_value_index; /* contact count value index in the field */
>> @@ -543,8 +545,12 @@ static int mt_touch_input_mapping(struct hid_device *hdev, struct hid_input *hi,
>> case HID_DG_CONFIDENCE:
>> if ((cls->name == MT_CLS_WIN_8 ||
>> cls->name == MT_CLS_WIN_8_DUAL) &&
>> - field->application == HID_DG_TOUCHPAD)
>> + field->application == HID_DG_TOUCHPAD) {
>> cls->quirks |= MT_QUIRK_CONFIDENCE;
>> + input_set_abs_params(hi->input,
>> + ABS_MT_TOOL_TYPE,
>> + MT_TOOL_FINGER, MT_TOOL_PALM, 0, 0);
>> + }
>> mt_store_field(usage, td, hi);
>> return 1;
>> case HID_DG_TIPSWITCH:
>> @@ -657,6 +663,7 @@ static void mt_complete_slot(struct mt_device *td, struct input_dev *input)
>>
>> if (td->curvalid || (td->mtclass.quirks & MT_QUIRK_ALWAYS_VALID)) {
>> int active;
>> + int tool;
>> int slotnum = mt_compute_slot(td, input);
>> struct mt_slot *s = &td->curdata;
>> struct input_mt *mt = input->mt;
>> @@ -671,24 +678,56 @@ static void mt_complete_slot(struct mt_device *td, struct input_dev *input)
>> return;
>> }
>>
>> + active = s->touch_state || s->inrange_state;
>> +
>> if (!(td->mtclass.quirks & MT_QUIRK_CONFIDENCE))
>> s->confidence_state = 1;
>> - active = (s->touch_state || s->inrange_state) &&
>> - s->confidence_state;
>> +
>> + if (likely(s->confidence_state)) {
>> + tool = MT_TOOL_FINGER;
>> + } else {
>> + tool = MT_TOOL_PALM;
>> + if (!active &&
>> + input_mt_is_active(&mt->slots[slotnum])) {
>> + /*
>> + * The non-confidence was reported for
>> + * previously valid contact that is also no
>> + * longer valid. We can't simply report
>> + * lift-off as userspace will not be aware
>> + * of non-confidence, so we need to split
>> + * it into 2 events: active MT_TOOL_PALM
>> + * and a separate liftoff.
>> + */
>> + active = true;
>> + set_bit(slotnum, td->pending_palm_slots);
>> + }
>> + }
>>
>> input_mt_slot(input, slotnum);
>> - input_mt_report_slot_state(input, MT_TOOL_FINGER, active);
>> + input_mt_report_slot_state(input, tool, active);
>> if (active) {
>> /* this finger is in proximity of the sensor */
>> int wide = (s->w > s->h);
>> int major = max(s->w, s->h);
>> int minor = min(s->w, s->h);
>>
>> - /*
>> - * divided by two to match visual scale of touch
>> - * for devices with this quirk
>> - */
>> - if (td->mtclass.quirks & MT_QUIRK_TOUCH_SIZE_SCALING) {
>> + if (unlikely(!s->confidence_state)) {
>> + /*
>> + * When reporting palm, set contact to maximum
>> + * size to help userspace that does not
>> + * recognize MT_TOOL_PALM to reject contacts
>> + * that are too large.
>> + */
>> + major = input_abs_get_max(input,
>> + ABS_MT_TOUCH_MAJOR);
>> + minor = input_abs_get_max(input,
>> + ABS_MT_TOUCH_MINOR);
>> + } else if (td->mtclass.quirks &
>> + MT_QUIRK_TOUCH_SIZE_SCALING) {
>> + /*
>> + * divided by two to match visual scale of touch
>> + * for devices with this quirk
>> + */
>> major = major >> 1;
>> minor = minor >> 1;
>> }
>> @@ -711,6 +750,25 @@ static void mt_complete_slot(struct mt_device *td, struct input_dev *input)
>> td->num_received++;
>> }
>>
>> +static void mt_release_pending_palms(struct mt_device *td,
>> + struct input_dev *input)
>> +{
>> + int slotnum;
>> + bool need_sync = false;
>> +
>> + for_each_set_bit(slotnum, td->pending_palm_slots, td->maxcontacts) {
>> + clear_bit(slotnum, td->pending_palm_slots);
>> +
>> + input_mt_slot(input, slotnum);
>> + input_mt_report_slot_state(input, MT_TOOL_PALM, false);
>> +
>> + need_sync = true;
>> + }
>> +
>> + if (need_sync)
>> + input_sync(input);
>> +}
>> +
>> /*
>> * this function is called when a whole packet has been received and processed,
>> * so that it can decide what to send to the input layer.
>> @@ -719,6 +777,9 @@ static void mt_sync_frame(struct mt_device *td, struct input_dev *input)
>> {
>> input_mt_sync_frame(input);
>> input_sync(input);
>> +
>> + mt_release_pending_palms(td, input);
>> +
>> td->num_received = 0;
>> if (test_bit(MT_IO_FLAGS_ACTIVE_SLOTS, &td->mt_io_flags))
>> set_bit(MT_IO_FLAGS_PENDING_SLOTS, &td->mt_io_flags);
>> @@ -903,6 +964,13 @@ static int mt_touch_input_configured(struct hid_device *hdev,
>> if (td->is_buttonpad)
>> __set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
>>
>> + td->pending_palm_slots = devm_kcalloc(&hi->input->dev,
>> + BITS_TO_LONGS(td->maxcontacts),
>> + sizeof(long),
>> + GFP_KERNEL);
>> + if (!td->pending_palm_slots)
>> + return -ENOMEM;
>> +
>> ret = input_mt_init_slots(input, td->maxcontacts, td->mt_flags);
>> if (ret)
>> return ret;
>> --
>> 2.14.0.434.g98096fd7a8-goog
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-input" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply
* [PATCH v1 3/3] Input: evdev - Switch to bitmap_zalloc()
From: Andy Shevchenko @ 2018-06-01 8:31 UTC (permalink / raw)
To: Dmitry Torokhov, Jeffy Chen, linux-input, linux-kernel; +Cc: Andy Shevchenko
In-Reply-To: <20180601083120.40352-1-andriy.shevchenko@linux.intel.com>
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/input/evdev.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index c81c79d01d93..3f87ef973bc7 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -481,7 +481,7 @@ static int evdev_release(struct inode *inode, struct file *file)
evdev_detach_client(evdev, client);
for (i = 0; i < EV_CNT; ++i)
- kfree(client->evmasks[i]);
+ bitmap_free(client->evmasks[i]);
kvfree(client);
@@ -925,17 +925,15 @@ static int evdev_handle_get_val(struct evdev_client *client,
{
int ret;
unsigned long *mem;
- size_t len;
- len = BITS_TO_LONGS(maxbit) * sizeof(unsigned long);
- mem = kmalloc(len, GFP_KERNEL);
+ mem = bitmap_malloc(maxbit, GFP_KERNEL);
if (!mem)
return -ENOMEM;
spin_lock_irq(&dev->event_lock);
spin_lock(&client->buffer_lock);
- memcpy(mem, bits, len);
+ bitmap_copy(mem, bits, maxbit);
spin_unlock(&dev->event_lock);
@@ -947,7 +945,7 @@ static int evdev_handle_get_val(struct evdev_client *client,
if (ret < 0)
evdev_queue_syn_dropped(client);
- kfree(mem);
+ bitmap_free(mem);
return ret;
}
@@ -1003,13 +1001,13 @@ static int evdev_set_mask(struct evdev_client *client,
if (!cnt)
return 0;
- mask = kcalloc(sizeof(unsigned long), BITS_TO_LONGS(cnt), GFP_KERNEL);
+ mask = bitmap_zalloc(cnt, GFP_KERNEL);
if (!mask)
return -ENOMEM;
error = bits_from_user(mask, cnt - 1, codes_size, codes, compat);
if (error < 0) {
- kfree(mask);
+ bitmap_free(mask);
return error;
}
@@ -1018,7 +1016,7 @@ static int evdev_set_mask(struct evdev_client *client,
client->evmasks[type] = mask;
spin_unlock_irqrestore(&client->buffer_lock, flags);
- kfree(oldmask);
+ bitmap_free(oldmask);
return 0;
}
--
2.17.0
^ permalink raw reply related
* [PATCH v1 2/3] Input: gpio-keys - Switch to bitmap_zalloc()
From: Andy Shevchenko @ 2018-06-01 8:31 UTC (permalink / raw)
To: Dmitry Torokhov, Jeffy Chen, linux-input, linux-kernel; +Cc: Andy Shevchenko
In-Reply-To: <20180601083120.40352-1-andriy.shevchenko@linux.intel.com>
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/input/keyboard/gpio_keys.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
index 052e37675086..492a971b95b5 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -196,7 +196,7 @@ static ssize_t gpio_keys_attr_show_helper(struct gpio_keys_drvdata *ddata,
ssize_t ret;
int i;
- bits = kcalloc(BITS_TO_LONGS(n_events), sizeof(*bits), GFP_KERNEL);
+ bits = bitmap_zalloc(n_events, GFP_KERNEL);
if (!bits)
return -ENOMEM;
@@ -216,7 +216,7 @@ static ssize_t gpio_keys_attr_show_helper(struct gpio_keys_drvdata *ddata,
buf[ret++] = '\n';
buf[ret] = '\0';
- kfree(bits);
+ bitmap_free(bits);
return ret;
}
@@ -240,7 +240,7 @@ static ssize_t gpio_keys_attr_store_helper(struct gpio_keys_drvdata *ddata,
ssize_t error;
int i;
- bits = kcalloc(BITS_TO_LONGS(n_events), sizeof(*bits), GFP_KERNEL);
+ bits = bitmap_zalloc(n_events, GFP_KERNEL);
if (!bits)
return -ENOMEM;
@@ -284,7 +284,7 @@ static ssize_t gpio_keys_attr_store_helper(struct gpio_keys_drvdata *ddata,
mutex_unlock(&ddata->disable_lock);
out:
- kfree(bits);
+ bitmap_free(bits);
return error;
}
--
2.17.0
^ permalink raw reply related
* [PATCH v1 1/3] bitmap: Add bitmap_alloc(), bitmap_zalloc() and bitmap_free()
From: Andy Shevchenko @ 2018-06-01 8:31 UTC (permalink / raw)
To: Dmitry Torokhov, Jeffy Chen, linux-input, linux-kernel; +Cc: Andy Shevchenko
A lot of code become ugly because of open coding allocations for bitmaps.
Introduce three helpers to allow users be more clear of intention
and keep their code neat.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
include/linux/bitmap.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 1ee46f492267..845822425393 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -6,6 +6,7 @@
#include <linux/types.h>
#include <linux/bitops.h>
+#include <linux/slab.h>
#include <linux/string.h>
#include <linux/kernel.h>
@@ -104,6 +105,21 @@
* contain all bit positions from 0 to 'bits' - 1.
*/
+static inline unsigned long *bitmap_alloc(unsigned int nbits, gfp_t flags)
+{
+ return kmalloc_array(BITS_TO_LONGS(nbits), sizeof(unsigned long), flags);
+}
+
+static inline unsigned long *bitmap_zalloc(unsigned int nbits, gfp_t flags)
+{
+ return kcalloc(BITS_TO_LONGS(nbits), sizeof(unsigned long), flags);
+}
+
+static inline void bitmap_free(const unsigned long *bitmap)
+{
+ kfree(bitmap);
+}
+
/*
* lib/bitmap.c provides these functions:
*/
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v4] xpad: Add GPD Win 2 Controller USB IDs
From: Dmitry Torokhov @ 2018-05-31 17:10 UTC (permalink / raw)
To: Ethan Lee
Cc: linux-input@vger.kernel.org, Bastien Nocera, Cameron Gutman,
Benjamin Tissoires
In-Reply-To: <192ae554-497b-2597-90d9-ecd242b5105a@gmail.com>
Hi Ethan,
- stable@ to BCC
On Thu, May 31, 2018 at 5:12 AM, Ethan Lee <flibitijibibo@gmail.com> wrote:
> Aaand right as I send these I see git-send-email auto-CC'd stable directly
> again. Sorry!
>
> -Ethan
>
>
> On 05/31/2018 08:10 AM, flibitijibibo@gmail.com wrote:
>>
>> From: Ethan Lee <flibitijibibo@gmail.com>
>>
>> GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp
>>
>> Tested on a unit from the first production run sent to Indiegogo backers
So I understand that adding this new VID/PID pair to the xpad driver
makes controller recognize the device,
but the button/axis mapping is not what it should be. Does it mean
that the mapping is different from other xpad controllers, or the
mapping that we are using is messed up for all/most of them?
It looks like the mapping we use is quite a mess, I wonder if we could
not bite the bullet and unify it so it follows
Documentation/input/gamepad.rst... I would make users update their
existing configs, but the new installations would be more sensible.
Just a thought... Or you could tell me that nobody pays attention to
what kernel sends and everyone remaps anyway...
>>
>> Signed-off-by: Ethan Lee <flibitijibibo@gmail.com>
>> Cc: stable@vger.kernel.org
>> ---
>> drivers/input/joystick/xpad.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
>> index 06e9650b3b30..a89b81b35932 100644
>> --- a/drivers/input/joystick/xpad.c
>> +++ b/drivers/input/joystick/xpad.c
>> @@ -123,6 +123,7 @@ static const struct xpad_device {
>> u8 mapping;
>> u8 xtype;
>> } xpad_device[] = {
>> + { 0x0079, 0x18d4, "GPD Win 2 Controller", 0, XTYPE_XBOX360 },
>> { 0x044f, 0x0f00, "Thrustmaster Wheel", 0, XTYPE_XBOX },
>> { 0x044f, 0x0f03, "Thrustmaster Wheel", 0, XTYPE_XBOX },
>> { 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX
>> },
>> @@ -409,6 +410,7 @@ static const signed short xpad_abs_triggers[] = {
>> static const struct usb_device_id xpad_table[] = {
>> { USB_INTERFACE_INFO('X', 'B', 0) }, /* X-Box USB-IF not
>> approved class */
>> + XPAD_XBOX360_VENDOR(0x0079), /* GPD Win 2 Controller */
>> XPAD_XBOX360_VENDOR(0x044f), /* Thrustmaster X-Box 360
>> controllers */
>> XPAD_XBOX360_VENDOR(0x045e), /* Microsoft X-Box 360
>> controllers */
>> XPAD_XBOXONE_VENDOR(0x045e), /* Microsoft X-Box One
>> controllers */
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4] xpad: Add GPD Win 2 Controller USB IDs
From: Ethan Lee @ 2018-05-31 12:12 UTC (permalink / raw)
To: linux-input; +Cc: hadess, aicommander, stable
In-Reply-To: <20180531121019.18228-1-flibitijibibo@gmail.com>
Aaand right as I send these I see git-send-email auto-CC'd stable
directly again. Sorry!
-Ethan
On 05/31/2018 08:10 AM, flibitijibibo@gmail.com wrote:
> From: Ethan Lee <flibitijibibo@gmail.com>
>
> GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp
>
> Tested on a unit from the first production run sent to Indiegogo backers
>
> Signed-off-by: Ethan Lee <flibitijibibo@gmail.com>
> Cc: stable@vger.kernel.org
> ---
> drivers/input/joystick/xpad.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index 06e9650b3b30..a89b81b35932 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -123,6 +123,7 @@ static const struct xpad_device {
> u8 mapping;
> u8 xtype;
> } xpad_device[] = {
> + { 0x0079, 0x18d4, "GPD Win 2 Controller", 0, XTYPE_XBOX360 },
> { 0x044f, 0x0f00, "Thrustmaster Wheel", 0, XTYPE_XBOX },
> { 0x044f, 0x0f03, "Thrustmaster Wheel", 0, XTYPE_XBOX },
> { 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX },
> @@ -409,6 +410,7 @@ static const signed short xpad_abs_triggers[] = {
>
> static const struct usb_device_id xpad_table[] = {
> { USB_INTERFACE_INFO('X', 'B', 0) }, /* X-Box USB-IF not approved class */
> + XPAD_XBOX360_VENDOR(0x0079), /* GPD Win 2 Controller */
> XPAD_XBOX360_VENDOR(0x044f), /* Thrustmaster X-Box 360 controllers */
> XPAD_XBOX360_VENDOR(0x045e), /* Microsoft X-Box 360 controllers */
> XPAD_XBOXONE_VENDOR(0x045e), /* Microsoft X-Box One controllers */
^ permalink raw reply
* [PATCH v3] goodix: Add new I2C/ACPI ids for GPD Win 2 touch screen
From: flibitijibibo @ 2018-05-31 12:10 UTC (permalink / raw)
To: linux-input; +Cc: hadess, Ethan Lee, stable
From: Ethan Lee <flibitijibibo@gmail.com>
GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp
Tested on a unit from the first production run sent to Indiegogo backers
Signed-off-by: Ethan Lee <flibitijibibo@gmail.com>
Cc: stable@vger.kernel.org
---
drivers/input/touchscreen/goodix.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
index 9736c83dd418..6a4ffe800194 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -926,6 +926,7 @@ static SIMPLE_DEV_PM_OPS(goodix_pm_ops, goodix_suspend, goodix_resume);
static const struct i2c_device_id goodix_ts_id[] = {
{ "GDIX1001:00", 0 },
+ { "GDIX1002:00", 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, goodix_ts_id);
@@ -933,6 +934,7 @@ MODULE_DEVICE_TABLE(i2c, goodix_ts_id);
#ifdef CONFIG_ACPI
static const struct acpi_device_id goodix_acpi_match[] = {
{ "GDIX1001", 0 },
+ { "GDIX1002", 0 },
{ }
};
MODULE_DEVICE_TABLE(acpi, goodix_acpi_match);
--
2.13.6
^ permalink raw reply related
* [PATCH v4] xpad: Add GPD Win 2 Controller USB IDs
From: flibitijibibo @ 2018-05-31 12:10 UTC (permalink / raw)
To: linux-input; +Cc: hadess, aicommander, Ethan Lee, stable
From: Ethan Lee <flibitijibibo@gmail.com>
GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp
Tested on a unit from the first production run sent to Indiegogo backers
Signed-off-by: Ethan Lee <flibitijibibo@gmail.com>
Cc: stable@vger.kernel.org
---
drivers/input/joystick/xpad.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 06e9650b3b30..a89b81b35932 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -123,6 +123,7 @@ static const struct xpad_device {
u8 mapping;
u8 xtype;
} xpad_device[] = {
+ { 0x0079, 0x18d4, "GPD Win 2 Controller", 0, XTYPE_XBOX360 },
{ 0x044f, 0x0f00, "Thrustmaster Wheel", 0, XTYPE_XBOX },
{ 0x044f, 0x0f03, "Thrustmaster Wheel", 0, XTYPE_XBOX },
{ 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX },
@@ -409,6 +410,7 @@ static const signed short xpad_abs_triggers[] = {
static const struct usb_device_id xpad_table[] = {
{ USB_INTERFACE_INFO('X', 'B', 0) }, /* X-Box USB-IF not approved class */
+ XPAD_XBOX360_VENDOR(0x0079), /* GPD Win 2 Controller */
XPAD_XBOX360_VENDOR(0x044f), /* Thrustmaster X-Box 360 controllers */
XPAD_XBOX360_VENDOR(0x045e), /* Microsoft X-Box 360 controllers */
XPAD_XBOXONE_VENDOR(0x045e), /* Microsoft X-Box One controllers */
--
2.13.6
^ permalink raw reply related
* [PATCH] HID: core: allow concurrent registration of drivers
From: Benjamin Tissoires @ 2018-05-31 11:49 UTC (permalink / raw)
To: Jiri Kosina, Mario.Limonciello
Cc: linux-input, linux-kernel, Benjamin Tissoires
Detected on the Dell XPS 9365.
The laptop has 2 devices that benefit from the hid-generic auto-unbinding.
When those 2 devices are presented to the userspace, udev loads both
wacom and hid-multitouch. When this happens, the code in
__hid_bus_reprobe_drivers() is called concurrently and the second device
gets reprobed twice.
An other bug in the power_supply subsystem prevent to remove the wacom
driver if it just finished its initialization, which basically kills
the wacom node.
Fixes c17a7476e4c4 ("HID: core: rewrite the hid-generic automatic unbind")
Cc: stable@vger.kernel.org # v4.17
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Hi Mario,
can you please test this on your faulty XPS?
I think it'll fix the issue, but I can not reproduce, so better wait for
your confirmation.
Jiri, ideally I would love to see this in v4.17 final, but Mario seems
to be on PTO until next week. I guess we'll just push this in v4.17.1
then. Also, if you can double check that it makes sense, that would be
nice :)
Cheers,
Benjamin
drivers/hid/hid-core.c | 5 ++++-
include/linux/hid.h | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 2f7367b1de00..7afed0c0f9e5 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1960,6 +1960,8 @@ static int hid_device_probe(struct device *dev)
}
hdev->io_started = false;
+ clear_bit(ffs(HID_STAT_REPROBED), &hdev->status);
+
if (!hdev->driver) {
id = hid_match_device(hdev, hdrv);
if (id == NULL) {
@@ -2223,7 +2225,8 @@ static int __hid_bus_reprobe_drivers(struct device *dev, void *data)
struct hid_device *hdev = to_hid_device(dev);
if (hdev->driver == hdrv &&
- !hdrv->match(hdev, hid_ignore_special_drivers))
+ !hdrv->match(hdev, hid_ignore_special_drivers) &&
+ !test_and_set_bit(ffs(HID_STAT_REPROBED), &hdev->status))
return device_reprobe(dev);
return 0;
diff --git a/include/linux/hid.h b/include/linux/hid.h
index ee2510019033..aee281522c6d 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -517,6 +517,7 @@ struct hid_output_fifo {
#define HID_STAT_ADDED BIT(0)
#define HID_STAT_PARSED BIT(1)
#define HID_STAT_DUP_DETECTED BIT(2)
+#define HID_STAT_REPROBED BIT(3)
struct hid_input {
struct list_head list;
@@ -585,7 +586,7 @@ struct hid_device { /* device report descriptor */
bool battery_avoid_query;
#endif
- unsigned int status; /* see STAT flags above */
+ unsigned long status; /* see STAT flags above */
unsigned claimed; /* Claimed by hidinput, hiddev? */
unsigned quirks; /* Various quirks the device can pull on us */
bool io_started; /* If IO has started */
--
2.14.3
^ permalink raw reply related
* [RESEND PATCH v4 2/2] input: misc: Add Spreadtrum vibrator driver
From: Baolin Wang @ 2018-05-31 10:34 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland
Cc: linux-input, devicetree, linux-kernel, baolin.wang, xiaotong.lu
In-Reply-To: <c315312e53fe50ab8da95bc00037a8f8b92f8d78.1527762429.git.baolin.wang@linaro.org>
From: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
This patch adds the Spreadtrum vibrator driver, which embedded in the
Spreadtrum SC27xx series PMICs.
Signed-off-by: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
Changes since v3:
- No updates.
Changes since v2:
- Fix the condition when disabling the vibrator.
- Change of_property_read_u32() to device_property_read_u32().
- Correct the device parent relationship.
- Call sc27xx_vibra_hw_init() before calling input_register_device().
- Remove platform_set_drvdata().
Changes since v1:
- Remove input_ff_destroy() and input_unregister_device()
---
drivers/input/misc/Kconfig | 10 +++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/sc27xx-vibra.c | 154 +++++++++++++++++++++++++++++++++++++
3 files changed, 165 insertions(+)
create mode 100644 drivers/input/misc/sc27xx-vibra.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 572b15f..c761c0c 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -841,4 +841,14 @@ config INPUT_RAVE_SP_PWRBUTTON
To compile this driver as a module, choose M here: the
module will be called rave-sp-pwrbutton.
+config INPUT_SC27XX_VIBRA
+ tristate "Spreadtrum sc27xx vibrator support"
+ depends on MFD_SC27XX_PMIC || COMPILE_TEST
+ select INPUT_FF_MEMLESS
+ help
+ This option enables support for Spreadtrum sc27xx vibrator driver.
+
+ To compile this driver as a module, choose M here. The module will
+ be called sc27xx_vibra.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 72cde28..9d0f9d1 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
obj-$(CONFIG_INPUT_AXP20X_PEK) += axp20x-pek.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER) += rotary_encoder.o
obj-$(CONFIG_INPUT_RK805_PWRKEY) += rk805-pwrkey.o
+obj-$(CONFIG_INPUT_SC27XX_VIBRA) += sc27xx-vibra.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
obj-$(CONFIG_INPUT_SIRFSOC_ONKEY) += sirfsoc-onkey.o
obj-$(CONFIG_INPUT_SOC_BUTTON_ARRAY) += soc_button_array.o
diff --git a/drivers/input/misc/sc27xx-vibra.c b/drivers/input/misc/sc27xx-vibra.c
new file mode 100644
index 0000000..295251a
--- /dev/null
+++ b/drivers/input/misc/sc27xx-vibra.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Spreadtrum Communications Inc.
+ */
+
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/input.h>
+#include <linux/workqueue.h>
+
+#define CUR_DRV_CAL_SEL GENMASK(13, 12)
+#define SLP_LDOVIBR_PD_EN BIT(9)
+#define LDO_VIBR_PD BIT(8)
+
+struct vibra_info {
+ struct input_dev *input_dev;
+ struct work_struct play_work;
+ struct regmap *regmap;
+ u32 base;
+ u32 strength;
+ bool enabled;
+};
+
+static void sc27xx_vibra_set(struct vibra_info *info, bool on)
+{
+ if (on) {
+ regmap_update_bits(info->regmap, info->base, LDO_VIBR_PD, 0);
+ regmap_update_bits(info->regmap, info->base,
+ SLP_LDOVIBR_PD_EN, 0);
+ info->enabled = true;
+ } else {
+ regmap_update_bits(info->regmap, info->base, LDO_VIBR_PD,
+ LDO_VIBR_PD);
+ regmap_update_bits(info->regmap, info->base,
+ SLP_LDOVIBR_PD_EN, SLP_LDOVIBR_PD_EN);
+ info->enabled = false;
+ }
+}
+
+static int sc27xx_vibra_hw_init(struct vibra_info *info)
+{
+ return regmap_update_bits(info->regmap, info->base, CUR_DRV_CAL_SEL, 0);
+}
+
+static void sc27xx_vibra_play_work(struct work_struct *work)
+{
+ struct vibra_info *info = container_of(work, struct vibra_info,
+ play_work);
+
+ if (info->strength && !info->enabled)
+ sc27xx_vibra_set(info, true);
+ else if (info->strength == 0 && info->enabled)
+ sc27xx_vibra_set(info, false);
+}
+
+static int sc27xx_vibra_play(struct input_dev *input, void *data,
+ struct ff_effect *effect)
+{
+ struct vibra_info *info = input_get_drvdata(input);
+
+ info->strength = effect->u.rumble.weak_magnitude;
+ schedule_work(&info->play_work);
+
+ return 0;
+}
+
+static void sc27xx_vibra_close(struct input_dev *input)
+{
+ struct vibra_info *info = input_get_drvdata(input);
+
+ cancel_work_sync(&info->play_work);
+ if (info->enabled)
+ sc27xx_vibra_set(info, false);
+}
+
+static int sc27xx_vibra_probe(struct platform_device *pdev)
+{
+ struct vibra_info *info;
+ int error;
+
+ info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ info->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+ if (!info->regmap) {
+ dev_err(&pdev->dev, "failed to get vibrator regmap.\n");
+ return -ENODEV;
+ }
+
+ error = device_property_read_u32(&pdev->dev, "reg", &info->base);
+ if (error) {
+ dev_err(&pdev->dev, "failed to get vibrator base address.\n");
+ return error;
+ }
+
+ info->input_dev = devm_input_allocate_device(&pdev->dev);
+ if (!info->input_dev) {
+ dev_err(&pdev->dev, "failed to allocate input device.\n");
+ return -ENOMEM;
+ }
+
+ info->input_dev->name = "sc27xx:vibrator";
+ info->input_dev->id.version = 0;
+ info->input_dev->close = sc27xx_vibra_close;
+
+ input_set_drvdata(info->input_dev, info);
+ input_set_capability(info->input_dev, EV_FF, FF_RUMBLE);
+ INIT_WORK(&info->play_work, sc27xx_vibra_play_work);
+ info->enabled = false;
+
+ error = sc27xx_vibra_hw_init(info);
+ if (error) {
+ dev_err(&pdev->dev, "failed to initialize the vibrator.\n");
+ return error;
+ }
+
+ error = input_ff_create_memless(info->input_dev, NULL,
+ sc27xx_vibra_play);
+ if (error) {
+ dev_err(&pdev->dev, "failed to register vibrator to FF.\n");
+ return error;
+ }
+
+ error = input_register_device(info->input_dev);
+ if (error) {
+ dev_err(&pdev->dev, "failed to register input device.\n");
+ return error;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id sc27xx_vibra_of_match[] = {
+ { .compatible = "sprd,sc2731-vibrator", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, sc27xx_vibra_of_match);
+
+static struct platform_driver sc27xx_vibra_driver = {
+ .driver = {
+ .name = "sc27xx-vibrator",
+ .of_match_table = sc27xx_vibra_of_match,
+ },
+ .probe = sc27xx_vibra_probe,
+};
+
+module_platform_driver(sc27xx_vibra_driver);
+
+MODULE_DESCRIPTION("Spreadtrum SC27xx Vibrator Driver");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Xiaotong Lu <xiaotong.lu@spreadtrum.com>");
--
1.7.9.5
^ permalink raw reply related
* [RESEND PATCH v4 1/2] dt-bindings: input: Add Add Spreadtrum SC27xx vibrator documentation
From: Baolin Wang @ 2018-05-31 10:34 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland
Cc: linux-input, devicetree, linux-kernel, baolin.wang, xiaotong.lu
From: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
This patch adds the binding documentation for Spreadtrum SC27xx series
vibrator device.
Signed-off-by: Xiaotong Lu <xiaotong.lu@spreadtrum.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes since v3:
- Change compatible string to explicit Soc name.
- Add parent MFD node.
Changes since v2:
- No updates.
Changes since v1:
- No updates.
---
.../bindings/input/sprd,sc27xx-vibra.txt | 23 ++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
diff --git a/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
new file mode 100644
index 0000000..f2ec0d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/sprd,sc27xx-vibra.txt
@@ -0,0 +1,23 @@
+Spreadtrum SC27xx PMIC Vibrator
+
+Required properties:
+- compatible: should be "sprd,sc2731-vibrator".
+- reg: address of vibrator control register.
+
+Example :
+
+ sc2731_pmic: pmic@0 {
+ compatible = "sprd,sc2731";
+ reg = <0>;
+ spi-max-frequency = <26000000>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vibrator@eb4 {
+ compatible = "sprd,sc2731-vibrator";
+ reg = <0xeb4>;
+ };
+ };
--
1.7.9.5
^ permalink raw reply related
* Re: Sometimes unusable i2c-hid devices in 4.17-rcX
From: Benjamin Tissoires @ 2018-05-31 10:00 UTC (permalink / raw)
To: Mario.Limonciello; +Cc: Jason Gerecke, linux-input, linux-kernel
In-Reply-To: <619ac9afa8dc40cca9ea490d88cf1232@ausx13mpc120.AMER.DELL.COM>
On Tue, May 29, 2018 at 10:56 PM <Mario.Limonciello@dell.com> wrote:
>
> > -----Original Message-----
> > From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> > Sent: Thursday, May 24, 2018 8:57 AM
> > To: Limonciello, Mario; Jason Gerecke
> > Cc: linux-input; linux-kernel@vger.kernel.org
> > Subject: Re: Sometimes unusable i2c-hid devices in 4.17-rcX
> >
> > Hi Mario,
> >
> > On Tue, May 22, 2018 at 6:15 PM, <Mario.Limonciello@dell.com> wrote:
> > > Benjamin,
> > >
> > >> -----Original Message-----
> > >> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> > >> Sent: Friday, May 18, 2018 1:18 PM
> > >> To: Limonciello, Mario
> > >> Cc: linux-input; linux-kernel@vger.kernel.org
> > >> Subject: Re: Sometimes unusable i2c-hid devices in 4.17-rcX
> > >>
> > >> On Thu, May 17, 2018 at 4:44 PM, <Mario.Limonciello@dell.com> wrote:
> > >> >> -----Original Message-----
> > >> >> From: Benjamin Tissoires [mailto:benjamin.tissoires@gmail.com]
> > >> >> Sent: Thursday, May 17, 2018 9:28 AM
> > >> >> To: Limonciello, Mario
> > >> >> Cc: linux-input; linux-kernel@vger.kernel.org
> > >> >> Subject: Re: Sometimes unusable i2c-hid devices in 4.17-rcX
> > >> >>
> > >> >> Hi Mario,
> > >> >>
> > >> >> On Wed, May 16, 2018 at 10:00 PM, <Mario.Limonciello@dell.com> wrote:
> > >> >> > Hi All,
> > >> >> >
> > >> >> > I've been running 4.16-rc7 on an XPS 9365 for some time and recently
> > moved
> > >> up
> > >> >> to 4.17-rc5.
> > >> >> > Immediately I noticed that i2c-hid devices (both touchscreen and touchpad)
> > >> were
> > >> >> not working.
> > >> >> > Also when shutting the system down or rebooting it would just hang. (magic
> > >> sysrq
> > >> >> still worked).
> > >> >> >
> > >> >> > I figured it was an easy to identify regression so I started a bisect but it
> > came
> > >> up
> > >> >> with garbage
> > >> >> > that ended in selftests shortly after 4.17-rc2. I realized that's because is still
> > >> will
> > >> >> fail on 4.17-rc2
> > >> >> > occasionally, seemingly after trying something newer and warm rebooting.
> > >> >> > So it seems like it's "worse" after 4.17-rc2 (doesn't work at all) but semi
> > >> >> reproducible on 4.17-rc2.
> > >> >> >
> > >> >> > Not sure if I'm chasing some initialization race, but wanted to see if anyone
> > >> else
> > >> >> was running into this
> > >> >> > or has some ideas?
> > >> >>
> > >> >> I am reliably running a v4.17-rc3 with a merge on Jiri's tree on the 9360.
> > >> >>
> > >> >> I doubt it's related to the event processing as I am not encountering
> > >> >> those issues.
> > >> >>
> > >> >> It *could* be related to the interrupts not being properly raised.
> > >> >>
> > >> >> Could you monitor /proc/interrupts and check if the ones associated
> > >> >> with your i2c-hid devices are increasing when you are using them?
> > >> >> Also, does the device emits raw HID events? (you can use hid-recorder
> > >> >> to check on the hidraw nodes.)
> > >> >
> > >>
> > >> Sorry, I couldn't get to it today. Monday is a public holiday here, so
> > >> I'll check on this Tuesday.
> > >>
> > >> > I checked both, /proc/interrupts isn't incrementing at all with the DLL077A:01
> > >> device.
> > >> > Hid-recorder is showing output from the raw HID node.
> > >>
> > >> I don't really understand how the hidraw node can send data while the
> > >> interrupts are not raised.
> > >>
> > >> Could you share the output of hid-recorder?
> > > Sure attached.
> > > Note that I had a dock connected at the same time since I needed power. This
> > was
> > > different than my previous tests.
> > > That dock has 2 HID endpoints (so that might muddy this, I can re-capture if you
> > need me to)
> >
> > According to the file, this is the touchpad, and you draw a quick
> > circle on it. It's surprising the interrupts are not incrementing
> > because it clearly works fine.
> >
> > >
> > >>
> > >> >
> > >> > Same thing for the touchscreen, no incrementing for it on the
> > i2c_designware.0
> > >> device.
> > >> >
> > >> > Something notable however;
> > >> > When in this bad state hid-recorder didn't show /dev/hidraw1 for the
> > >> touchscreen (which
> > >> > Happens to be a Wacom touch screen).
> > >> > It only showed /dev/hidraw0 for the touchpad.
> > >>
> > >> This explains why the touchscreen doesn't increment the interrupts.
> > >> Something I missed in the first email is that the hidraw0 node
> > >> disappear for the wacom device as the touchpad gets the hidraw0 name.
> > >>
> > >> Could you provide the output of a working kernel configuration of:
> > >> sudo hid-recorder /dev/hidraw*
> > >>
> > >> This should provide me the whole logs at the same time of all the
> > >> hidraw nodes, and will allow me to reproduce the combination of
> > >> wacom/hid-multitouch you are experiencing.
> > >>
> > > I was having a hard time getting it to work again with 4.17-rcX while trying
> > > to capture this.
> > > The only thing I got it to work with was when I turned off the touchscreen
> > > In FW setup.
> >
> > Yeah. Sorry I should have been more precise. Ideally, could you try to
> > capture all the hidraw nodes at once on a working kernel (4.16 or
> > 4.15)?
> > I shouldn't need the current broken behavior, just a description (with
> > some events) of the devices as they are supposed to be working.
> >
>
> Yes, here you go. This is with me touching both touchscreen and touchpad.
> It's on Ubuntu's 4.15.
Thanks a lot for the logs.
I think I found it. It's a combination of two bugs actually:
- the first one is a race when we load hid-multitouch and wacom in
parallel. Both drivers will call __hid_bus_driver_added() which will
reprobe the devices if they are still marked as handled by
hid-generic. However, the test appears to not be concurrent safe so we
are rebinding twice the wacom device (one after loading wacom.ko, and
one after loading hid-multitouch.ko)
- the second issue is one we came to realize a few days ago with
Richard Hughes. The wacom driver suffers from a bug in power_supply
where you can not unbind it right after having bound it, because
power_supply_unregister() wait for the completion of its init work
which takes teh lock on the device. However, when you unbind a driver,
the lock is already help, so you have a dead lock.
I am not sure I'll found a solution for the second issue right now. I
can't reproduce it locally with my test kernel :(
For the first solution, it should be easy enough to add a locking
mechanism to be sure we are not unibinding twice the device.
Note that if we hadn't the second issue, the first one would only show
dmesg logs, but the device would be working :/
Cheers,
Benjamin
>
> > >
> > > So I guess that means it's probably something Wacom race condition on
> > > initialization since you noted the hidraw endpoint getting clobbered.
> >
> > Still, it's curious the wacom module disappear without any message.
> > Jason, did you experienced such issues with some of the integrated
> > wacom panels on v4.17-rc3 and later?
> >
> > Cheers,
> > Benjamin
> >
> > >> >> >
> > >> >> > #dmesg | grep 'i2c\|hid' doesn't show any obvious errors when in this state
> > of
> > >> >> non functional hid stuff.
> > >> >> > [ 2.398649] i2c /dev entries driver
> > >> >> > [ 2.881651] hidraw: raw HID events driver (C) Jiri Kosina
> > >> >> > [ 3.683583] ish-hid {33AECD58-B679-4E54-9BD9-A04D34F0C226}: [hid-
> > ish]:
> > >> >> enum_devices_done OK, num_hid_devices=5
> > >> >> > [ 3.701259] hid-generic 001F:8086:22D8.0001: hidraw0: <UNKNOWN>
> > HID
> > >> >> v2.00 Device [hid-ishtp 8086:22D8] on
> > >> >> > [ 3.702204] hid-generic 001F:8086:22D8.0002: hidraw1: <UNKNOWN>
> > HID
> > >> >> v2.00 Device [hid-ishtp 8086:22D8] on
> > >> >> > [ 3.703063] hid-generic 001F:8086:22D8.0003: hidraw2: <UNKNOWN>
> > HID
> > >> >> v2.00 Device [hid-ishtp 8086:22D8] on
> > >> >> > [ 3.704276] hid-generic 001F:8086:22D8.0004: hidraw3: <UNKNOWN>
> > HID
> > >> >> v2.00 Device [hid-ishtp 8086:22D8] on
> > >> >> > [ 3.704557] hid-generic 001F:8086:22D8.0005: hidraw4: <UNKNOWN>
> > HID
> > >> >> v2.00 Device [hid-ishtp 8086:22D8] on
> > >> >> > [ 3.750710] psmouse serio1: synaptics: Your touchpad (PNP: DLL077a
> > >> 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.
> > >> >> > [ 7.030446] acpi INT33D5:00: intel-hid: created platform device
> > >> >> > [ 7.199178] i2c_hid i2c-WCOM482F:00: i2c-WCOM482F:00 supply vdd not
> > >> >> found, using dummy regulator
> > >> >> > [ 7.246638] input: WCOM482F:00 056A:482F as
> > >> >> /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-6/i2c-
> > >> >> WCOM482F:00/0018:056A:482F.0006/input/input11
> > >> >> > [ 7.246873] hid-generic 0018:056A:482F.0006: input,hidraw0: I2C HID
> > v1.00
> > >> >> Mouse [WCOM482F:00 056A:482F] on i2c-WCOM482F:00
> > >> >> > [ 7.275279] i2c_hid i2c-DLL077A:01: i2c-DLL077A:01 supply vdd not
> > found,
> > >> >> using dummy regulator
> > >> >> > [ 7.304107] input: DLL077A:01 06CB:76AF as
> > >> >> /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/i2c-
> > >> >> DLL077A:01/0018:06CB:76AF.0007/input/input14
> > >> >> > [ 7.304212] hid-generic 0018:06CB:76AF.0007: input,hidraw1: I2C HID
> > v1.00
> > >> >> Mouse [DLL077A:01 06CB:76AF] on i2c-DLL077A:01
> > >> >> > [ 7.657123] usbcore: registered new interface driver usbhid
> > >> >> > [ 7.657124] usbhid: USB HID core driver
> > >> >> > [ 7.722876] input: Wacom HID 482F Pen as
> > >> >> /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-6/i2c-
> > >> >> WCOM482F:00/0018:056A:482F.0006/input/input15
> > >> >> > [ 7.723148] input: Wacom HID 482F Finger as
> > >> >> /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-6/i2c-
> > >> >> WCOM482F:00/0018:056A:482F.0006/input/input16
> > >> >> > [ 7.723611] wacom 0018:056A:482F.0006: hidraw0: I2C HID v1.00 Mouse
> > >> >> [WCOM482F:00 056A:482F] on i2c-WCOM482F:00
> > >> >> > [ 7.768275] input: DLL077A:01 06CB:76AF Touchpad as
> > >> >> /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/i2c-
> > >> >> DLL077A:01/0018:06CB:76AF.0007/input/input19
> > >> >> > [ 7.864201] hid-multitouch 0018:06CB:76AF.0007: input,hidraw0: I2C HID
> > >> v1.00
> > >> >> Mouse [DLL077A:01 06CB:76AF] on i2c-DLL077A:01
> > >> >> >
> > >> >> > However in this state, I can't rmmod i2c-hid. It just hangs the system with
> > this
> > >> >> trace:
> > >> >> > [ 243.033779] INFO: task kworker/u8:0:6 blocked for more than 120
> > seconds.
> > >> >> > [ 243.033793] Not tainted 4.17.0-rc1+ #37
> > >> >> > [ 243.033798] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> > disables
> > >> this
> > >> >> message.
> > >> >> > [ 243.033804] kworker/u8:0 D 0 6 2 0x80000000
> > >> >> > [ 243.033826] Workqueue: events_power_efficient
> > >> >> power_supply_deferred_register_work
> > >> >> > [ 243.033832] Call Trace:
> > >> >> > [ 243.033850] __schedule+0x3c2/0x890
> > >> >> > [ 243.033861] ? __switch_to_asm+0x40/0x70
> > >> >> > [ 243.033868] schedule+0x36/0x80
> > >> >> > [ 243.033875] schedule_preempt_disabled+0xe/0x10
> > >> >> > [ 243.033882] __mutex_lock.isra.4+0x2ae/0x4e0
> > >> >> > [ 243.033890] ? __switch_to_asm+0x34/0x70
> > >> >> > [ 243.033899] ? __switch_to_asm+0x40/0x70
> > >> >> > [ 243.033906] ? __switch_to_asm+0x40/0x70
> > >> >> > [ 243.033914] __mutex_lock_slowpath+0x13/0x20
> > >> >> > [ 243.033920] ? __mutex_lock_slowpath+0x13/0x20
> > >> >> > [ 243.033927] mutex_lock+0x2f/0x40
> > >> >> > [ 243.033933] power_supply_deferred_register_work+0x2b/0x50
> > >> >> > [ 243.033944] process_one_work+0x148/0x3d0
> > >> >> > [ 243.033952] worker_thread+0x4b/0x460
> > >> >> > [ 243.033960] kthread+0x102/0x140
> > >> >> > [ 243.033967] ? rescuer_thread+0x380/0x380
> > >> >> > [ 243.033973] ? kthread_associate_blkcg+0xa0/0xa0
> > >> >> > [ 243.033982] ret_from_fork+0x35/0x40
> > >> >> > [ 243.034012] INFO: task systemd-udevd:308 blocked for more than 120
> > >> seconds.
> > >> >> > [ 243.034018] Not tainted 4.17.0-rc1+ #37
> > >> >> > [ 243.034022] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> > disables
> > >> this
> > >> >> message.
> > >> >> > [ 243.034027] systemd-udevd D 0 308 279 0x80000104
> > >> >> > [ 243.034033] Call Trace:
> > >> >> > [ 243.034041] __schedule+0x3c2/0x890
> > >> >> > [ 243.034049] schedule+0x36/0x80
> > >> >> > [ 243.034056] schedule_timeout+0x1e7/0x360
> > >> >> > [ 243.034066] ? ttwu_do_activate+0x77/0x80
> > >> >> > [ 243.034074] wait_for_completion+0xb4/0x140
> > >> >> > [ 243.034082] ? wake_up_q+0x70/0x70
> > >> >> > [ 243.034090] flush_work+0x12a/0x1e0
> > >> >> > [ 243.034097] ? worker_detach_from_pool+0xb0/0xb0
> > >> >> > [ 243.034107] __cancel_work_timer+0x112/0x190
> > >> >> > [ 243.034116] cancel_delayed_work_sync+0x13/0x20
> > >> >> > [ 243.034122] power_supply_unregister+0x37/0xb0
> > >> >> > [ 243.034127] devm_power_supply_release+0x11/0x20
> > >> >> > [ 243.034135] release_nodes+0x107/0x1f0
> > >> >> > [ 243.034147] devres_release_group+0x7c/0xb0
> > >> >> > [ 243.034162] wacom_remove+0xce/0x120 [wacom]
> > >> >> > [ 243.034178] hid_device_remove+0x4d/0xa0 [hid]
> > >> >> > [ 243.034187] device_release_driver_internal+0x155/0x220
> > >> >> > [ 243.034198] ? __hid_bus_driver_added+0x40/0x40 [hid]
> > >> >> > [ 243.034208] ? hid_destroy_device+0x60/0x60 [hid]
> > >> >> > [ 243.034215] device_release_driver+0x12/0x20
> > >> >> > [ 243.034221] device_reprobe+0x30/0x50
> > >> >> > [ 243.034231] __hid_bus_reprobe_drivers+0x45/0x50 [hid]
> > >> >> > [ 243.034239] bus_for_each_dev+0x64/0xb0
> > >> >> > [ 243.034250] __hid_bus_driver_added+0x2c/0x40 [hid]
> > >> >> > [ 243.034256] bus_for_each_drv+0x67/0xb0
> > >> >> > [ 243.034267] __hid_register_driver+0x6f/0x80 [hid]
> > >> >> > [ 243.034275] ? 0xffffffffc07f5000
> > >> >> > [ 243.034287] mt_driver_init+0x23/0x1000 [hid_multitouch]
> > >> >> > [ 243.034296] do_one_initcall+0x4f/0x1ce
> > >> >> > [ 243.034303] ? _cond_resched+0x1a/0x50
> > >> >> > [ 243.034315] ? kmem_cache_alloc_trace+0xb8/0x1f0
> > >> >> > [ 243.034327] do_init_module+0x5f/0x219
> > >> >> > [ 243.034335] load_module+0x24c7/0x2be0
> > >> >> > [ 243.034348] __do_sys_finit_module+0xe5/0x120
> > >> >> > [ 243.034354] ? __do_sys_finit_module+0xe5/0x120
> > >> >> > [ 243.034363] __x64_sys_finit_module+0x1a/0x20
> > >> >> > [ 243.034370] do_syscall_64+0x54/0x110
> > >> >> > [ 243.034380] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > >> >> > [ 243.034386] RIP: 0033:0x7f2ec539c839
> > >> >> > [ 243.034390] RSP: 002b:00007ffcfc620298 EFLAGS: 00000246 ORIG_RAX:
> > >> >> 0000000000000139
> > >> >> > [ 243.034396] RAX: ffffffffffffffda RBX: 000055d6a0147ec0 RCX:
> > >> >> 00007f2ec539c839
> > >> >> > [ 243.034399] RDX: 0000000000000000 RSI: 00007f2ec507b0e5 RDI:
> > >> >> 000000000000000f
> > >> >> > [ 243.034402] RBP: 00007f2ec507b0e5 R08: 0000000000000000 R09:
> > >> >> 00007ffcfc6203b0
> > >> >> > [ 243.034405] R10: 000000000000000f R11: 0000000000000246 R12:
> > >> >> 0000000000000000
> > >> >> > [ 243.034408] R13: 000055d6a017b3a0 R14: 0000000000020000 R15:
> > >> >> 000055d6a0147ec0
> > >> >> > --
> > >> >> > To unsubscribe from this list: send the line "unsubscribe linux-input" in
> > >> >> > the body of a message to majordomo@vger.kernel.org
> > >> >> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3] xpad: Add GPD Win 2 Controller USB IDs
From: Bastien Nocera @ 2018-05-31 8:17 UTC (permalink / raw)
To: Greg KH, flibitijibibo; +Cc: linux-input, stable, aicommander
In-Reply-To: <20180531053512.GA2532@kroah.com>
On Thu, 2018-05-31 at 07:35 +0200, Greg KH wrote:
> On Wed, May 30, 2018 at 09:14:59PM -0400, flibitijibibo@gmail.com
> wrote:
> > From: Ethan Lee <flibitijibibo@gmail.com>
> >
> > GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp
> >
> > Tested on a unit from the first production run sent to Indiegogo
> > backers
> >
> > Signed-off-by: Ethan Lee <flibitijibibo@gmail.com>
> > ---
> > drivers/input/joystick/xpad.c | 2 ++
> > 1 file changed, 2 insertions(+)
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read:
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rule
> s.html
> for how to do this properly.
>
> </formletter>
- Please CC stable@ so your patch is picked up for stable releases
*adds stable@ to the CC: list in the mailed patch*
- Not in this way!
^ permalink raw reply
* Re: [PATCH v3] xpad: Add GPD Win 2 Controller USB IDs
From: Greg KH @ 2018-05-31 5:35 UTC (permalink / raw)
To: flibitijibibo; +Cc: linux-input, stable, hadess, aicommander
In-Reply-To: <20180531011459.2911-1-flibitijibibo@gmail.com>
On Wed, May 30, 2018 at 09:14:59PM -0400, flibitijibibo@gmail.com wrote:
> From: Ethan Lee <flibitijibibo@gmail.com>
>
> GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp
>
> Tested on a unit from the first production run sent to Indiegogo backers
>
> Signed-off-by: Ethan Lee <flibitijibibo@gmail.com>
> ---
> drivers/input/joystick/xpad.c | 2 ++
> 1 file changed, 2 insertions(+)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
^ permalink raw reply
* [PATCH v3] xpad: Add GPD Win 2 Controller USB IDs
From: flibitijibibo @ 2018-05-31 1:14 UTC (permalink / raw)
To: linux-input; +Cc: stable, hadess, aicommander, Ethan Lee
From: Ethan Lee <flibitijibibo@gmail.com>
GPD Win 2 Website: http://www.gpd.hk/gpdwin2.asp
Tested on a unit from the first production run sent to Indiegogo backers
Signed-off-by: Ethan Lee <flibitijibibo@gmail.com>
---
drivers/input/joystick/xpad.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 06e9650b3b30..a89b81b35932 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -123,6 +123,7 @@ static const struct xpad_device {
u8 mapping;
u8 xtype;
} xpad_device[] = {
+ { 0x0079, 0x18d4, "GPD Win 2 Controller", 0, XTYPE_XBOX360 },
{ 0x044f, 0x0f00, "Thrustmaster Wheel", 0, XTYPE_XBOX },
{ 0x044f, 0x0f03, "Thrustmaster Wheel", 0, XTYPE_XBOX },
{ 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX },
@@ -409,6 +410,7 @@ static const signed short xpad_abs_triggers[] = {
static const struct usb_device_id xpad_table[] = {
{ USB_INTERFACE_INFO('X', 'B', 0) }, /* X-Box USB-IF not approved class */
+ XPAD_XBOX360_VENDOR(0x0079), /* GPD Win 2 Controller */
XPAD_XBOX360_VENDOR(0x044f), /* Thrustmaster X-Box 360 controllers */
XPAD_XBOX360_VENDOR(0x045e), /* Microsoft X-Box 360 controllers */
XPAD_XBOXONE_VENDOR(0x045e), /* Microsoft X-Box One controllers */
--
2.13.6
^ permalink raw reply related
* Re: [PATCH 1/2] HID: multitouch: report MT_TOOL_PALM for non-confident touches
From: Peter Hutterer @ 2018-05-30 23:12 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jiri Kosina, Benjamin Tissoires, Henrik Rydberg, Jason Gerecke,
Dennis Kempin, Andrew de los Reyes, linux-input, linux-kernel
In-Reply-To: <20170811004500.13740-1-dmitry.torokhov@gmail.com>
Hi Dmitry,
On Thu, Aug 10, 2017 at 05:44:59PM -0700, Dmitry Torokhov wrote:
> According to Microsoft specification [1] for Precision Touchpads (and
> Touchscreens) the devices use "confidence" reports to signal accidental
> touches, or contacts that are "too large to be a finger". Instead of
> simply marking contact inactive in this case (which causes issues if
> contact was originally proper and we lost confidence in it later, as
> this results in accidental clicks, drags, etc), let's report such
> contacts as MT_TOOL_PALM and let userspace decide what to do.
> Additionally, let's report contact size for such touches as maximum
> allowed for major/minor, which should help userspace that is not yet
> aware of MT_TOOL_PALM to still perform palm rejection.
>
> An additional complication, is that some firmwares do not report
> non-confident touches as active. To cope with this we delay release of
> such contact (i.e. if contact was active we first report it as still
> active MT+TOOL_PALM and then synthesize the release event in a separate
> frame).
>
> [1] https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This one popped up again in a bug report [1] and it looks like it never
got merged. fwiw, libinput does support ABS_MT_TOOL_PALM for touchpads as of
1.8.0 and just releasing the touch causes fake taps. So you have the green
light from me to merge this :)
Cheers,
Peter
[1] https://bugs.freedesktop.org/show_bug.cgi?id=106716
> ---
> drivers/hid/hid-multitouch.c | 86 +++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 77 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 440b999304a5..c28defe50a10 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -114,6 +114,8 @@ struct mt_device {
> struct timer_list release_timer; /* to release sticky fingers */
> struct mt_fields *fields; /* temporary placeholder for storing the
> multitouch fields */
> + unsigned long *pending_palm_slots; /* slots where we reported palm
> + and need to release */
> unsigned long mt_io_flags; /* mt flags (MT_IO_FLAGS_*) */
> int cc_index; /* contact count field index in the report */
> int cc_value_index; /* contact count value index in the field */
> @@ -543,8 +545,12 @@ static int mt_touch_input_mapping(struct hid_device *hdev, struct hid_input *hi,
> case HID_DG_CONFIDENCE:
> if ((cls->name == MT_CLS_WIN_8 ||
> cls->name == MT_CLS_WIN_8_DUAL) &&
> - field->application == HID_DG_TOUCHPAD)
> + field->application == HID_DG_TOUCHPAD) {
> cls->quirks |= MT_QUIRK_CONFIDENCE;
> + input_set_abs_params(hi->input,
> + ABS_MT_TOOL_TYPE,
> + MT_TOOL_FINGER, MT_TOOL_PALM, 0, 0);
> + }
> mt_store_field(usage, td, hi);
> return 1;
> case HID_DG_TIPSWITCH:
> @@ -657,6 +663,7 @@ static void mt_complete_slot(struct mt_device *td, struct input_dev *input)
>
> if (td->curvalid || (td->mtclass.quirks & MT_QUIRK_ALWAYS_VALID)) {
> int active;
> + int tool;
> int slotnum = mt_compute_slot(td, input);
> struct mt_slot *s = &td->curdata;
> struct input_mt *mt = input->mt;
> @@ -671,24 +678,56 @@ static void mt_complete_slot(struct mt_device *td, struct input_dev *input)
> return;
> }
>
> + active = s->touch_state || s->inrange_state;
> +
> if (!(td->mtclass.quirks & MT_QUIRK_CONFIDENCE))
> s->confidence_state = 1;
> - active = (s->touch_state || s->inrange_state) &&
> - s->confidence_state;
> +
> + if (likely(s->confidence_state)) {
> + tool = MT_TOOL_FINGER;
> + } else {
> + tool = MT_TOOL_PALM;
> + if (!active &&
> + input_mt_is_active(&mt->slots[slotnum])) {
> + /*
> + * The non-confidence was reported for
> + * previously valid contact that is also no
> + * longer valid. We can't simply report
> + * lift-off as userspace will not be aware
> + * of non-confidence, so we need to split
> + * it into 2 events: active MT_TOOL_PALM
> + * and a separate liftoff.
> + */
> + active = true;
> + set_bit(slotnum, td->pending_palm_slots);
> + }
> + }
>
> input_mt_slot(input, slotnum);
> - input_mt_report_slot_state(input, MT_TOOL_FINGER, active);
> + input_mt_report_slot_state(input, tool, active);
> if (active) {
> /* this finger is in proximity of the sensor */
> int wide = (s->w > s->h);
> int major = max(s->w, s->h);
> int minor = min(s->w, s->h);
>
> - /*
> - * divided by two to match visual scale of touch
> - * for devices with this quirk
> - */
> - if (td->mtclass.quirks & MT_QUIRK_TOUCH_SIZE_SCALING) {
> + if (unlikely(!s->confidence_state)) {
> + /*
> + * When reporting palm, set contact to maximum
> + * size to help userspace that does not
> + * recognize MT_TOOL_PALM to reject contacts
> + * that are too large.
> + */
> + major = input_abs_get_max(input,
> + ABS_MT_TOUCH_MAJOR);
> + minor = input_abs_get_max(input,
> + ABS_MT_TOUCH_MINOR);
> + } else if (td->mtclass.quirks &
> + MT_QUIRK_TOUCH_SIZE_SCALING) {
> + /*
> + * divided by two to match visual scale of touch
> + * for devices with this quirk
> + */
> major = major >> 1;
> minor = minor >> 1;
> }
> @@ -711,6 +750,25 @@ static void mt_complete_slot(struct mt_device *td, struct input_dev *input)
> td->num_received++;
> }
>
> +static void mt_release_pending_palms(struct mt_device *td,
> + struct input_dev *input)
> +{
> + int slotnum;
> + bool need_sync = false;
> +
> + for_each_set_bit(slotnum, td->pending_palm_slots, td->maxcontacts) {
> + clear_bit(slotnum, td->pending_palm_slots);
> +
> + input_mt_slot(input, slotnum);
> + input_mt_report_slot_state(input, MT_TOOL_PALM, false);
> +
> + need_sync = true;
> + }
> +
> + if (need_sync)
> + input_sync(input);
> +}
> +
> /*
> * this function is called when a whole packet has been received and processed,
> * so that it can decide what to send to the input layer.
> @@ -719,6 +777,9 @@ static void mt_sync_frame(struct mt_device *td, struct input_dev *input)
> {
> input_mt_sync_frame(input);
> input_sync(input);
> +
> + mt_release_pending_palms(td, input);
> +
> td->num_received = 0;
> if (test_bit(MT_IO_FLAGS_ACTIVE_SLOTS, &td->mt_io_flags))
> set_bit(MT_IO_FLAGS_PENDING_SLOTS, &td->mt_io_flags);
> @@ -903,6 +964,13 @@ static int mt_touch_input_configured(struct hid_device *hdev,
> if (td->is_buttonpad)
> __set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
>
> + td->pending_palm_slots = devm_kcalloc(&hi->input->dev,
> + BITS_TO_LONGS(td->maxcontacts),
> + sizeof(long),
> + GFP_KERNEL);
> + if (!td->pending_palm_slots)
> + return -ENOMEM;
> +
> ret = input_mt_init_slots(input, td->maxcontacts, td->mt_flags);
> if (ret)
> return ret;
> --
> 2.14.0.434.g98096fd7a8-goog
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v3 1/3] Input: ti_am335x_tsc - Mark IRQ as wakeup capable
From: Dmitry Torokhov @ 2018-05-30 21:47 UTC (permalink / raw)
To: Vignesh R
Cc: Grygorii Strashko, linux-input, linux-kernel, linux-omap,
Tony Lindgren
In-Reply-To: <20180424062741.7891-2-vigneshr@ti.com>
Hi Vignesh,
On Tue, Apr 24, 2018 at 11:57:39AM +0530, Vignesh R wrote:
> On AM335x, ti_am335x_tsc can wake up the system from suspend, mark the
> IRQ as wakeup capable, so that device irq is not disabled during system
> suspend.
>
> Signed-off-by: Vignesh R <vigneshr@ti.com>
> ---
> v3: Drop unneeded device_may_wakeup() check
>
> drivers/input/touchscreen/ti_am335x_tsc.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
> index f1043ae71dcc..3908c21862c7 100644
> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
> @@ -27,6 +27,7 @@
> #include <linux/of.h>
> #include <linux/of_device.h>
> #include <linux/sort.h>
> +#include <linux/pm_wakeirq.h>
>
> #include <linux/mfd/ti_am335x_tscadc.h>
>
> @@ -432,6 +433,10 @@ static int titsc_probe(struct platform_device *pdev)
> goto err_free_mem;
> }
>
> + err = dev_pm_set_wake_irq(tscadc_dev->dev, ts_dev->irq);
> + if (err)
> + dev_err(&pdev->dev, "irq wake enable failed.\n");
> +
Looking at this driver some more: why do we have the parent MFD device
as wakeup source? It seems we have 2 independent interrupt lines, one in
IIO and one in input and we could actually have the touchscreen itself
to be one of the wakeup devices? I.e. i'd expect
err = dev_pm_set_wake_irq(&pdev->dev, ts_dev->irq);
here and we should be checking the touchscreen pdev in suspend/resume
when checking whether to program the controller for wakeups.
> titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO0THRES);
> titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_EOS);
> err = titsc_config_wires(ts_dev);
> @@ -462,6 +467,7 @@ static int titsc_probe(struct platform_device *pdev)
> return 0;
>
> err_free_irq:
> + dev_pm_clear_wake_irq(tscadc_dev->dev);
> free_irq(ts_dev->irq, ts_dev);
> err_free_mem:
> input_free_device(input_dev);
> @@ -474,6 +480,7 @@ static int titsc_remove(struct platform_device *pdev)
> struct titsc *ts_dev = platform_get_drvdata(pdev);
> u32 steps;
>
> + dev_pm_clear_wake_irq(ts_dev->mfd_tscadc->dev);
> free_irq(ts_dev->irq, ts_dev);
>
> /* total steps followed by the enable mask */
> --
> 2.17.0
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 3/3] Input: ti_am335x_tsc - Prevent system suspend when TSC is in use
From: Dmitry Torokhov @ 2018-05-30 21:44 UTC (permalink / raw)
To: Vignesh R
Cc: Grygorii Strashko, linux-input, linux-kernel, linux-omap,
Tony Lindgren
In-Reply-To: <20180424062741.7891-4-vigneshr@ti.com>
On Tue, Apr 24, 2018 at 11:57:41AM +0530, Vignesh R wrote:
> From: Grygorii Strashko <grygorii.strashko@ti.com>
>
> Prevent system suspend while user has finger on touch screen,
> because TSC is wakeup source and suspending device while in use will
> result in failure to disable the module.
> This patch uses pm_stay_awake() and pm_relax() APIs to prevent and
> resume system suspend as required.
>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Vignesh R <vigneshr@ti.com>
Applied, thank you.
> ---
>
> v3: No change
>
> drivers/input/touchscreen/ti_am335x_tsc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
> index a548b0dbe320..ae6fc9099636 100644
> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
> @@ -277,6 +277,7 @@ static irqreturn_t titsc_irq(int irq, void *dev)
> if (status & IRQENB_HW_PEN) {
> ts_dev->pen_down = true;
> irqclr |= IRQENB_HW_PEN;
> + pm_stay_awake(ts_dev->mfd_tscadc->dev);
> }
>
> if (status & IRQENB_PENUP) {
> @@ -286,6 +287,7 @@ static irqreturn_t titsc_irq(int irq, void *dev)
> input_report_key(input_dev, BTN_TOUCH, 0);
> input_report_abs(input_dev, ABS_PRESSURE, 0);
> input_sync(input_dev);
> + pm_relax(ts_dev->mfd_tscadc->dev);
> } else {
> ts_dev->pen_down = true;
> }
> @@ -524,6 +526,7 @@ static int __maybe_unused titsc_resume(struct device *dev)
> titsc_writel(ts_dev, REG_IRQWAKEUP,
> 0x00);
> titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
> + pm_relax(ts_dev->mfd_tscadc->dev);
> }
> titsc_step_config(ts_dev);
> titsc_writel(ts_dev, REG_FIFO0THR,
> --
> 2.17.0
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 2/3] Input: ti_am335x_tsc - Ack pending IRQs at probe and before suspend
From: Dmitry Torokhov @ 2018-05-30 21:44 UTC (permalink / raw)
To: Vignesh R
Cc: Grygorii Strashko, linux-input, linux-kernel, linux-omap,
Tony Lindgren
In-Reply-To: <20180424062741.7891-3-vigneshr@ti.com>
On Tue, Apr 24, 2018 at 11:57:40AM +0530, Vignesh R wrote:
> From: Grygorii Strashko <grygorii.strashko@ti.com>
>
> It is seen that just enabling the TSC module triggers a HW_PEN IRQ
> without any interaction with touchscreen by user. This results in first
> suspend/resume sequence to fail as system immediately wakes up from
> suspend as soon as HW_PEN IRQ is enabled in suspend handler due to the
> pending IRQ. Therefore clear all IRQs at probe and also in suspend
> callback for sanity.
>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Vignesh R <vigneshr@ti.com>
Applied, thank you.
> ---
>
> v3: Clear IRQs related to TSC module only
>
> drivers/input/touchscreen/ti_am335x_tsc.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
> index 3908c21862c7..a548b0dbe320 100644
> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
> @@ -35,6 +35,8 @@
> #define SEQ_SETTLE 275
> #define MAX_12BIT ((1 << 12) - 1)
>
> +#define TSC_IRQENB_MASK (IRQENB_FIFO0THRES | IRQENB_EOS | IRQENB_HW_PEN)
> +
> static const int config_pins[] = {
> STEPCONFIG_XPP,
> STEPCONFIG_XNN,
> @@ -437,6 +439,7 @@ static int titsc_probe(struct platform_device *pdev)
> if (err)
> dev_err(&pdev->dev, "irq wake enable failed.\n");
>
> + titsc_writel(ts_dev, REG_IRQSTATUS, TSC_IRQENB_MASK);
> titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO0THRES);
> titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_EOS);
> err = titsc_config_wires(ts_dev);
> @@ -502,6 +505,7 @@ static int __maybe_unused titsc_suspend(struct device *dev)
>
> tscadc_dev = ti_tscadc_dev_get(to_platform_device(dev));
> if (device_may_wakeup(tscadc_dev->dev)) {
> + titsc_writel(ts_dev, REG_IRQSTATUS, TSC_IRQENB_MASK);
> idle = titsc_readl(ts_dev, REG_IRQENABLE);
> titsc_writel(ts_dev, REG_IRQENABLE,
> (idle | IRQENB_HW_PEN));
> --
> 2.17.0
>
--
Dmitry
^ permalink raw reply
* Re: [git pull] Input updates for v4.17-rc7
From: Dmitry Torokhov @ 2018-05-30 18:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, linux-input
In-Reply-To: <CA+55aFzc_gZ15Qg3BAoSgALbgTepnQmAnzNb+1w9U8OUxjjVvQ@mail.gmail.com>
On Tue, May 29, 2018 at 10:21:53PM -0500, Linus Torvalds wrote:
> On Tue, May 29, 2018 at 6:38 PM Dmitry Torokhov <dmitry.torokhov@gmail.com>
> wrote:
>
> > We are switching a bunch of
> > Lenovo devices with Synaptics touchpads from PS/2 emulation over to
> > native RMI/SMbus.
>
> > Given that all commits are marked for stable there is no point delaying
> > them till next release.
>
> Hmm. The elan driver stack overrun isn't mentioned, but seems more
> fundamental fix than the other changes that just add a few new PnP ID's...
I do not think that the Elan problem is actually observable on any
hardware with 4.17 at the moment, as it only shows up when switching
some Elan devices from PS/2 to SMBus and the patches that do that are
slated for the next merge window. I included it in the pull as a
precaution. Switching Synaptics to RMI is much more user-visible...
Still should have mentioned Elan corruption fix though.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v5] Input: add bu21029 touch driver
From: Jonas Mark (BT-FIR/ENG1) @ 2018-05-30 9:42 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Mark Rutland
Cc: linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, hs@denx.de,
andy.shevchenko@gmail.com, ZHU Yi (BT-FIR/ENG1-Zhu),
Jonas Mark (BT-FIR/ENG1)
Hi,
> [PATCH v5] Input: add bu21029 touch driver
>
> Add Rohm BU21029 resistive touch panel controller support with I2C
> interface.
Is the patch ready to be pushed upstream? Is there anything I still need to do?
Regards,
Mark
Mark Jonas
Building Technologies, Panel Software Fire (BT-FIR/ENG1)
Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com
Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118
Aufsichtsratsvorsitzender: Stefan Hartung; Geschäftsführung: Gert van Iperen, Andreas Bartz, Thomas Quante, Bernhard Schuster
^ permalink raw reply
* Re: [PATCH 1/9] Input: mt - export MT_TOOL in input_mt_init_slot()
From: Benjamin Tissoires @ 2018-05-30 8:53 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jiri Kosina, Mario.Limonciello, Peter Hutterer,
open list:HID CORE LAYER, lkml
In-Reply-To: <20180529182107.GC167092@dtor-ws>
Hi Dmitry,
On Tue, May 29, 2018 at 8:21 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Benjamin,
>
> On Tue, May 29, 2018 at 11:57:52AM +0200, Benjamin Tissoires wrote:
>> Looks like we require users to set a tool but input_mt_init_slots() never
>> set the tool bit for us. Meaning that this is a useless information the
>> driver tries to forward.
>
> I am not sure if I agree with this patch: up until now drivers could
> decide if they export presence of the tool type to userspace and
> userspace could distinguish between "pure" touchscreens and touchscreens
> that support additional tools, such as stylus. Now we unconditionally
> claim that all multi-touch devices support multiple tools.
>
> The fact that we were dropping MT_TOOL_TYPE for devices that do not
> support anything but finger I'd consider a "feature".
OK. I was not sure to agree with this, but I had a quick chat with
Peter and he also agrees. There is no real point in forwarding an
event that will never be updated, so let's just skip that patch then.
Expect this to be removed in v2 then.
Cheers,
Benjamin
>
>>
>> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>> ---
>> drivers/input/input-mt.c | 1 +
>> drivers/input/rmi4/rmi_2d_sensor.c | 2 --
>> drivers/input/touchscreen/atmel_mxt_ts.c | 2 --
>> drivers/input/touchscreen/hideep.c | 2 --
>> drivers/input/touchscreen/wacom_w8001.c | 2 --
>> 5 files changed, 1 insertion(+), 8 deletions(-)
>>
>> diff --git a/drivers/input/input-mt.c b/drivers/input/input-mt.c
>> index a1bbec9cda8d..3900686c5d0f 100644
>> --- a/drivers/input/input-mt.c
>> +++ b/drivers/input/input-mt.c
>> @@ -57,6 +57,7 @@ int input_mt_init_slots(struct input_dev *dev, unsigned int num_slots,
>> mt->flags = flags;
>> input_set_abs_params(dev, ABS_MT_SLOT, 0, num_slots - 1, 0, 0);
>> input_set_abs_params(dev, ABS_MT_TRACKING_ID, 0, TRKID_MAX, 0, 0);
>> + input_set_abs_params(dev, ABS_MT_TOOL_TYPE, 0, MT_TOOL_MAX, 0, 0);
>>
>> if (flags & (INPUT_MT_POINTER | INPUT_MT_DIRECT)) {
>> __set_bit(EV_KEY, dev->evbit);
>> diff --git a/drivers/input/rmi4/rmi_2d_sensor.c b/drivers/input/rmi4/rmi_2d_sensor.c
>> index 8bb866c7b985..23e666bd2539 100644
>> --- a/drivers/input/rmi4/rmi_2d_sensor.c
>> +++ b/drivers/input/rmi4/rmi_2d_sensor.c
>> @@ -186,8 +186,6 @@ static void rmi_2d_sensor_set_input_params(struct rmi_2d_sensor *sensor)
>> input_set_abs_params(input, ABS_MT_TOUCH_MAJOR, 0, 0x0f, 0, 0);
>> input_set_abs_params(input, ABS_MT_TOUCH_MINOR, 0, 0x0f, 0, 0);
>> input_set_abs_params(input, ABS_MT_ORIENTATION, 0, 1, 0, 0);
>> - input_set_abs_params(input, ABS_MT_TOOL_TYPE,
>> - 0, MT_TOOL_MAX, 0, 0);
>>
>> if (sensor->sensor_type == rmi_sensor_touchpad)
>> input_flags = INPUT_MT_POINTER;
>> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
>> index 54fe190fd4bc..0dcf48100dc1 100644
>> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
>> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
>> @@ -2021,8 +2021,6 @@ static int mxt_initialize_input_device(struct mxt_data *data)
>> }
>>
>> if (data->multitouch == MXT_TOUCH_MULTITOUCHSCREEN_T100) {
>> - input_set_abs_params(input_dev, ABS_MT_TOOL_TYPE,
>> - 0, MT_TOOL_MAX, 0, 0);
>> input_set_abs_params(input_dev, ABS_MT_DISTANCE,
>> MXT_DISTANCE_ACTIVE_TOUCH,
>> MXT_DISTANCE_HOVERING,
>> diff --git a/drivers/input/touchscreen/hideep.c b/drivers/input/touchscreen/hideep.c
>> index f1cd4dd9a4a3..980539d8d551 100644
>> --- a/drivers/input/touchscreen/hideep.c
>> +++ b/drivers/input/touchscreen/hideep.c
>> @@ -799,8 +799,6 @@ static int hideep_init_input(struct hideep_ts *ts)
>> input_set_capability(ts->input_dev, EV_ABS, ABS_MT_POSITION_Y);
>> input_set_abs_params(ts->input_dev, ABS_MT_PRESSURE, 0, 65535, 0, 0);
>> input_set_abs_params(ts->input_dev, ABS_MT_TOUCH_MAJOR, 0, 255, 0, 0);
>> - input_set_abs_params(ts->input_dev, ABS_MT_TOOL_TYPE,
>> - 0, MT_TOOL_MAX, 0, 0);
>> touchscreen_parse_properties(ts->input_dev, true, &ts->prop);
>>
>> if (ts->prop.max_x == 0 || ts->prop.max_y == 0) {
>> diff --git a/drivers/input/touchscreen/wacom_w8001.c b/drivers/input/touchscreen/wacom_w8001.c
>> index 3715d1eace92..946dca30560b 100644
>> --- a/drivers/input/touchscreen/wacom_w8001.c
>> +++ b/drivers/input/touchscreen/wacom_w8001.c
>> @@ -529,8 +529,6 @@ static int w8001_setup_touch(struct w8001 *w8001, char *basename,
>> 0, touch.x, 0, 0);
>> input_set_abs_params(dev, ABS_MT_POSITION_Y,
>> 0, touch.y, 0, 0);
>> - input_set_abs_params(dev, ABS_MT_TOOL_TYPE,
>> - 0, MT_TOOL_MAX, 0, 0);
>> input_abs_set_res(dev, ABS_MT_POSITION_X, touch.panel_res);
>> input_abs_set_res(dev, ABS_MT_POSITION_Y, touch.panel_res);
>>
>> --
>> 2.14.3
>>
>
> Thanks.
>
> --
> Dmitry
^ 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