* [git pull] Input updates for 3.17-rc0 (part 2)
From: Dmitry Torokhov @ 2014-09-03 23:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input
[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem. You will get a fix for MT
breakage, enhancement to Elantech PS/2 driver and a couple of assorted
fixes.
Changelog:
---------
Dmitry Torokhov (2):
Input: fix used slots detection breakage
Input: ALPS - suppress message about 'Unknown touchpad'
Nick Dyer (1):
Input: atmel_mxt_ts - improve description of gpio-keymap property
Ulrik De Bie (2):
Input: elantech - reset the device when elantech probe fails
Input: elantech - add support for trackpoint found on some v3 models
Vincent Stehlé (1):
Input: sparc - i8042-sparcio.h: fix unused kbd_res warning
Diffstat:
--------
.../devicetree/bindings/input/atmel,maxtouch.txt | 11 ++
drivers/input/input-mt.c | 30 +++--
drivers/input/mouse/alps.c | 4 +-
drivers/input/mouse/elantech.c | 137 +++++++++++++++++++--
drivers/input/mouse/elantech.h | 3 +
drivers/input/serio/i8042-sparcio.h | 3 +-
6 files changed, 164 insertions(+), 24 deletions(-)
--
Dmitry
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] HID: hid-sensor-hub: Adding USB_DEVICE_ID_STM_HID_SENSOR device id
From: Srinivas Pandruvada @ 2014-09-03 23:00 UTC (permalink / raw)
To: jkosina; +Cc: elad, linux-input, Srinivas Pandruvada
Adding USB_DEVICE_ID_STM_HID_SENSOR again in the quirk table. During 3.16 merge
cycle somehow quirk for device id USB_DEVICE_ID_STM_HID_SENSOR is missing.
I see commit dde3b45cd74e ("HID: hid-sensor-hub: new device id and quirk
for STM Sensor hub") added new id USB_DEVICE_ID_STM_HID_SENSOR_1,
but didn't really delete the old device id.
Anyway we need to add this back, otherwise it breaks ST sensor hubs.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
drivers/hid/hid-sensor-hub.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index 2ac2576..e6d8e18 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -709,6 +709,9 @@ static const struct hid_device_id sensor_hub_devices[] = {
USB_DEVICE_ID_MS_TYPE_COVER_2),
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_STM_0,
+ USB_DEVICE_ID_STM_HID_SENSOR),
+ .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
+ { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_STM_0,
USB_DEVICE_ID_STM_HID_SENSOR_1),
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_TEXAS_INSTRUMENTS,
--
1.9.3
^ permalink raw reply related
* Re: hid-thingm: kernel panic on remove
From: Jiri Kosina @ 2014-09-03 21:47 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Dylan Alex Simon, linux-input
In-Reply-To: <CAN+gG=HZfXp5dEdsRRcmia9Da0p8VT1Rj9TLB-cahiUDkCQujA@mail.gmail.com>
On Wed, 3 Sep 2014, Benjamin Tissoires wrote:
> > From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > Date: Tue, 2 Sep 2014 15:50:43 -0400
> > Subject: [PATCH] HID: thingm: set the proper error code before leaving
> >
> > In case of an unsupported firmware, the driver bails out without setting
> > the LEDs interfaces, but forget to set the proper error code.
> > err is then still equal to 0 and the hid subsytem consider the device
> > to be in perfect shape.
> > When removing it, thingm_remove() tries to unbind the rgb LEDs which
> > has not been created, leading to a segfault.
> >
> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > ---
> > drivers/hid/hid-thingm.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
> > index 134be89..f91f971 100644
> > --- a/drivers/hid/hid-thingm.c
> > +++ b/drivers/hid/hid-thingm.c
> > @@ -250,6 +250,7 @@ static int thingm_probe(struct hid_device *hdev, const struct hid_device_id *id)
> >
> > if (!tdev->fwinfo) {
> > hid_err(hdev, "unsupported firmware %c\n", tdev->version.major);
> > + err = -ENODEV;
> > goto stop;
> > }
>
> Jiri, could you still consider including this one? If Thingm decides
> to create a firmware with 3.X, it will fail, so I guess this is still
> required, even if it does not fix Dylan's problem.
It's now queued in for-3.17/upstream-fixes. I don't think it justifies
pull request to Linus by itself, but if there is anything else that does,
it'll piggy-back. Otherwise it'll go into 3.18. Please shout if it's not
okay.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: wacom: Add support for the Cintiq Companion
From: Jiri Kosina @ 2014-09-03 21:44 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dmitry Torokhov, Ping Cheng, Jason Gerecke, linux-input,
linux-kernel
In-Reply-To: <1409773405-18030-1-git-send-email-benjamin.tissoires@redhat.com>
On Wed, 3 Sep 2014, Benjamin Tissoires wrote:
> The Wacom Cintiq Companion shares the same sensor than the Cintiq
> Companion Hybrid, with the exception of the different PIDs.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
>
> Hi,
>
> I guess this could now go through Jiri's tree given that it applies on top of a
> plain 3.17-rcX. It can be scheduled for either 3.17 or 3.18 (no preferences on
> my side).
I have now queued it in hid.git#for-3.18/wacom. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: Driver for Logitech M560
From: Benjamin Tissoires @ 2014-09-03 21:36 UTC (permalink / raw)
To: Goffredo Baroncelli; +Cc: Nestor Lopez Casado, open list:HID CORE LAYER
In-Reply-To: <5404C6F4.1000800@inwind.it>
Hi Goffredo,
On Mon, Sep 1, 2014 at 3:20 PM, Goffredo Baroncelli <kreijack@inwind.it> wrote:
> Hi Benjamin,
>
> following the Nestor suggestion, I rewrote the driver for the
> mouse Logitech M560 on the basis of your work (branch "for-whot").
Just for the record. This branch is located here:
https://github.com/bentiss/hid-logitech-dj/tree/for-whot and I
*really* need to finish this work so that everything can go upstream
:(
>
> The Logitech M560 is is a mouse designed for windows 8.
> Comparing to a standard one, some buttons (the middle one and the
> two ones placed on the side) are bounded to a key combination
> instead of a classic "mouse" button.
>
> Think this mouse as a pair of mouse and keyboard. When the middle
> button is pressed the it sends a key (as keyboard)
> combination, the same for the other two side button.
> Instead the left/right/wheel work correctly.
> To complicate further the things, the middle button send a
> key combination the odd press, and another one for the even press;
> in the latter case it sends also a left click. But the worst thing
> is that no event is generated when the middle button is released.
>
> Moreover this device is a wireless mouse which uses the unifying
> receiver.
>
> I discovered that it is possible to re-configure the mouse
> sending a command (see function m560_send_config_command()).
> After this command the mouse sends some sequence when the
> buttons are pressed and/or released (see comments for
> an explanation of the mouse protocol).
>
> If the mouse is "silent" (no data is sent) for more than
> PACKET_TIMEOUT seconds (currently 10), when the next packet
> comes, the driver try to reconfigure it.
> This because it is possible that the mouse is switched-off
> and lost its setting. Se we need to reconfigure.
This just looks weird. I am pretty sure we managed to properly tackle
that for the touchpads, there should not be any difference with the
mouse. Or maybe we did not?
Anyway, calling this every timeout is not a good solution IMO.
>
> Benjamin, I have to highlight three things:
> when the dj driver detects a disconnection, it
> sends a sequence like
>
> 0x01 0x00 0x00 0x00 0x00 0x00 0x00 ...
> 0x02 0x00 0x00 0x00 0x00 0x00 0x00 ...
>
> because the mouse is both a keyboard (0x01) and
> a mouse (0x02). But this sequence is a valid one
> (when two buttons are released) due to the strangeness
> of the protocol.
>
> Can I suggest to send in these case a sequence like
>
> <device_type> 0xff 0xff 0xff 0xff 0xff 0xff....
>
> ? I suspect that this would be less common.
Nope. This does not work. The idea behind sending the "null" report is
that this report will reset the current state of the keyboards/mice by
sending a "all buttons are now released" event. It is _not_ designed
as a marker that the device has been disconnected.
If you need this info, then another mechanism has to be used.
>
> Another thing that seemed strange to me is that report
> with ID equal 0x20 and 0x21 are handled so the packet
> are forwarded to the driver from the 3rd byte onward.
Yes. 0x20 and 0x21 are DJ reports, which encapsulate a mouse/keyboard
report coming from the DJ device.
To be properly handled by the final driver, we have to remove the
encapsulation fields so that the reports are just plain HID.
> In the others cases (this mouse send also packet with
> ID=0x11) the report id forwarded as is (without
> by-passing the first two bytes). It is the expected
> behaviour, or the code was written on the basis the
> assumption that the devices send ID=0x20/0x21 and the
> other ID are sent only by the receiver ?
No. The 0x10/0x11 reports are from the HID++ Logitech-specific
implementation, and must be forwarded as is. They have to be handled
as such by the final driver, and so, they must keep their report ID.
>
> Finally I have to point out that to work, this driver
> has to be inserted BEFORE the hid_logitech_dj
>
> In fact I had to add a file /etc/modprobe.d/hid-logitech_dj.conf
> as below
>
> install hid_logitech_dj modprobe hid_logitech_m560; sleep 5s ; modprobe --ignore-install hid_logitech_dj
>
> It is possible that the "sleep 5s" is not needed.
Hmm. This might be because there are some conflicts between your
current install and the one you just changed. I would not worry about
that. When this work will land upstream, there will be not problems.
I still did not decided if I am going to take this right now into the
github tree or not (and make a deeper review).
BTW, there is no need to send such patch to the LKML currently, you
are working against my non upstream branch. What you can do is either
setup a github clone with your patch/modifications if you want to
share them, or I can also pull this in a separate branch.
Once I'll finish the changes I want to do to hid-logitech-dj and
hid-logitech-hidpp, then we can think of merging that in my
submission.
Sorry, I still need a little bit of time to finish up this work.
Cheers,
Benjamin
> --
> gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
>
>
> ---
>
> This driver add support for the mouse Logitech m560
>
> Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
>
> diff --git a/Makefile b/Makefile
> index 3016586..86157c0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,6 +1,7 @@
> obj-m += hid-logitech-dj.o
> obj-m += hid-logitech-hidpp.o
> obj-m += hid-logitech-wtp.o
> +obj-m += hid-logitech-m560.o
>
> KDIR := /lib/modules/$(shell uname -r)/build
> PWD := $(shell pwd)
> diff --git a/hid-logitech-m560.c b/hid-logitech-m560.c
> new file mode 100644
> index 0000000..5758423
> --- /dev/null
> +++ b/hid-logitech-m560.c
> @@ -0,0 +1,378 @@
> +/*
> + * HID driver for Logitech m560 mouse
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include <linux/device.h>
> +#include <linux/hid.h>
> +#include <linux/module.h>
> +#include <linux/sched.h>
> +#include <linux/workqueue.h>
> +#include "hid-ids.h"
> +#include "hid-logitech-dj.h"
> +#include "hid-logitech-hidpp.h"
> +
> +#define DJ_DEVICE_ID_M560 0x402d
> +
> +/*
> + * Logitech M560 protocol overview
> + *
> + * The Logitech M560 mouse, is designed for windows 8. When the middle and/or
> + * the sides buttons are pressed, it sends some keyboard keys events
> + * instead of buttons ones.
> + * To complicate further the things, the middle button keys sequence
> + * is different from the odd press and the even press.
> + *
> + * forward button -> Super_R
> + * backward button -> Super_L+'d' (press only)
> + * middle button -> 1st time: Alt_L+SuperL+XF86TouchpadOff (press only)
> + * 2nd time: left-click (press only)
> + * NB: press-only means that when the button is pressed, the
> + * KeyPress/ButtonPress and KeyRelease/ButtonRelease events are generated
> + * together sequentially; instead when the button is released, no event is
> + * generated !
> + *
> + * With the command
> + * 10<xx>0a 3500af03 (where <xx> is the mouse id),
> + * the mouse reacts differently:
> + * - it never send a keyboard key event
> + * - for the three mouse button it sends:
> + * middle button press 11<xx>0a 3500af00...
> + * side 1 button (forward) press 11<xx>0a 3500b000...
> + * side 2 button (backward) press 11<xx>0a 3500ae00...
> + * middle/side1/side2 button release 11<xx>0a 35000000...
> + */
> +static u8 m560_config_command[] = {0x35, 0x00, 0xaf, 0x03};
> +
> +struct m560_private_data {
> + union {
> + struct dj_report dj_report;
> + u8 data[sizeof(struct dj_report)];
> + };
> + bool do_config_command;
> + struct delayed_work work;
> + struct dj_device *djdev;
> + unsigned long packet_last_time;
> +};
> +
> +/* how the button are mapped in the report */
> +#define MOUSE_BTN_LEFT 0
> +#define MOUSE_BTN_RIGHT 1
> +#define MOUSE_BTN_MIDDLE 2
> +#define MOUSE_BTN_WHEEL_LEFT 3
> +#define MOUSE_BTN_WHEEL_RIGHT 4
> +#define MOUSE_BTN_FORWARD 5
> +#define MOUSE_BTN_BACKWARD 6
> +
> +#define CONFIG_COMMAND_TIMEOUT (3*HZ)
> +#define PACKET_TIMEOUT (10*HZ)
> +
> +
> +/*
> + * m560_send_config_command - send the config_command to the mouse
> + *
> + * @dev: hid device where the mouse belongs
> + *
> + * @return: >0 OK, <0 error
> + */
> +static int m560_send_config_command(struct hid_device *hdev)
> +{
> + struct dj_report *dj_report;
> + int retval;
> + struct dj_device *dj_device = hdev->driver_data;
> + struct hid_device *djrcv_hdev = dj_device->dj_receiver_dev->hdev;
> +
> + dj_report = kzalloc(sizeof(struct dj_report), GFP_KERNEL);
> + if (!dj_report)
> + return -ENOMEM;
> +
> + dj_report->report_id = REPORT_ID_HIDPP_SHORT;
> + dj_report->device_index = dj_device->device_index;
> + dj_report->report_type = 0x0a;
> +
> + memcpy(dj_report->report_params, m560_config_command,
> + sizeof(m560_config_command));
> + retval = hid_hw_raw_request(djrcv_hdev,
> + dj_report->report_id,
> + (void *)dj_report, HIDPP_REPORT_SHORT_LENGTH,
> + HID_OUTPUT_REPORT, HID_REQ_SET_REPORT);
> +
> + kfree(dj_report);
> + return retval;
> +
> +}
> +
> +/*
> + * delayedwork_callback - handle the sending of the config_command.
> + * It schedules another sending because sometime the mouse doesn't understand
> + * the first request and returns an error. So until an ack is received, this
> + * function continue to reschedule a sending each RESET_TIMEOUT seconds
> + *
> + * @work: work_struct struct
> + */
> +static void delayedwork_callback(struct work_struct *work)
> +{
> + struct m560_private_data *mydata =
> + container_of(work, struct m560_private_data, work.work);
> + struct hid_device *hdev = mydata->djdev->hdev;
> +
> + if (!mydata->do_config_command)
> + return;
> +
> + if (schedule_delayed_work(&mydata->work, CONFIG_COMMAND_TIMEOUT) == 0) {
> + dbg_hid(
> + "%s: did not schedule the work item, was already queued\n",
> + __func__);
> + }
> +
> + m560_send_config_command(hdev);
> +}
> +
> +/*
> + * start_config_command - start sending config_command
> + *
> + * @mydata: pointer to private driver data
> + */
> +static inline void start_config_command(struct m560_private_data *mydata)
> +{
> + mydata->do_config_command = true;
> + if (schedule_delayed_work(&mydata->work, HZ/2) == 0) {
> + struct hid_device *hdev = mydata->djdev->hdev;
> + hid_err(hdev,
> + "%s: did not schedule the work item, was already queued\n",
> + __func__);
> + }
> +}
> +
> +/*
> + * stop_config_command - stop sending config_command
> + *
> + * @mydata: pointer to private driver data
> + */
> +static inline void stop_config_command(struct m560_private_data *mydata)
> +{
> + mydata->do_config_command = false;
> +}
> +
> +/*
> + * m560_djdevice_probe - perform the probing of the device.
> + *
> + * @hdev: hid device
> + * @id: hid device id
> + */
> +static int m560_djdevice_probe(struct hid_device *hdev,
> + const struct hid_device_id *id)
> +{
> +
> + int ret;
> + struct m560_private_data *mydata;
> + struct dj_device *dj_device = hdev->driver_data;
> +
> + if (strcmp(hdev->name, "M560"))
> + return -ENODEV;
> +
> + mydata = kzalloc(sizeof(struct m560_private_data), GFP_KERNEL);
> + if (!mydata)
> + return -ENOMEM;
> +
> + mydata->djdev = dj_device;
> +
> + /* force it so input_mapping doesn't pass anything */
> + mydata->do_config_command = true;
> +
> + ret = hid_parse(hdev);
> + if (!ret)
> + ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> +
> + /* we can't set before */
> + hid_set_drvdata(hdev, mydata);
> +
> + if (ret) {
> + kfree(mydata);
> + return ret;
> + }
> + INIT_DELAYED_WORK(&mydata->work, delayedwork_callback);
> +
> + start_config_command(mydata);
> +
> + return 0;
> +}
> +
> +static inline int mouse_btn_byte(int bit)
> +{
> + return (bit / 8) & 0x01;
> +}
> +
> +static inline int mouse_btn_bit(int bit)
> +{
> + return 1 << (bit & 0x07);
> +}
> +
> +static int m560_dj_raw_event(struct hid_device *hdev,
> + struct hid_report *report, u8 *data, int size)
> +{
> + struct m560_private_data *mydata = hid_get_drvdata(hdev);
> + int i;
> +
> + /* count the zeros; the for body is empty */
> + for (i = 1 ; i < size && data[i] == 0 ; i++) ;
> +
> + /* check if the data is a mouse related report */
> + if (data[0] != REPORT_TYPE_MOUSE && data[2] != 0x0a)
> + return 1;
> +
> + /*
> + * Check if the last packet was older than PACKET_TIMEOUT
> + * This may be a sign of a disconnection; in this case
> + * we resend the config_command
> + *
> + * NOTE: in case of a disconnection, the receiver driver
> + * send the sequence 0x01 0x00 ... 0x00 and
> + * 0x02 0x00 ... 0x00, but these are possibile true packet
> + * sent by the mouse (release of the left and the front button)
> + */
> + if (mydata->packet_last_time &&
> + (jiffies - mydata->packet_last_time) > PACKET_TIMEOUT) {
> + start_config_command(mydata);
> + }
> + mydata->packet_last_time = jiffies;
> +
> + /* check if the report is the ack of the config_command */
> + if (data[0] == 0x11 && data[2] == 0x0a &&
> + size >= (3+sizeof(m560_config_command)) &&
> + !memcmp(data+3, m560_config_command,
> + sizeof(m560_config_command))) {
> +
> + stop_config_command(mydata);
> + return true;
> + }
> +
> + /*
> + * check if the report is a mouse button sequence
> + *
> + * mydata->data[0] = type (0x02)
> + * mydata->data[1..2] = buttons
> + * mydata->data[3..5] = xy
> + * mydata->data[6] = wheel
> + * mydata->data[7] = horizontal wheel
> + */
> + if (data[0] == 0x11 && data[2] == 0x0a && data[06] == 0x00) {
> + int btn, i, maxsize;
> +
> + /* check if the event is a button */
> + btn = data[5];
> + if (btn != 0x00 && btn != 0xb0 && btn != 0xae && btn != 0xaf)
> + return true;
> +
> + if (btn == 0xaf)
> + mydata->data[1+mouse_btn_byte(MOUSE_BTN_MIDDLE)] |=
> + mouse_btn_bit(MOUSE_BTN_MIDDLE);
> + else if (btn == 0xb0)
> + mydata->data[1+mouse_btn_byte(MOUSE_BTN_FORWARD)] |=
> + mouse_btn_bit(MOUSE_BTN_FORWARD);
> + else if (btn == 0xae)
> + mydata->data[1+mouse_btn_byte(MOUSE_BTN_BACKWARD)] |=
> + mouse_btn_bit(MOUSE_BTN_BACKWARD);
> +
> + else if (btn == 0x00) {
> + mydata->data[1+mouse_btn_byte(MOUSE_BTN_MIDDLE)] &=
> + ~mouse_btn_bit(MOUSE_BTN_MIDDLE);
> + mydata->data[1+mouse_btn_byte(MOUSE_BTN_FORWARD)] &=
> + ~mouse_btn_bit(MOUSE_BTN_FORWARD);
> + mydata->data[1+mouse_btn_byte(MOUSE_BTN_BACKWARD)] &=
> + ~mouse_btn_bit(MOUSE_BTN_BACKWARD);
> + }
> +
> + /* replace the report with a standard one */
> + if (size > sizeof(mydata->data))
> + maxsize = sizeof(mydata->data);
> + else
> + maxsize = size;
> + for (i = 0 ; i < maxsize ; i++)
> + data[i] = mydata->data[i];
> +
> + return 1;
> + }
> +
> + /* check if the report is a "standard" mouse report */
> + if (data[0] == REPORT_TYPE_MOUSE) {
> + int i;
> +
> + /* horizontal wheel handling */
> + if (data[1+mouse_btn_byte(MOUSE_BTN_WHEEL_LEFT)] &
> + mouse_btn_bit(MOUSE_BTN_WHEEL_LEFT))
> + data[1+6] = -1;
> + if (data[1+mouse_btn_byte(MOUSE_BTN_WHEEL_RIGHT)] &
> + mouse_btn_bit(MOUSE_BTN_WHEEL_RIGHT))
> + data[1+6] = 1;
> +
> + data[1+mouse_btn_byte(MOUSE_BTN_WHEEL_LEFT)] &=
> + ~mouse_btn_bit(MOUSE_BTN_WHEEL_LEFT);
> + data[1+mouse_btn_byte(MOUSE_BTN_WHEEL_RIGHT)] &=
> + ~mouse_btn_bit(MOUSE_BTN_WHEEL_RIGHT);
> +
> + /* copy the button status */
> + for (i = 0 ; i < 3 ; i++)
> + mydata->data[i] = data[i];
> + }
> +
> + return 1;
> +}
> +
> +/*
> + * This function performs the cleanup when the device is removed
> + */
> +static void m560_djdevice_remove(struct hid_device *hdev)
> +{
> + struct m560_private_data *mydata = hid_get_drvdata(hdev);
> +
> + if (!mydata)
> + return;
> +
> + cancel_delayed_work_sync(&mydata->work);
> + hid_hw_stop(hdev);
> + kfree(mydata);
> +}
> +
> +/*
> + * This function avoids that any event different from the mouse ones
> + * goes to the upper level
> + */
> +static int m560_djdevice_input_mapping(struct hid_device *hdev,
> + struct hid_input *hi, struct hid_field *field,
> + struct hid_usage *usage, unsigned long **bit, int *max)
> +{
> + if (field->application != HID_GD_MOUSE)
> + return -1;
> + return 0;
> +}
> +
> +static const struct hid_device_id m560_dj_device[] = {
> + { HID_DEVICE(BUS_USB, HID_GROUP_LOGITECH_DJ_DEVICE_GENERIC,
> + USB_VENDOR_ID_LOGITECH, DJ_DEVICE_ID_M560)},
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(hid, m560_dj_device);
> +
> +struct hid_driver hid_logitech_dj_device_driver_m560 = {
> + .name = "m560",
> + .id_table = m560_dj_device,
> + .probe = m560_djdevice_probe,
> + .remove = m560_djdevice_remove,
> + .input_mapping = m560_djdevice_input_mapping,
> + .raw_event = m560_dj_raw_event,
> +};
> +
> +module_hid_driver(hid_logitech_dj_device_driver_m560)
> +
> +MODULE_AUTHOR("Goffredo Baroncelli <kreijack@inwind.it>");
> +MODULE_DESCRIPTION("Logitech Wireless Mouse m560");
> +MODULE_LICENSE("GPL");
>
>
>
^ permalink raw reply
* Re: hid-thingm: kernel panic on remove
From: Benjamin Tissoires @ 2014-09-03 19:48 UTC (permalink / raw)
To: Dylan Alex Simon, linux-input, Jiri Kosina
In-Reply-To: <54062150.2010800@gmail.com>
On Tue, Sep 2, 2014 at 3:58 PM, Benjamin Tissoires
<benjamin.tissoires@gmail.com> wrote:
> Hi,
>
> On 09/02/2014 01:46 PM, Dylan Alex Simon wrote:
>> Whenever either disconnecting the USB device or simply rmmod'ing the module
>> (even when not in use), I get a kernel panic. I haven't managed to capture a
>> backtrace, but at least the first two lines were saved after an rmmod:
>>
>> 18:53:17 kernel: thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
>> <snip, rmmod hid-thingm:>
>> 08:38:42 kernel: BUG: unable to handle kernel paging request at fffffffb8a80aaf8
>> 08:38:42 kernel: IP: [<ffffffff8106e30c>] osq_lock+0x3c/0x110
>>
>> Let me know if you'd like me to try to capture more info, but this problem
>> seems very reproducible (at least with a mk2 device; I never had the problem on
>> older kernels with a mk1). I do direct write()s to the hidraw device, but
>> don't otherwise use the driver while it's loaded.
>>
>> Also at https://bugzilla.kernel.org/show_bug.cgi?id=83751
>
> Do you happen to see a "unsupported firmware " error when plugging your device?
>
> If so, then the following patch should help with the panic (but you will an other one to be able to use again your device).
>
> ---
>
> From 791297375227b91990b37f94fc9de93156a3c21a Mon Sep 17 00:00:00 2001
> From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Date: Tue, 2 Sep 2014 15:50:43 -0400
> Subject: [PATCH] HID: thingm: set the proper error code before leaving
>
> In case of an unsupported firmware, the driver bails out without setting
> the LEDs interfaces, but forget to set the proper error code.
> err is then still equal to 0 and the hid subsytem consider the device
> to be in perfect shape.
> When removing it, thingm_remove() tries to unbind the rgb LEDs which
> has not been created, leading to a segfault.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
> drivers/hid/hid-thingm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
> index 134be89..f91f971 100644
> --- a/drivers/hid/hid-thingm.c
> +++ b/drivers/hid/hid-thingm.c
> @@ -250,6 +250,7 @@ static int thingm_probe(struct hid_device *hdev, const struct hid_device_id *id)
>
> if (!tdev->fwinfo) {
> hid_err(hdev, "unsupported firmware %c\n", tdev->version.major);
> + err = -ENODEV;
> goto stop;
> }
>
> --
> 2.1.0
>
Jiri, could you still consider including this one? If Thingm decides
to create a firmware with 3.X, it will fail, so I guess this is still
required, even if it does not fix Dylan's problem.
Cheers,
Benjamin
^ permalink raw reply
* [PATCH] HID: wacom: Add support for the Cintiq Companion
From: Benjamin Tissoires @ 2014-09-03 19:43 UTC (permalink / raw)
To: Jiri Kosina, Dmitry Torokhov, Ping Cheng, Jason Gerecke
Cc: linux-input, linux-kernel
The Wacom Cintiq Companion shares the same sensor than the Cintiq
Companion Hybrid, with the exception of the different PIDs.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Hi,
I guess this could now go through Jiri's tree given that it applies on top of a
plain 3.17-rcX. It can be scheduled for either 3.17 or 3.18 (no preferences on
my side).
Cheers,
Benjamin
drivers/hid/wacom_wac.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index aa6a08e..c3cbbfb 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -2573,6 +2573,14 @@ static const struct wacom_features wacom_features_0x309 =
{ "Wacom ISDv5 309", .type = WACOM_24HDT, /* Touch */
.oVid = USB_VENDOR_ID_WACOM, .oPid = 0x0307, .touch_max = 10,
.check_for_hid_type = true, .hid_type = HID_TYPE_USBNONE };
+static const struct wacom_features wacom_features_0x30A =
+ { "Wacom ISDv5 30A", 59352, 33648, 2047, 63,
+ CINTIQ_HYBRID, WACOM_INTUOS3_RES, WACOM_INTUOS3_RES, 200, 200,
+ .oVid = USB_VENDOR_ID_WACOM, .oPid = 0x30C };
+static const struct wacom_features wacom_features_0x30C =
+ { "Wacom ISDv5 30C", .type = WACOM_24HDT, /* Touch */
+ .oVid = USB_VENDOR_ID_WACOM, .oPid = 0x30A, .touch_max = 10,
+ .check_for_hid_type = true, .hid_type = HID_TYPE_USBNONE };
#define USB_DEVICE_WACOM(prod) \
HID_DEVICE(BUS_USB, HID_GROUP_WACOM, USB_VENDOR_ID_WACOM, prod),\
@@ -2708,6 +2716,8 @@ const struct hid_device_id wacom_ids[] = {
{ USB_DEVICE_WACOM(0x304) },
{ USB_DEVICE_WACOM(0x307) },
{ USB_DEVICE_WACOM(0x309) },
+ { USB_DEVICE_WACOM(0x30A) },
+ { USB_DEVICE_WACOM(0x30C) },
{ USB_DEVICE_WACOM(0x30E) },
{ USB_DEVICE_WACOM(0x314) },
{ USB_DEVICE_WACOM(0x315) },
--
2.1.0
^ permalink raw reply related
* FROM: Husam Al Sayed
From: Husam Al Sayed @ 2014-09-03 18:56 UTC (permalink / raw)
Cc: m.hulsman, r.marek, khali, lm-sensors, pierre, wim,
linux-watchdog, zaga, linux-scsi, dh.herrmann, david,
inaky.perez-gonzalez, linux-wimax, wimax, mitr, acme, broonie,
lrg, linux-input, patches, tj, andrew.hendry, linux-x25, tglx,
mingo, hpa, x86, matthew.garrett, platform-driver-x86, tony.luck
FROM: Husam Al Sayed.
EMAIL:alsayedhusa@hotmail.com
Hello,
I decided to write you this proposal in good faith, believing that you will
not betray me. I am Mr. Husam Al Sayed, a Bank officer here in U.A.E.
One Mr. Peter Adams, a citizen of your country and Crude Oil dealer made a fixed deposit with my bank in 2005 for 108 calendar months, valued at US$30,000,000.00 (Thirty Million United State Dollars) the due date for this deposit contract was last 22nd of January 2014. Sadly Peter was among the death victims in the May 27 2006 Earthquake disaster in Java, Indonesia that killed over 5,000 people. He was in Indonesia on a business trip and that was how he met his untimely end. My bank management is yet to know about his death, I knew about it because he was my friend and I am his Account Officer. Peter did not mention any Next of Kin/ Heir when the account was opened, he was not married and no children. Last week my Bank Management requested that Peter should give instructions on what to do
about his funds, if to renew the contract.
I know this will happen and that is why I have been looking for a means to handle the situation, because if my Bank Directors happens to know that Peter is dead and do not have any Heir, they will take the funds for their personal use, so I don't want such to happen. That is why I am seeking your co-operation to present you as the Next of Kin/ Heir to the account, since you are a foreigner and my bank head quarters will release the account to you. There is no risk involved; the transaction will be executed under a legitimate arrangement that will protect us from any breach of law. It is better that we claim the money, than allowing the Bank Directors to take it, they are rich already. I am not a greedy person, so I am suggesting we share the funds in this ratio, 50/50%, equal sharing. Let
me know your mind on this and please do treat this information highly confidential. We shall go over the details once I receive your urgent response. Please Urgently get back to me through this email address as soon as possible:
Have a nice day and God bless. Anticipating your communication.
Regards,
FROM: Husam Al Sayed.
EMAIL: alsayedhusa@hotmail.com
_____________________________________________________________________
Presny televizny program najdete na http://www.ahaho.sk
^ permalink raw reply
* Re: hid-thingm: kernel panic on remove
From: Jiri Kosina @ 2014-09-03 14:37 UTC (permalink / raw)
To: Dylan Alex Simon; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <20140903141601.GA1866@datura.dylex.net>
On Wed, 3 Sep 2014, Dylan Alex Simon wrote:
> I think that did the trick. I've run through the whole cycle about 20 times
> in various conditions, and it seems solid so far. Thanks!
Thanks. I actually think that the minimal necessary fix is below. Could
you please do a (hopefully last) round of testing with just this patch
applied?
diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
index 134be89..c1d21fa 100644
--- a/drivers/hid/hid-thingm.c
+++ b/drivers/hid/hid-thingm.c
@@ -208,10 +208,10 @@ unregister_red:
static void thingm_remove_rgb(struct thingm_rgb *rgb)
{
- flush_work(&rgb->work);
led_classdev_unregister(&rgb->red.ldev);
led_classdev_unregister(&rgb->green.ldev);
led_classdev_unregister(&rgb->blue.ldev);
+ flush_work(&rgb->work);
}
static int thingm_probe(struct hid_device *hdev, const struct hid_device_id *id)
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* [PATCH] elantech: Fix detection of touchpad on ASUS s301l
From: Hans de Goede @ 2014-09-03 14:24 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Hans de Goede, stable
http://mariusmonton.com/?p=489
Cc: stable@vger.kernel.org
Reported-and-tested-by: Màrius Monton <marius.monton@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/input/mouse/elantech.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index daaf82f..fad7367 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1331,6 +1331,13 @@ static bool elantech_is_signature_valid(const unsigned char *param)
if (param[1] == 0)
return true;
+ /*
+ * Some models have a revision higher then 20. Meaning param[2] may
+ * be 10 or 20, skip the rates check for these.
+ */
+ if (param[0] == 0x46 && (param[1] & 0xef) == 0x0f && param[2] < 40)
+ return true;
+
for (i = 0; i < ARRAY_SIZE(rates); i++)
if (param[2] == rates[i])
return false;
--
2.1.0
^ permalink raw reply related
* Re: hid-thingm: kernel panic on remove
From: Dylan Alex Simon @ 2014-09-03 14:16 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <alpine.LNX.2.00.1409031509070.12309@pobox.suse.cz>
> Hrm, what we really want is to first destroy the LED interface, otherwise
> someone might have re-queued the workqueue through thingm_led_set() after
> it has been flushed / cancelled already.
>
> Could you please give it one more shot with the patch below? Thanks for
> your prompt testing.
>
>
> diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
> index 134be89..3d8cf5e 100644
> --- a/drivers/hid/hid-thingm.c
> +++ b/drivers/hid/hid-thingm.c
> @@ -208,10 +208,10 @@ unregister_red:
>
> static void thingm_remove_rgb(struct thingm_rgb *rgb)
> {
> - flush_work(&rgb->work);
> led_classdev_unregister(&rgb->red.ldev);
> led_classdev_unregister(&rgb->green.ldev);
> led_classdev_unregister(&rgb->blue.ldev);
> + cancel_work_sync(&rgb->work);
> }
>
> static int thingm_probe(struct hid_device *hdev, const struct hid_device_id *id)
> @@ -286,10 +286,10 @@ static void thingm_remove(struct hid_device *hdev)
> struct thingm_device *tdev = hid_get_drvdata(hdev);
> int i;
>
> + hid_hw_stop(hdev);
> +
> for (i = 0; i < tdev->fwinfo->numrgb; ++i)
> thingm_remove_rgb(tdev->rgb + i);
> -
> - hid_hw_stop(hdev);
> }
>
> static const struct hid_device_id thingm_table[] = {
>
I think that did the trick. I've run through the whole cycle about 20 times
in various conditions, and it seems solid so far. Thanks!
^ permalink raw reply
* Re: hid-thingm: kernel panic on remove
From: Jiri Kosina @ 2014-09-03 13:10 UTC (permalink / raw)
To: Dylan Alex Simon; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <20140903130348.GA1161@datura.dylex.net>
On Wed, 3 Sep 2014, Dylan Alex Simon wrote:
> Still no luck (it really is using the new module, even though it didn't
> rebuild the kernel). I should also mention this is gcc 4.9.1. I can rebuild
> with 4.8.3 if there's a reason to suspect that, though I haven't seen any
> other issues.
>
> [ 145.571979] thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
> [ 149.151153] BUG: unable to handle kernel paging request at ffffffffa00aa0cf
> [ 149.151246] IP:
> [ 149.151251] [<ffffffffa00aa0cf>] 0xffffffffa00aa0cf
> [ 149.151257] PGD 1814067 PUD 1815063 PMD 42ba9e067 PTE 0
> [ 149.151262] Oops: 0010 [#1] SMP
> [ 149.151273] Modules linked in: led_class cuse fuse snd_emu10k1 snd_hwdep snd_util_mem snd_ac97_codec ac97_bus snd_rawmidi snd_seq_device snd_pcm snd_timer ipt_ULOG [last unloaded: hid_thingm]
> [ 149.151279] CPU: 7 PID: 664 Comm: kworker/7:2 Not tainted 3.16.1-00001-g98fed6d-dirty #146
> [ 149.151280] Hardware name: empty empty/S8010-LE, BIOS 'V2.03B ' 03/15/2012
> [ 149.151286] Workqueue: events 0xffffffffa00aa040
> [ 149.151288] task: ffff88042de12010 ti: ffff8800bb96c000 task.ti: ffff8800bb96c000
> [ 149.151294] RIP: 0010:[<ffffffffa00aa0cf>] [<ffffffffa00aa0cf>] 0xffffffffa00aa0cf
> [ 149.151296] RSP: 0018:ffff8800bb96fdd0 EFLAGS: 00010286
> [ 149.151298] RAX: 0000000000000009 RBX: ffff88042ba612f0 RCX: 0000000000000302
> [ 149.151300] RDX: 0000000000000049 RSI: 0000000000000286 RDI: ffff88042aa95d80
> [ 149.151302] RBP: ffff8800bb96fdf0 R08: ffff8804aaa95d80 R09: 0000000000000282
> [ 149.151303] R10: 000000716d515080 R11: 0000000000000026 R12: ffff88042d189940
> [ 149.151305] R13: 0000000000000000 R14: ffff88043edd4e00 R15: ffff88043edd13c0
> [ 149.151308] FS: 00007f383d7a3700(0000) GS:ffff88043edc0000(0000) knlGS:0000000000000000
> [ 149.151311] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 149.151315] CR2: ffffffffa00aa0cf CR3: 0000000001813000 CR4: 00000000000407e0
> [ 149.151316] Stack:
> [ 149.151321] 010000000000a000 0001000000000063 00000000f7ea6138 ffff88042ba612f0
> [ 149.151325] ffff8800bb96fe38 ffffffff81052c2f ffff88043edd13c0 000000003edd13c0
> [ 149.151329] ffff88043edd13c0 ffff88043edd13e8 ffff88042de12010 ffff88042d189970
> [ 149.151330] Call Trace:
> [ 149.151341] [<ffffffff81052c2f>] process_one_work+0x14f/0x400
> [ 149.151349] [<ffffffff81053423>] worker_thread+0x63/0x540
> [ 149.151354] [<ffffffff810533c0>] ? create_and_start_worker+0x60/0x60
> [ 149.151359] [<ffffffff81059038>] kthread+0xe8/0x100
> [ 149.151364] [<ffffffff81058f50>] ? kthread_create_on_node+0x1b0/0x1b0
> [ 149.151370] [<ffffffff815323ec>] ret_from_fork+0x7c/0xb0
> [ 149.151374] [<ffffffff81058f50>] ? kthread_create_on_node+0x1b0/0x1b0
Hrm, what we really want is to first destroy the LED interface, otherwise
someone might have re-queued the workqueue through thingm_led_set() after
it has been flushed / cancelled already.
Could you please give it one more shot with the patch below? Thanks for
your prompt testing.
diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
index 134be89..3d8cf5e 100644
--- a/drivers/hid/hid-thingm.c
+++ b/drivers/hid/hid-thingm.c
@@ -208,10 +208,10 @@ unregister_red:
static void thingm_remove_rgb(struct thingm_rgb *rgb)
{
- flush_work(&rgb->work);
led_classdev_unregister(&rgb->red.ldev);
led_classdev_unregister(&rgb->green.ldev);
led_classdev_unregister(&rgb->blue.ldev);
+ cancel_work_sync(&rgb->work);
}
static int thingm_probe(struct hid_device *hdev, const struct hid_device_id *id)
@@ -286,10 +286,10 @@ static void thingm_remove(struct hid_device *hdev)
struct thingm_device *tdev = hid_get_drvdata(hdev);
int i;
+ hid_hw_stop(hdev);
+
for (i = 0; i < tdev->fwinfo->numrgb; ++i)
thingm_remove_rgb(tdev->rgb + i);
-
- hid_hw_stop(hdev);
}
static const struct hid_device_id thingm_table[] = {
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* Re: hid-thingm: kernel panic on remove
From: Dylan Alex Simon @ 2014-09-03 13:03 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <alpine.LNX.2.00.1409031021230.12309@pobox.suse.cz>
> I sent you wrong version of the patch, sorry for that. Could you please
> try the one below instead?
>
>
> diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
> index 134be89..dffc50d 100644
> --- a/drivers/hid/hid-thingm.c
> +++ b/drivers/hid/hid-thingm.c
> @@ -208,7 +208,7 @@ unregister_red:
>
> static void thingm_remove_rgb(struct thingm_rgb *rgb)
> {
> - flush_work(&rgb->work);
> + cancel_work_sync(&rgb->work);
> led_classdev_unregister(&rgb->red.ldev);
> led_classdev_unregister(&rgb->green.ldev);
> led_classdev_unregister(&rgb->blue.ldev);
> @@ -286,10 +286,10 @@ static void thingm_remove(struct hid_device *hdev)
> struct thingm_device *tdev = hid_get_drvdata(hdev);
> int i;
>
> + hid_hw_stop(hdev);
> +
> for (i = 0; i < tdev->fwinfo->numrgb; ++i)
> thingm_remove_rgb(tdev->rgb + i);
> -
> - hid_hw_stop(hdev);
> }
>
> static const struct hid_device_id thingm_table[] = {
>
Still no luck (it really is using the new module, even though it didn't
rebuild the kernel). I should also mention this is gcc 4.9.1. I can rebuild
with 4.8.3 if there's a reason to suspect that, though I haven't seen any
other issues.
[ 145.571979] thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
[ 149.151153] BUG: unable to handle kernel paging request at ffffffffa00aa0cf
[ 149.151246] IP:
[ 149.151251] [<ffffffffa00aa0cf>] 0xffffffffa00aa0cf
[ 149.151257] PGD 1814067 PUD 1815063 PMD 42ba9e067 PTE 0
[ 149.151262] Oops: 0010 [#1] SMP
[ 149.151273] Modules linked in: led_class cuse fuse snd_emu10k1 snd_hwdep snd_util_mem snd_ac97_codec ac97_bus snd_rawmidi snd_seq_device snd_pcm snd_timer ipt_ULOG [last unloaded: hid_thingm]
[ 149.151279] CPU: 7 PID: 664 Comm: kworker/7:2 Not tainted 3.16.1-00001-g98fed6d-dirty #146
[ 149.151280] Hardware name: empty empty/S8010-LE, BIOS 'V2.03B ' 03/15/2012
[ 149.151286] Workqueue: events 0xffffffffa00aa040
[ 149.151288] task: ffff88042de12010 ti: ffff8800bb96c000 task.ti: ffff8800bb96c000
[ 149.151294] RIP: 0010:[<ffffffffa00aa0cf>] [<ffffffffa00aa0cf>] 0xffffffffa00aa0cf
[ 149.151296] RSP: 0018:ffff8800bb96fdd0 EFLAGS: 00010286
[ 149.151298] RAX: 0000000000000009 RBX: ffff88042ba612f0 RCX: 0000000000000302
[ 149.151300] RDX: 0000000000000049 RSI: 0000000000000286 RDI: ffff88042aa95d80
[ 149.151302] RBP: ffff8800bb96fdf0 R08: ffff8804aaa95d80 R09: 0000000000000282
[ 149.151303] R10: 000000716d515080 R11: 0000000000000026 R12: ffff88042d189940
[ 149.151305] R13: 0000000000000000 R14: ffff88043edd4e00 R15: ffff88043edd13c0
[ 149.151308] FS: 00007f383d7a3700(0000) GS:ffff88043edc0000(0000) knlGS:0000000000000000
[ 149.151311] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 149.151315] CR2: ffffffffa00aa0cf CR3: 0000000001813000 CR4: 00000000000407e0
[ 149.151316] Stack:
[ 149.151321] 010000000000a000 0001000000000063 00000000f7ea6138 ffff88042ba612f0
[ 149.151325] ffff8800bb96fe38 ffffffff81052c2f ffff88043edd13c0 000000003edd13c0
[ 149.151329] ffff88043edd13c0 ffff88043edd13e8 ffff88042de12010 ffff88042d189970
[ 149.151330] Call Trace:
[ 149.151341] [<ffffffff81052c2f>] process_one_work+0x14f/0x400
[ 149.151349] [<ffffffff81053423>] worker_thread+0x63/0x540
[ 149.151354] [<ffffffff810533c0>] ? create_and_start_worker+0x60/0x60
[ 149.151359] [<ffffffff81059038>] kthread+0xe8/0x100
[ 149.151364] [<ffffffff81058f50>] ? kthread_create_on_node+0x1b0/0x1b0
[ 149.151370] [<ffffffff815323ec>] ret_from_fork+0x7c/0xb0
[ 149.151374] [<ffffffff81058f50>] ? kthread_create_on_node+0x1b0/0x1b0
[ 149.151382] Code: Bad RIP value.
[ 149.151386] RIP [<ffffffffa00aa0cf>] 0xffffffffa00aa0cf
[ 149.151387] RSP <ffff8800bb96fdd0>
[ 149.151389] CR2: ffffffffa00aa0cf
[ 149.151392] ---[ end trace 0d9114b619b5b2dc ]---
[ 149.151442] BUG: unable to handle kernel paging request at ffffffffffffffc8
^ permalink raw reply
* [PATCH] HID: add support for PenMount HID TouchScreen Driver v4
From: Christian Gmeiner @ 2014-09-03 8:33 UTC (permalink / raw)
To: linux-input; +Cc: benjamin.tissoires, jkosina, Christian Gmeiner
This patch adds a seperate hid-penmount driver to work
around an issue with the HID report descriptor. The
descriptor does not contain the ContactID usage and as
result the touchscreen is represented as normal mouse
to the system.
This driver maps the button 0 emitted by the touchscreen
to BTN_TOUCH. This makes it possible to use touch events
in userspace.
changes from v1 to v2
- incorporated feedback from Benjamin Tissoires
changes from v2 to v3
- add missing hid-core.c and hid-ids.h changes
changes from v3 to v4
- incorporated feedback from Benjamin Tissoires
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/Kconfig | 6 ++++++
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-penmount.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 58 insertions(+)
create mode 100644 drivers/hid/hid-penmount.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index c18d5d7..0351b66 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -530,6 +530,17 @@ config PANTHERLORD_FF
Say Y here if you have a PantherLord/GreenAsia based game controller
or adapter and want to enable force feedback support for it.
+config HID_PENMOUNT
+ tristate "Penmount touch device"
+ depends on USB_HID
+ ---help---
+ This selects a driver for the PenMount 6000 touch controller.
+
+ The driver works around a problem in the report descript allowing
+ the userspace to touch events instead of mouse events.
+
+ Say Y here if you have a Penmount based touch controller.
+
config HID_PETALYNX
tristate "Petalynx Maxter remote control"
depends on HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 4dbac7f..e2850d8 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_HID_NTRIG) += hid-ntrig.o
obj-$(CONFIG_HID_ORTEK) += hid-ortek.o
obj-$(CONFIG_HID_PRODIKEYS) += hid-prodikeys.o
obj-$(CONFIG_HID_PANTHERLORD) += hid-pl.o
+obj-$(CONFIG_HID_PENMOUNT) += hid-penmount.o
obj-$(CONFIG_HID_PETALYNX) += hid-petalynx.o
obj-$(CONFIG_HID_PICOLCD) += hid-picolcd.o
hid-picolcd-y += hid-picolcd_core.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 12b6e67..6827196 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1880,6 +1880,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_18) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, USB_DEVICE_ID_ORTEK_PKB1700) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ORTEK, USB_DEVICE_ID_ORTEK_WKB2000) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_6000) },
{ HID_USB_DEVICE(USB_VENDOR_ID_PETALYNX, USB_DEVICE_ID_PETALYNX_MAXTER_REMOTE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX, USB_DEVICE_ID_PRIMAX_KEYBOARD) },
#if IS_ENABLED(CONFIG_HID_ROCCAT)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 25cd674..3943ffe 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -722,6 +722,7 @@
#define USB_DEVICE_ID_PENMOUNT_PCI 0x3500
#define USB_DEVICE_ID_PENMOUNT_1610 0x1610
#define USB_DEVICE_ID_PENMOUNT_1640 0x1640
+#define USB_DEVICE_ID_PENMOUNT_6000 0x6000
#define USB_VENDOR_ID_PETALYNX 0x18b1
#define USB_DEVICE_ID_PETALYNX_MAXTER_REMOTE 0x0037
diff --git a/drivers/hid/hid-penmount.c b/drivers/hid/hid-penmount.c
new file mode 100644
index 0000000..c11dce8
--- /dev/null
+++ b/drivers/hid/hid-penmount.c
@@ -0,0 +1,49 @@
+/*
+ * HID driver for PenMount touchscreens
+ *
+ * Copyright (c) 2014 Christian Gmeiner <christian.gmeiner <at> gmail.com>
+ *
+ * based on hid-penmount copyrighted by
+ * PenMount Touch Solutions <penmount <at> seed.net.tw>
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/hid.h>
+#include "hid-ids.h"
+
+static int penmount_input_mapping(struct hid_device *hdev,
+ struct hid_input *hi, struct hid_field *field,
+ struct hid_usage *usage, unsigned long **bit, int *max)
+{
+ if ((usage->hid & HID_USAGE_PAGE) == HID_UP_BUTTON) {
+ hid_map_usage(hi, usage, bit, max, EV_KEY, BTN_TOUCH);
+ return 1;
+ }
+
+ return 0;
+}
+
+static const struct hid_device_id penmount_devices[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_PENMOUNT, USB_DEVICE_ID_PENMOUNT_6000) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, penmount_devices);
+
+static struct hid_driver penmount_driver = {
+ .name = "hid-penmount",
+ .id_table = penmount_devices,
+ .input_mapping = penmount_input_mapping,
+};
+
+module_hid_driver(penmount_driver);
+
+MODULE_AUTHOR("Christian Gmeiner <christian.gmeiner@gmail.com>");
+MODULE_DESCRIPTION("PenMount HID TouchScreen driver");
+MODULE_LICENSE("GPL");
--
1.9.3
^ permalink raw reply related
* Re: hid-thingm: kernel panic on remove
From: Jiri Kosina @ 2014-09-03 8:21 UTC (permalink / raw)
To: Dylan Alex Simon; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <20140903081723.GA1153@datura.dylex.net>
On Wed, 3 Sep 2014, Dylan Alex Simon wrote:
> > Alright, this supports my original hunch. I think I see the race. Could
> > you please try the patch below? Thanks.
> >
> >
> >
> >
> > diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
> > index 134be89..743a517 100644
> > --- a/drivers/hid/hid-thingm.c
> > +++ b/drivers/hid/hid-thingm.c
> > @@ -208,7 +208,7 @@ unregister_red:
> >
> > static void thingm_remove_rgb(struct thingm_rgb *rgb)
> > {
> > - flush_work(&rgb->work);
> > + cancel_work_sync(&rgb->work);
> > led_classdev_unregister(&rgb->red.ldev);
> > led_classdev_unregister(&rgb->green.ldev);
> > led_classdev_unregister(&rgb->blue.ldev);
>
> Same problem (only rmmod this time, no write error, but still
> doesn't happen every time):
I sent you wrong version of the patch, sorry for that. Could you please
try the one below instead?
diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
index 134be89..dffc50d 100644
--- a/drivers/hid/hid-thingm.c
+++ b/drivers/hid/hid-thingm.c
@@ -208,7 +208,7 @@ unregister_red:
static void thingm_remove_rgb(struct thingm_rgb *rgb)
{
- flush_work(&rgb->work);
+ cancel_work_sync(&rgb->work);
led_classdev_unregister(&rgb->red.ldev);
led_classdev_unregister(&rgb->green.ldev);
led_classdev_unregister(&rgb->blue.ldev);
@@ -286,10 +286,10 @@ static void thingm_remove(struct hid_device *hdev)
struct thingm_device *tdev = hid_get_drvdata(hdev);
int i;
+ hid_hw_stop(hdev);
+
for (i = 0; i < tdev->fwinfo->numrgb; ++i)
thingm_remove_rgb(tdev->rgb + i);
-
- hid_hw_stop(hdev);
}
static const struct hid_device_id thingm_table[] = {
>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* Re: hid-thingm: kernel panic on remove
From: Dylan Alex Simon @ 2014-09-03 8:17 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <alpine.LNX.2.00.1409030928200.12309@pobox.suse.cz>
>From Jiri Kosina <jkosina@suse.cz>, Wed, Sep 03, 2014 at 09:29:07AM +0200:
> On Tue, 2 Sep 2014, Dylan Alex Simon wrote:
>
> > Some combination of kernel debugging options and killing processes let it
> > survive long enough to write the backtrace to disk. A simple modprobe/rmmod
> > wasn't enough, though, it required a few tries removing the device and then
> > rmmod (though has definitely happend on just one removal before). Let me know
> > if there's anything else I can try.
>
> Alright, this supports my original hunch. I think I see the race. Could
> you please try the patch below? Thanks.
>
>
>
>
> diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
> index 134be89..743a517 100644
> --- a/drivers/hid/hid-thingm.c
> +++ b/drivers/hid/hid-thingm.c
> @@ -208,7 +208,7 @@ unregister_red:
>
> static void thingm_remove_rgb(struct thingm_rgb *rgb)
> {
> - flush_work(&rgb->work);
> + cancel_work_sync(&rgb->work);
> led_classdev_unregister(&rgb->red.ldev);
> led_classdev_unregister(&rgb->green.ldev);
> led_classdev_unregister(&rgb->blue.ldev);
Same problem (only rmmod this time, no write error, but still
doesn't happen every time):
[ 213.180726] thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
<rmmod>
[ 217.399934] BUG: unable to handle kernel paging request at ffffffffa00aa0cf
[ 217.400034] IP:
[ 217.400038] [<ffffffffa00aa0cf>] 0xffffffffa00aa0cf
[ 217.400039] PGD 1814067
[ 217.400040] PUD 1815063
[ 217.400044] PMD 42c266067 PTE 0
[ 217.400048] Oops: 0010 [#1] SMP
[ 217.400057] Modules linked in: led_class cuse fuse snd_emu10k1 snd_hwdep snd_util_mem snd_ac97_codec ac97_bus snd_rawmidi snd_seq_device snd_pcm snd_timer ipt_ULOG [last unloaded: hid_thingm]
[ 217.400061] CPU: 1 PID: 749 Comm: kworker/1:2 Not tainted 3.16.1-00001-g98fed6d-dirty #146
[ 217.400063] Hardware name: empty empty/S8010-LE, BIOS 'V2.03B ' 03/15/2012
[ 217.400066] Workqueue: events 0xffffffffa00aa040
[ 217.400068] task: ffff88042df88790 ti: ffff8800bb9e4000 task.ti: ffff8800bb9e4000
[ 217.400072] RIP: 0010:[<ffffffffa00aa0cf>] [<ffffffffa00aa0cf>] 0xffffffffa00aa0cf
[ 217.400073] RSP: 0018:ffff8800bb9e7dd0 EFLAGS: 00010286
[ 217.400075] RAX: 0000000000000009 RBX: ffff88042c285af0 RCX: 0000000000000302
[ 217.400077] RDX: 0000000000000078 RSI: 0000000000000286 RDI: ffff88042d0e1a80
[ 217.400078] RBP: ffff8800bb9e7df0 R08: ffff8804ad0e1a80 R09: 0000000000000282
[ 217.400079] R10: 0000000000000001 R11: 000000002c95c8ba R12: ffff88042c8b0580
[ 217.400081] R13: 0000000000000000 R14: ffff88043ec54e00 R15: ffff88043ec513c0
[ 217.400087] FS: 00007f02217fc700(0000) GS:ffff88043ec40000(0000) knlGS:0000000000000000
[ 217.400089] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 217.400091] CR2: ffffffffa00aa0cf CR3: 000000042af90000 CR4: 00000000000407e0
[ 217.400091] Stack:
[ 217.400096] 010000000000a000 0001000000000063 000000000ba997f6 ffff88042c285af0
[ 217.400099] ffff8800bb9e7e38 ffffffff81052c2f ffff88043ec513c0 000000003ec513c0
[ 217.400104] ffff88043ec513c0 ffff88043ec513e8 ffff88042df88790 ffff88042c8b05b0
[ 217.400105] Call Trace:
[ 217.400114] [<ffffffff81052c2f>] process_one_work+0x14f/0x400
[ 217.400120] [<ffffffff81053423>] worker_thread+0x63/0x540
[ 217.400125] [<ffffffff810533c0>] ? create_and_start_worker+0x60/0x60
[ 217.400130] [<ffffffff81059038>] kthread+0xe8/0x100
[ 217.400136] [<ffffffff8152de24>] ? schedule+0x24/0x60
[ 217.400144] [<ffffffff81058f50>] ? kthread_create_on_node+0x1b0/0x1b0
[ 217.400149] [<ffffffff815323ec>] ret_from_fork+0x7c/0xb0
[ 217.400153] [<ffffffff81058f50>] ? kthread_create_on_node+0x1b0/0x1b0
[ 217.400159] Code: Bad RIP value.
[ 217.400163] RIP [<ffffffffa00aa0cf>] 0xffffffffa00aa0cf
[ 217.400164] RSP <ffff8800bb9e7dd0>
[ 217.400165] CR2: ffffffffa00aa0cf
[ 217.400168] ---[ end trace 9bd9c9db3e942a93 ]---
^ permalink raw reply
* Re: hid-thingm: kernel panic on remove
From: Jiri Kosina @ 2014-09-03 7:29 UTC (permalink / raw)
To: Dylan Alex Simon; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <20140903023531.GA1128@datura.dylex.net>
On Tue, 2 Sep 2014, Dylan Alex Simon wrote:
> Some combination of kernel debugging options and killing processes let it
> survive long enough to write the backtrace to disk. A simple modprobe/rmmod
> wasn't enough, though, it required a few tries removing the device and then
> rmmod (though has definitely happend on just one removal before). Let me know
> if there's anything else I can try.
>
> <insmod>
> [ 28.855960] thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
> <rmmod;insmod>
> [ 147.037008] thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
> <unplug>
> [ 218.496688] usb 1-3.1.4: USB disconnect, device number 7
> [ 218.502278] hid : failed to write color
> [ 218.506131] hid : failed to write color
> <plug>
> [ 233.557300] usb 1-3.1.4: new full-speed USB device number 8 using ehci-pci
> [ 233.657195] usb 1-3.1.4: config 1 interface 0 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1
> [ 233.660402] thingm 0003:27B8:01ED.0005: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
> <rmmod>
> [ 253.682724] BUG: unable to handle kernel paging request at ffffffffa00af0cf
> [ 253.682807] IP:
> [ 253.682812] [<ffffffffa00af0cf>] 0xffffffffa00af0cf
> [ 253.682817] PGD 1814067 PUD 1815063 PMD 42cace067 PTE 0
> [ 253.682820] Oops: 0010 [#1] SMP
> [ 253.682830] Modules linked in: led_class cuse fuse snd_emu10k1 snd_hwdep snd_util_mem snd_ac97_codec ac97_bus snd_rawmidi snd_seq_device snd_pcm snd_timer ipt_ULOG [last unloaded: hid_thingm]
> [ 253.682833] CPU: 0 PID: 849 Comm: kworker/0:2 Not tainted 3.16.1-00001-g98fed6d #145
> [ 253.682835] Hardware name: empty empty/S8010-LE, BIOS 'V2.03B ' 03/15/2012
> [ 253.682838] Workqueue: events 0xffffffffa00af040
> [ 253.682840] task: ffff88042e330050 ti: ffff880429d8c000 task.ti: ffff880429d8c000
> [ 253.682844] RIP: 0010:[<ffffffffa00af0cf>] [<ffffffffa00af0cf>] 0xffffffffa00af0cf
> [ 253.682846] RSP: 0018:ffff880429d8fdd0 EFLAGS: 00010286
> [ 253.682847] RAX: 0000000000000009 RBX: ffff88042ca83af0 RCX: 0000000000000302
> [ 253.682849] RDX: 0000000000000078 RSI: 0000000000000286 RDI: ffff88042caaade0
> [ 253.682850] RBP: ffff880429d8fdf0 R08: ffff8804acaaade0 R09: 0000000000000282
> [ 253.682852] R10: ffff88042c93dbc0 R11: 000000000000001f R12: ffff88042c885e80
> [ 253.682853] R13: 0000000000000000 R14: ffff88043ec14e00 R15: ffff88043ec113c0
> [ 253.682856] FS: 00007f58ebcec700(0000) GS:ffff88043ec00000(0000) knlGS:0000000000000000
> [ 253.682857] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 253.682859] CR2: ffffffffa00af0cf CR3: 0000000001813000 CR4: 00000000000407f0
> [ 253.682859] Stack:
> [ 253.682863] 010000000000a000 0001000000000063 000000008867f918 ffff88042ca83af0
> [ 253.682866] ffff880429d8fe38 ffffffff81052c2f ffff88043ec113c0 000000003ec113c0
> [ 253.682869] ffff88043ec113c0 ffff88043ec113e8 ffff88042e330050 ffff88042c885eb0
> [ 253.682870] Call Trace:
> [ 253.682878] [<ffffffff81052c2f>] process_one_work+0x14f/0x400
> [ 253.682882] [<ffffffff81053423>] worker_thread+0x63/0x540
> [ 253.682886] [<ffffffff810533c0>] ? create_and_start_worker+0x60/0x60
> [ 253.682889] [<ffffffff81059038>] kthread+0xe8/0x100
> [ 253.682893] [<ffffffff81058f50>] ? kthread_create_on_node+0x1b0/0x1b0
> [ 253.682897] [<ffffffff815323ec>] ret_from_fork+0x7c/0xb0
> [ 253.682900] [<ffffffff81058f50>] ? kthread_create_on_node+0x1b0/0x1b0
Alright, this supports my original hunch. I think I see the race. Could
you please try the patch below? Thanks.
diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
index 134be89..743a517 100644
--- a/drivers/hid/hid-thingm.c
+++ b/drivers/hid/hid-thingm.c
@@ -208,7 +208,7 @@ unregister_red:
static void thingm_remove_rgb(struct thingm_rgb *rgb)
{
- flush_work(&rgb->work);
+ cancel_work_sync(&rgb->work);
led_classdev_unregister(&rgb->red.ldev);
led_classdev_unregister(&rgb->green.ldev);
led_classdev_unregister(&rgb->blue.ldev);
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* Re: [PATCH 0/2] input: Add INPUT_PROP_POINTING_STICK property
From: Peter Hutterer @ 2014-09-03 3:24 UTC (permalink / raw)
To: David Herrmann
Cc: Hans de Goede, Dmitry Torokhov, Peter Hutterer,
Benjamin Tissoires, open list:HID CORE LAYER
In-Reply-To: <CANq1E4RMKmM3Qk09-hd49VSH2On_n8-x7sOp7OKd9Ww-48sLzw@mail.gmail.com>
On Tue, Sep 02, 2014 at 04:50:53PM +0200, David Herrmann wrote:
> Hi
>
> On Tue, Sep 2, 2014 at 4:40 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> > On 09/02/2014 02:55 PM, David Herrmann wrote:
> >> Hi
> >>
> >> On Tue, Sep 2, 2014 at 2:43 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> >>> Hi,
> >>>
> >>> It is useful for userspace to know that they're not dealing with a regular
> >>> mouse but rather with a pointing stick (e.g. a trackpoint) so that userspace
> >>> can e.g. automatically enable middle button scrollwheel emulation.
> >>>
> >>> It is impossible to tell the difference from the evdev info without resorting
> >>> to putting a list of device / driver names in userspace, this is undesirable.
> >>
> >> ..so it is better to put that table into the kernel?
> >
> > No not a table, at the kernel level we actually have different drivers
> > for pointer sticks and for other mouse (and mouse like devices), so this is
> > a simple matter of adding a single line of code to all of 4 drivers.
> >
> > We could have a table in userspace matching the driver/model strings used
> > by those 4 drivers, but what if a 5th pops up ?
>
> Ok, for now it's pretty easy as all "pointing stick" drivers are
> already separate in the kernel. But imagine a new generation of
> "pointing stick" devices is an HID device handled by hid-input.c. What
> do you do? To set the INPUT_PROPERTY bit, you need to add a driver for
> this vid/did combination. Seems overkill, so we'd probably not set
> this property bit for this device and let user-space deal with it. Now
> we end up with two places to store such information.
right now, there's no ioctl to set a property on a device. that'd be a
requirement for a udev hwdb-like thing, unless you want clients to rely on
pulling the information from two places and merging it in some strategy
that's not well defined yet.
I'm all for a userspace hwdb, but this is some bigger project that afaik
hasn't been worked on beyond the libinputmapper discussions we had a year or
so ago.
Cheers,
Peter
> We already fix scancode/keycode mappings via hwdb as it would be
> excessive to write kernel drivers for all devices just to fix those.
> Imo, device properties are very similar to this. We have to draw a
> line between properties the kernel should detect and expose, and
> properties we detect in user-space. We already gave up defining ABS_
> axes for everything (I mean, we report all kinds of data via ABS_X,
> ranging from trackpad, to pressure and accelerometer data). User-space
> needs to detect what devices it deals with, to know what the different
> axes event-bits mean.
>
> Yeah, the POINTING_STICK property turns out to be trivial, so please
> go ahead. I just want to remind you, that we need a user-space
> database, anyway. And hwdb entries can be added via simple distro
> updates (even users can regenerate it themselves). Kernel driver
> changes are way more heavy.. and slow.
>
> Thanks
> David
> --
^ permalink raw reply
* Re: [PATCH 2/2] input/mouse: Add missing POINTER / DIRECT properties to a bunch of drivers
From: Peter Hutterer @ 2014-09-03 3:21 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Hans de Goede, Dmitry Torokhov, Peter Hutterer, linux-input
In-Reply-To: <20140902143834.GC25423@mail.corp.redhat.com>
On Tue, Sep 02, 2014 at 10:38:34AM -0400, Benjamin Tissoires wrote:
> On Sep 02 2014 or thereabouts, Hans de Goede wrote:
> > I've not done a full audit of all mouse drivers, I noticed these ones were
> > missing the POINTER property while working on the POINTING_STICK property.
>
> I am not sure about this one. INPUT_PROP_POINTER is the default behavior
> when no properties are set. The current Xorg/libinput code should
> already be aware of that and uses this to be able to be backward
> compatible.
> Adding the info now, will not change anything in the user-space code and
> we will not be able to remove the compat code before a long time.
>
> So, really, I am not in favor, nor I will opposite my vote regarding
> this patch.
If we could reliably use the property in userspace it would make detecting
things like joysticks or accelerometers a lot easier. So setting it where we
know it's a pointer device may be helpful.
Cheers,
Peter
> >
> > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > ---
> > drivers/input/mouse/alps.c | 1 +
> > drivers/input/mouse/elantech.c | 1 +
> > drivers/input/mouse/psmouse-base.c | 2 ++
> > drivers/input/mouse/synaptics_usb.c | 5 +++++
> > drivers/input/mouse/trackpoint.c | 1 +
> > 5 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> > index 9de3c25..d7020ad 100644
> > --- a/drivers/input/mouse/alps.c
> > +++ b/drivers/input/mouse/alps.c
> > @@ -2373,6 +2373,7 @@ int alps_init(struct psmouse *psmouse)
> > dev2->keybit[BIT_WORD(BTN_LEFT)] =
> > BIT_MASK(BTN_LEFT) | BIT_MASK(BTN_MIDDLE) | BIT_MASK(BTN_RIGHT);
> >
> > + __set_bit(INPUT_PROP_POINTER, dev2->propbit);
> > if (priv->flags & ALPS_DUALPOINT)
> > __set_bit(INPUT_PROP_POINTING_STICK, dev2->propbit);
> >
> > diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> > index c767f7e..daaf82f 100644
> > --- a/drivers/input/mouse/elantech.c
> > +++ b/drivers/input/mouse/elantech.c
> > @@ -1608,6 +1608,7 @@ int elantech_init(struct psmouse *psmouse)
> > BIT_MASK(BTN_LEFT) | BIT_MASK(BTN_MIDDLE) |
> > BIT_MASK(BTN_RIGHT);
> >
> > + __set_bit(INPUT_PROP_POINTER, tp_dev->propbit);
> > __set_bit(INPUT_PROP_POINTING_STICK, tp_dev->propbit);
> >
> > error = input_register_device(etd->tp_dev);
> > diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c
> > index 5c1237d..a44d655 100644
> > --- a/drivers/input/mouse/psmouse-base.c
> > +++ b/drivers/input/mouse/psmouse-base.c
> > @@ -685,6 +685,8 @@ static void psmouse_apply_defaults(struct psmouse *psmouse)
> > __set_bit(REL_X, input_dev->relbit);
> > __set_bit(REL_Y, input_dev->relbit);
> >
> > + __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
> > +
> > psmouse->set_rate = psmouse_set_rate;
> > psmouse->set_resolution = psmouse_set_resolution;
> > psmouse->poll = psmouse_poll;
> > diff --git a/drivers/input/mouse/synaptics_usb.c b/drivers/input/mouse/synaptics_usb.c
> > index db3973d..6bcc018 100644
> > --- a/drivers/input/mouse/synaptics_usb.c
> > +++ b/drivers/input/mouse/synaptics_usb.c
> > @@ -402,6 +402,11 @@ static int synusb_probe(struct usb_interface *intf,
> > __set_bit(BTN_TOOL_TRIPLETAP, input_dev->keybit);
> > }
> >
> > + if (synusb->flags & SYNUSB_TOUCHSCREEN)
> > + __set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
> > + else
> > + __set_bit(INPUT_PROP_POINTER, input_dev->propbit);
> > +
> > __set_bit(BTN_LEFT, input_dev->keybit);
> > __set_bit(BTN_RIGHT, input_dev->keybit);
> > __set_bit(BTN_MIDDLE, input_dev->keybit);
> > diff --git a/drivers/input/mouse/trackpoint.c b/drivers/input/mouse/trackpoint.c
> > index b377462..30c8b69 100644
> > --- a/drivers/input/mouse/trackpoint.c
> > +++ b/drivers/input/mouse/trackpoint.c
> > @@ -393,6 +393,7 @@ int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
> > if ((button_info & 0x0f) >= 3)
> > __set_bit(BTN_MIDDLE, psmouse->dev->keybit);
> >
> > + __set_bit(INPUT_PROP_POINTER, psmouse->dev->propbit);
> > __set_bit(INPUT_PROP_POINTING_STICK, psmouse->dev->propbit);
> >
> > trackpoint_defaults(psmouse->private);
> > --
> > 2.1.0
> >
> --
> 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 1/2] input: Add INPUT_PROP_POINTING_STICK property
From: Peter Hutterer @ 2014-09-03 3:18 UTC (permalink / raw)
To: Hans de Goede
Cc: Dmitry Torokhov, Peter Hutterer, Benjamin Tissoires, linux-input
In-Reply-To: <1409661804-10489-2-git-send-email-hdegoede@redhat.com>
On Tue, Sep 02, 2014 at 02:43:23PM +0200, Hans de Goede wrote:
> It is useful for userspace to know that there not dealing with a regular
> mouse but rather with a pointing stick (e.g. a trackpoint) so that userspace
> can e.g. automatically enable middle button scrollwheel emulation.
>
> It is impossible to tell the difference from the evdev info without resorting
> to putting a list of device / driver names in userspace, this is undesirable.
>
> Add a property which allows userspace to see if a device is a pointing
> stick, and set it on all the pointing stick drivers.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Cheers,
Peter
> ---
> drivers/input/mouse/alps.c | 3 +++
> drivers/input/mouse/elantech.c | 3 +++
> drivers/input/mouse/synaptics_usb.c | 1 +
> drivers/input/mouse/trackpoint.c | 2 ++
> include/uapi/linux/input.h | 1 +
> 5 files changed, 10 insertions(+)
>
> diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
> index a59a1a6..9de3c25 100644
> --- a/drivers/input/mouse/alps.c
> +++ b/drivers/input/mouse/alps.c
> @@ -2373,6 +2373,9 @@ int alps_init(struct psmouse *psmouse)
> dev2->keybit[BIT_WORD(BTN_LEFT)] =
> BIT_MASK(BTN_LEFT) | BIT_MASK(BTN_MIDDLE) | BIT_MASK(BTN_RIGHT);
>
> + if (priv->flags & ALPS_DUALPOINT)
> + __set_bit(INPUT_PROP_POINTING_STICK, dev2->propbit);
> +
> if (input_register_device(priv->dev2))
> goto init_fail;
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 63533e5..c767f7e 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -1607,6 +1607,9 @@ int elantech_init(struct psmouse *psmouse)
> tp_dev->keybit[BIT_WORD(BTN_LEFT)] =
> BIT_MASK(BTN_LEFT) | BIT_MASK(BTN_MIDDLE) |
> BIT_MASK(BTN_RIGHT);
> +
> + __set_bit(INPUT_PROP_POINTING_STICK, tp_dev->propbit);
> +
> error = input_register_device(etd->tp_dev);
> if (error < 0)
> goto init_fail_tp_reg;
> diff --git a/drivers/input/mouse/synaptics_usb.c b/drivers/input/mouse/synaptics_usb.c
> index e122bda..db3973d 100644
> --- a/drivers/input/mouse/synaptics_usb.c
> +++ b/drivers/input/mouse/synaptics_usb.c
> @@ -387,6 +387,7 @@ static int synusb_probe(struct usb_interface *intf,
> __set_bit(EV_REL, input_dev->evbit);
> __set_bit(REL_X, input_dev->relbit);
> __set_bit(REL_Y, input_dev->relbit);
> + __set_bit(INPUT_PROP_POINTING_STICK, input_dev->propbit);
> input_set_abs_params(input_dev, ABS_PRESSURE, 0, 127, 0, 0);
> } else {
> input_set_abs_params(input_dev, ABS_X,
> diff --git a/drivers/input/mouse/trackpoint.c b/drivers/input/mouse/trackpoint.c
> index ca843b6..b377462 100644
> --- a/drivers/input/mouse/trackpoint.c
> +++ b/drivers/input/mouse/trackpoint.c
> @@ -393,6 +393,8 @@ int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
> if ((button_info & 0x0f) >= 3)
> __set_bit(BTN_MIDDLE, psmouse->dev->keybit);
>
> + __set_bit(INPUT_PROP_POINTING_STICK, psmouse->dev->propbit);
> +
> trackpoint_defaults(psmouse->private);
>
> error = trackpoint_power_on_reset(&psmouse->ps2dev);
> diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
> index 19df18c..1874ebe 100644
> --- a/include/uapi/linux/input.h
> +++ b/include/uapi/linux/input.h
> @@ -165,6 +165,7 @@ struct input_keymap_entry {
> #define INPUT_PROP_BUTTONPAD 0x02 /* has button(s) under pad */
> #define INPUT_PROP_SEMI_MT 0x03 /* touch rectangle only */
> #define INPUT_PROP_TOPBUTTONPAD 0x04 /* softbuttons at top of pad */
> +#define INPUT_PROP_POINTING_STICK 0x05 /* is a pointing stick */
>
> #define INPUT_PROP_MAX 0x1f
> #define INPUT_PROP_CNT (INPUT_PROP_MAX + 1)
> --
> 2.1.0
^ permalink raw reply
* Re: hid-thingm: kernel panic on remove
From: Dylan Alex Simon @ 2014-09-03 2:35 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input
In-Reply-To: <alpine.LNX.2.00.1409022328470.12309@pobox.suse.cz>
>From Jiri Kosina <jkosina@suse.cz>, Tue, Sep 02, 2014 at 11:32:30PM +0200:
> On Tue, 2 Sep 2014, Benjamin Tissoires wrote:
>
> > > Whenever either disconnecting the USB device or simply rmmod'ing the module
> > > (even when not in use), I get a kernel panic. I haven't managed to capture a
> > > backtrace, but at least the first two lines were saved after an rmmod:
> > >
> > > 18:53:17 kernel: thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
> > > <snip, rmmod hid-thingm:>
> > > 08:38:42 kernel: BUG: unable to handle kernel paging request at fffffffb8a80aaf8
> > > 08:38:42 kernel: IP: [<ffffffff8106e30c>] osq_lock+0x3c/0x110
>
> Hmm, so the only lock that is taken in thingm driver itself is
> rgb->tdev->lock, which is thingm_device->lock, properly initialized in
> _probe().
>
> So my first thought was that the work is not cancelled properly, causing
> use-after-free on the lock with the workqueue firing at the time the
> drvier has cleaned up everything, but that doesn't seem to be the case, as
> thingm_remove() -> thingm_remove_rgb() seems to be doing the right thing.
>
> Dylan, is there any chance for you to capture more complete backtrace from
> the oops? serial console, netconsole, anything?
Some combination of kernel debugging options and killing processes let it
survive long enough to write the backtrace to disk. A simple modprobe/rmmod
wasn't enough, though, it required a few tries removing the device and then
rmmod (though has definitely happend on just one removal before). Let me know
if there's anything else I can try.
<insmod>
[ 28.855960] thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
<rmmod;insmod>
[ 147.037008] thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
<unplug>
[ 218.496688] usb 1-3.1.4: USB disconnect, device number 7
[ 218.502278] hid : failed to write color
[ 218.506131] hid : failed to write color
<plug>
[ 233.557300] usb 1-3.1.4: new full-speed USB device number 8 using ehci-pci
[ 233.657195] usb 1-3.1.4: config 1 interface 0 altsetting 0 has 2 endpoint descriptors, different from the interface descriptor's value: 1
[ 233.660402] thingm 0003:27B8:01ED.0005: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
<rmmod>
[ 253.682724] BUG: unable to handle kernel paging request at ffffffffa00af0cf
[ 253.682807] IP:
[ 253.682812] [<ffffffffa00af0cf>] 0xffffffffa00af0cf
[ 253.682817] PGD 1814067 PUD 1815063 PMD 42cace067 PTE 0
[ 253.682820] Oops: 0010 [#1] SMP
[ 253.682830] Modules linked in: led_class cuse fuse snd_emu10k1 snd_hwdep snd_util_mem snd_ac97_codec ac97_bus snd_rawmidi snd_seq_device snd_pcm snd_timer ipt_ULOG [last unloaded: hid_thingm]
[ 253.682833] CPU: 0 PID: 849 Comm: kworker/0:2 Not tainted 3.16.1-00001-g98fed6d #145
[ 253.682835] Hardware name: empty empty/S8010-LE, BIOS 'V2.03B ' 03/15/2012
[ 253.682838] Workqueue: events 0xffffffffa00af040
[ 253.682840] task: ffff88042e330050 ti: ffff880429d8c000 task.ti: ffff880429d8c000
[ 253.682844] RIP: 0010:[<ffffffffa00af0cf>] [<ffffffffa00af0cf>] 0xffffffffa00af0cf
[ 253.682846] RSP: 0018:ffff880429d8fdd0 EFLAGS: 00010286
[ 253.682847] RAX: 0000000000000009 RBX: ffff88042ca83af0 RCX: 0000000000000302
[ 253.682849] RDX: 0000000000000078 RSI: 0000000000000286 RDI: ffff88042caaade0
[ 253.682850] RBP: ffff880429d8fdf0 R08: ffff8804acaaade0 R09: 0000000000000282
[ 253.682852] R10: ffff88042c93dbc0 R11: 000000000000001f R12: ffff88042c885e80
[ 253.682853] R13: 0000000000000000 R14: ffff88043ec14e00 R15: ffff88043ec113c0
[ 253.682856] FS: 00007f58ebcec700(0000) GS:ffff88043ec00000(0000) knlGS:0000000000000000
[ 253.682857] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 253.682859] CR2: ffffffffa00af0cf CR3: 0000000001813000 CR4: 00000000000407f0
[ 253.682859] Stack:
[ 253.682863] 010000000000a000 0001000000000063 000000008867f918 ffff88042ca83af0
[ 253.682866] ffff880429d8fe38 ffffffff81052c2f ffff88043ec113c0 000000003ec113c0
[ 253.682869] ffff88043ec113c0 ffff88043ec113e8 ffff88042e330050 ffff88042c885eb0
[ 253.682870] Call Trace:
[ 253.682878] [<ffffffff81052c2f>] process_one_work+0x14f/0x400
[ 253.682882] [<ffffffff81053423>] worker_thread+0x63/0x540
[ 253.682886] [<ffffffff810533c0>] ? create_and_start_worker+0x60/0x60
[ 253.682889] [<ffffffff81059038>] kthread+0xe8/0x100
[ 253.682893] [<ffffffff81058f50>] ? kthread_create_on_node+0x1b0/0x1b0
[ 253.682897] [<ffffffff815323ec>] ret_from_fork+0x7c/0xb0
[ 253.682900] [<ffffffff81058f50>] ? kthread_create_on_node+0x1b0/0x1b0
[ 253.682906] Code: Bad RIP value.
[ 253.682908] RIP [<ffffffffa00af0cf>] 0xffffffffa00af0cf
[ 253.682909] RSP <ffff880429d8fdd0>
[ 253.682910] CR2: ffffffffa00af0cf
[ 253.682913] ---[ end trace 38f1b789201cd967 ]---
[ 253.682946] BUG: unable to handle kernel paging request at ffffffffffffffc8
[ 253.682950] IP: [<ffffffff810595eb>] kthread_data+0xb/0x20
[ 253.682953] PGD 1814067 PUD 1816067 PMD 0
[ 253.682955] Oops: 0000 [#2] SMP
[ 253.682964] Modules linked in: led_class cuse fuse snd_emu10k1 snd_hwdep snd_util_mem snd_ac97_codec ac97_bus snd_rawmidi snd_seq_device snd_pcm snd_timer ipt_ULOG [last unloaded: hid_thingm]
[ 253.682967] CPU: 0 PID: 849 Comm: kworker/0:2 Tainted: G D 3.16.1-00001-g98fed6d #145
[ 253.682969] Hardware name: empty empty/S8010-LE, BIOS 'V2.03B ' 03/15/2012
[ 253.682987] task: ffff88042e330050 ti: ffff880429d8c000 task.ti: ffff880429d8c000
[ 253.682990] RIP: 0010:[<ffffffff810595eb>] [<ffffffff810595eb>] kthread_data+0xb/0x20
[ 253.682992] RSP: 0018:ffff880429d8fa40 EFLAGS: 00010002
[ 253.682993] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffff80cd76
[ 253.682995] RDX: 0000000050f1eeb6 RSI: 0000000000000000 RDI: ffff88042e330050
[ 253.682996] RBP: ffff880429d8fa40 R08: ffff88042c8928a0 R09: 0000000000000001
[ 253.682998] R10: 00000000000001ea R11: 0000000000000000 R12: 0000000000000000
[ 253.682999] R13: ffff88042e330400 R14: 0000000000000000 R15: ffff88042e330050
[ 253.683002] FS: 00007f58ebcec700(0000) GS:ffff88043ec00000(0000) knlGS:0000000000000000
[ 253.683003] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 253.683005] CR2: 0000000000000028 CR3: 0000000001813000 CR4: 00000000000407f0
[ 253.683005] Stack:
[ 253.683009] ffff880429d8fa58 ffffffff8105396c ffff88043ec11c40 ffff880429d8fac0
[ 253.683011] ffffffff8152db81 000000000000a000 ffff88042e330050 ffff880429d8fa88
[ 253.683014] ffff880429d8ffd8 ffff880429d8fad0 ffffffff8103e2a9 ffff88042e330610
[ 253.683015] Call Trace:
[ 253.683019] [<ffffffff8105396c>] wq_worker_sleeping+0xc/0x90
[ 253.683024] [<ffffffff8152db81>] __schedule+0x4b1/0x730
[ 253.683029] [<ffffffff8103e2a9>] ? release_task+0x249/0x3d0
[ 253.683033] [<ffffffff8152de24>] schedule+0x24/0x60
[ 253.683036] [<ffffffff8103eb92>] do_exit+0x762/0xa10
[ 253.683041] [<ffffffff81005998>] oops_end+0x68/0x90
[ 253.683046] [<ffffffff8103242c>] no_context+0x12c/0x2f0
[ 253.683050] [<ffffffff81032675>] __bad_area_nosemaphore+0x85/0x1f0
[ 253.683054] [<ffffffff810327ee>] bad_area_nosemaphore+0xe/0x10
[ 253.683058] [<ffffffff81032b16>] __do_page_fault+0xb6/0x4d0
[ 253.683062] [<ffffffff81531e09>] ? _raw_spin_unlock_irq+0x9/0x10
[ 253.683066] [<ffffffff8141a43f>] ? urb_destroy+0x1f/0x30
[ 253.683069] [<ffffffff8141ad09>] ? usb_free_urb+0x19/0x20
[ 253.683072] [<ffffffff8141b342>] ? usb_start_wait_urb+0xa2/0xf0
[ 253.683075] [<ffffffff81032f5c>] do_page_fault+0xc/0x10
[ 253.683079] [<ffffffff81533922>] page_fault+0x22/0x30
[ 253.683084] [<ffffffff81052c2f>] process_one_work+0x14f/0x400
[ 253.683087] [<ffffffff81053423>] worker_thread+0x63/0x540
[ 253.683091] [<ffffffff810533c0>] ? create_and_start_worker+0x60/0x60
[ 253.683093] [<ffffffff81059038>] kthread+0xe8/0x100
[ 253.683097] [<ffffffff81058f50>] ? kthread_create_on_node+0x1b0/0x1b0
[ 253.683100] [<ffffffff815323ec>] ret_from_fork+0x7c/0xb0
[ 253.683103] [<ffffffff81058f50>] ? kthread_create_on_node+0x1b0/0x1b0
[ 253.683132] Code: 00 48 89 e5 5d 48 8b 40 b8 48 c1 e8 02 83 e0 01 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 8b 87 58 03 00 00 55 48 89 e5 <48> 8b 40 c8 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
[ 253.683135] RIP [<ffffffff810595eb>] kthread_data+0xb/0x20
[ 253.683136] RSP <ffff880429d8fa40>
[ 253.683137] CR2: ffffffffffffffc8
[ 253.683139] ---[ end trace 38f1b789201cd968 ]---
[ 253.683140] Fixing recursive fault but reboot is needed!
[ 313.753106] INFO: rcu_sched detected stalls on CPUs/tasks: { 0} (detected by 7, t=18003 jiffies, g=1479, c=1478, q=300)
<more traces follow but probably irrelevant>
^ permalink raw reply
* Re: hid-thingm: kernel panic on remove
From: Jiri Kosina @ 2014-09-02 21:32 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Dylan Alex Simon, linux-input
In-Reply-To: <54062150.2010800@gmail.com>
On Tue, 2 Sep 2014, Benjamin Tissoires wrote:
> > Whenever either disconnecting the USB device or simply rmmod'ing the module
> > (even when not in use), I get a kernel panic. I haven't managed to capture a
> > backtrace, but at least the first two lines were saved after an rmmod:
> >
> > 18:53:17 kernel: thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
> > <snip, rmmod hid-thingm:>
> > 08:38:42 kernel: BUG: unable to handle kernel paging request at fffffffb8a80aaf8
> > 08:38:42 kernel: IP: [<ffffffff8106e30c>] osq_lock+0x3c/0x110
Hmm, so the only lock that is taken in thingm driver itself is
rgb->tdev->lock, which is thingm_device->lock, properly initialized in
_probe().
So my first thought was that the work is not cancelled properly, causing
use-after-free on the lock with the workqueue firing at the time the
drvier has cleaned up everything, but that doesn't seem to be the case, as
thingm_remove() -> thingm_remove_rgb() seems to be doing the right thing.
Dylan, is there any chance for you to capture more complete backtrace from
the oops? serial console, netconsole, anything?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: hid-thingm: kernel panic on remove
From: Dylan Alex Simon @ 2014-09-02 20:12 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: linux-input, Jiri Kosina
In-Reply-To: <54062150.2010800@gmail.com>
>From Benjamin Tissoires <benjamin.tissoires@gmail.com>, Tue, Sep 02, 2014 at 03:58:08PM -0400:
> Hi,
>
> On 09/02/2014 01:46 PM, Dylan Alex Simon wrote:
> > Whenever either disconnecting the USB device or simply rmmod'ing the module
> > (even when not in use), I get a kernel panic. I haven't managed to capture a
> > backtrace, but at least the first two lines were saved after an rmmod.
> >
> > Let me know if you'd like me to try to capture more info, but this problem
> > seems very reproducible (at least with a mk2 device; I never had the problem on
> > older kernels with a mk1). I do direct write()s to the hidraw device, but
> > don't otherwise use the driver while it's loaded.
> >
> > Also at https://bugzilla.kernel.org/show_bug.cgi?id=83751
>
> Do you happen to see a "unsupported firmware " error when plugging your device?
>
> If so, then the following patch should help with the panic (but you will an other one to be able to use again your device).
No, no unsupported firmware messages. The device and driver work fine
otherwise. It registers (and unregisters) all the devices. Hotplug events:
18:53:17 kernel: thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
18:53:17 hotplug: 694 add module path:/module/hid_thingm
18:53:17 hotplug: 695 add hidraw path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/hidraw/hidraw3
18:53:17 hotplug: 696 add leds path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/leds/thingm3:red:led1
18:53:17 hotplug: 698 add leds path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/leds/thingm3:blue:led1
18:53:17 hotplug: 697 add leds path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/leds/thingm3:green:led1
18:53:17 hotplug: 699 add leds path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/leds/thingm3:red:led2
18:53:17 hotplug: 700 add leds path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/leds/thingm3:green:led2
18:53:17 hotplug: 701 add leds path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/leds/thingm3:blue:led2
18:53:17 hotplug: 702 add drivers path:/bus/hid/drivers/thingm
<snip, rmmod:>
08:38:42 hotplug: 710 remove leds path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/leds/thingm3:red:led1
08:38:42 hotplug: 712 remove leds path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/leds/thingm3:blue:led1
08:38:42 hotplug: 711 remove leds path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/leds/thingm3:green:led1
08:38:42 hotplug: 714 remove leds path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/leds/thingm3:green:led2
08:38:42 hotplug: 713 remove leds path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/leds/thingm3:red:led2
08:38:42 hotplug: 715 remove leds path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/leds/thingm3:blue:led2
08:38:42 hotplug: 716 remove hidraw path:/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3.1/1-3.1.4/1-3.1.4:1.0/0003:27B8:01ED.0004/hidraw/hidraw3
08:38:42 kernel: BUG: unable to handle kernel paging request at fffffffb8a80aaf8
08:38:42 kernel: IP: [<ffffffff8106e30c>] osq_lock+0x3c/0x110
^ permalink raw reply
* Re: hid-thingm: kernel panic on remove
From: Benjamin Tissoires @ 2014-09-02 19:58 UTC (permalink / raw)
To: Dylan Alex Simon, linux-input, Jiri Kosina
In-Reply-To: <20140902174659.GA1811@datura.dylex.net>
Hi,
On 09/02/2014 01:46 PM, Dylan Alex Simon wrote:
> Whenever either disconnecting the USB device or simply rmmod'ing the module
> (even when not in use), I get a kernel panic. I haven't managed to capture a
> backtrace, but at least the first two lines were saved after an rmmod:
>
> 18:53:17 kernel: thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
> <snip, rmmod hid-thingm:>
> 08:38:42 kernel: BUG: unable to handle kernel paging request at fffffffb8a80aaf8
> 08:38:42 kernel: IP: [<ffffffff8106e30c>] osq_lock+0x3c/0x110
>
> Let me know if you'd like me to try to capture more info, but this problem
> seems very reproducible (at least with a mk2 device; I never had the problem on
> older kernels with a mk1). I do direct write()s to the hidraw device, but
> don't otherwise use the driver while it's loaded.
>
> Also at https://bugzilla.kernel.org/show_bug.cgi?id=83751
Do you happen to see a "unsupported firmware " error when plugging your device?
If so, then the following patch should help with the panic (but you will an other one to be able to use again your device).
---
>From 791297375227b91990b37f94fc9de93156a3c21a Mon Sep 17 00:00:00 2001
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date: Tue, 2 Sep 2014 15:50:43 -0400
Subject: [PATCH] HID: thingm: set the proper error code before leaving
In case of an unsupported firmware, the driver bails out without setting
the LEDs interfaces, but forget to set the proper error code.
err is then still equal to 0 and the hid subsytem consider the device
to be in perfect shape.
When removing it, thingm_remove() tries to unbind the rgb LEDs which
has not been created, leading to a segfault.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-thingm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-thingm.c b/drivers/hid/hid-thingm.c
index 134be89..f91f971 100644
--- a/drivers/hid/hid-thingm.c
+++ b/drivers/hid/hid-thingm.c
@@ -250,6 +250,7 @@ static int thingm_probe(struct hid_device *hdev, const struct hid_device_id *id)
if (!tdev->fwinfo) {
hid_err(hdev, "unsupported firmware %c\n", tdev->version.major);
+ err = -ENODEV;
goto stop;
}
--
2.1.0
^ permalink raw reply related
* hid-thingm: kernel panic on remove
From: Dylan Alex Simon @ 2014-09-02 17:46 UTC (permalink / raw)
To: linux-input
Whenever either disconnecting the USB device or simply rmmod'ing the module
(even when not in use), I get a kernel panic. I haven't managed to capture a
backtrace, but at least the first two lines were saved after an rmmod:
18:53:17 kernel: thingm 0003:27B8:01ED.0004: hidraw3: USB HID v1.01 Device [ThingM blink(1) mk2] on usb-0000:00:12.2-3.1.4/input0
<snip, rmmod hid-thingm:>
08:38:42 kernel: BUG: unable to handle kernel paging request at fffffffb8a80aaf8
08:38:42 kernel: IP: [<ffffffff8106e30c>] osq_lock+0x3c/0x110
Let me know if you'd like me to try to capture more info, but this problem
seems very reproducible (at least with a mk2 device; I never had the problem on
older kernels with a mk1). I do direct write()s to the hidraw device, but
don't otherwise use the driver while it's loaded.
Also at https://bugzilla.kernel.org/show_bug.cgi?id=83751
^ 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