* Re: [PATCH] Revert "Input: trackpoint - add new trackpoint firmware ID"
From: Dmitry Torokhov @ 2018-01-02 7:08 UTC (permalink / raw)
To: Aaron Ma; +Cc: Greg KH, Sebastian Schmidt, linux-input
In-Reply-To: <901a0a66-eb83-9dcd-658c-5b09eabcab88@canonical.com>
Hi Aaron,
On Sun, Dec 31, 2017 at 04:51:09PM +0800, Aaron Ma wrote:
> 1, Commit ec667683c53 addes support of the new trackpoint.
> The trackpoint can be identified as "TPPS/2 IBM TrackPoint" and set
> properties OK. Trackpoint enabled some enhanced features.
> Without this commit there will be no scroll mode when xf86-input-evdev
> is used.
>
> 2, trackpoint.c export a speed of sysfs,
> the speed sys file can't be set right value on X1 Carbon 5th. This issue
> is caused by trackpoint firmware.
No, I do not believe that this is an issue with the firmware. Rather, it
seems that Lenovo is multi-sourcing trackpoint for their devices, and
not all of them implement the IBM trackpoint protocol. We will need to
contact Elan to figure out what capabilities their trackpoints have.
> Workaround is to use xinput/xorg/udev/GUI to set trackpoint speed.
I'd rather we did not force users to do that.
>
> 3, Windowds tool Trackpointdetect.exe shows it is ELAN (ID:03) in error log.
> After debugging psmouse driver on it, the IDs and FW/hardware version is
> not ELAN. Forcing to load ELAN driver will not make it work.
We do not have a special driver for Elan trackpoints and if they do not
fully implement IBM trackpoint protocol, then standard PS/2 mode should
be used, at least until someone creates a proper Elan trackpoint driver.
The original "magic ID" for the IBM trcakpoints was 0x1. This value was
described in the original trackpoint spec and has not changed since late
90th. Now we have 0x2 and 0x3. Could they indicate ALPS and Elan
trackpoints respectively? What ID does your Yoga report? Does it support
all features exported by the trackpoint driver (speed, sensitivity,
inertia, etc)?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: misc: Kconfig: fixed a spelling mistake
From: Dmitry Torokhov @ 2018-01-02 6:53 UTC (permalink / raw)
To: Zhuohua Li; +Cc: linux-input, linux-kernel
In-Reply-To: <20171228083050.6475-1-lizhuohua1994@gmail.com>
On Thu, Dec 28, 2017 at 04:30:50PM +0800, Zhuohua Li wrote:
> fixed a spelling mistake: buttong -> button
>
> Signed-off-by: Zhuohua Li <lizhuohua1994@gmail.com>
Applied, thank you.
> ---
> drivers/input/misc/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 9f082a388388..509ba8ef1464 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -468,7 +468,7 @@ config INPUT_TPS65218_PWRBUTTON
> tristate "TPS65218 Power button driver"
> depends on (MFD_TPS65217 || MFD_TPS65218)
> help
> - Say Y here if you want to enable power buttong reporting for
> + Say Y here if you want to enable power button reporting for
> TPS65217 and TPS65218 Power Management IC devices.
>
> To compile this driver as a module, choose M here. The module will
> --
> 2.13.6
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: misc: gpio_tilt: Delete driver
From: Dmitry Torokhov @ 2018-01-02 6:50 UTC (permalink / raw)
To: Heiko Stuebner; +Cc: Linus Walleij, linux-input, linux-arm-kernel
In-Reply-To: <14171345.p7a3jPx4Si@phil>
On Wed, Dec 27, 2017 at 02:51:45PM +0100, Heiko Stuebner wrote:
> Hi Linus,
>
> Am Mittwoch, 27. Dezember 2017, 13:15:47 CET schrieb Linus Walleij:
> > This driver was merged in 2011 as a tool for detecting the orientation
> > of a screen. The device driver assumes board file setup using the
> > platform data from <linux/input/gpio_tilt.h>. But no boards in the
> > kernel tree defines this platform data.
> >
> > As I am faced with refactoring drivers to use GPIO descriptors and
> > pass decriptor tables from boards, or use the device tree device
> > drivers like these creates a serious problem: I cannot fix them and
> > cannot test them, not even compile-test them with a system actually
> > using it (no in-tree boardfile).
> >
> > I suggest to delete this driver and rewrite it using device tree if
> > it is still in use on actively maintained systems.
> >
> > I can also offer to rewrite it out of the blue using device tree if
> > someone promise to test it and help me iterate it.
> >
> > Cc: Heiko Stübner <heiko@sntech.de>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > Heiko: not meaning to be militant here, just contain the situation,
> > as stated: if you like the driver and can test it, I can reimplement
> > it from scratch using device tree.
>
> It seems that piece of hardware (gpio-connected orientation-sensors)
> was really only used in the one s3c24xx-based device I hacked on in 2011.
>
> I somehow lost focus from trying to do the s3c24xx devicetree migration
> when I started hacking on Rockchip stuff, so while I do have the devices
> still around, I don't think I'll find the time and energy trying to get a
> recent kernel to run on them anyway, so I'm fine with dropping the driver.
> It's simple enough to get reintroduced if someone really finds a device
> using it or time to redo the ereader support using devicetree.
>
> So long story short
> Acked-by: Heiko Stuebner <heiko@sntech.de>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v5 1/3] uinput: Use monotonic times for uinput timestamps.
From: Dmitry Torokhov @ 2018-01-02 6:46 UTC (permalink / raw)
To: Deepa Dinamani; +Cc: linux-input, linux-kernel, peter.hutterer, arnd, y2038
In-Reply-To: <20171218051844.10193-2-deepa.kernel@gmail.com>
On Sun, Dec 17, 2017 at 09:18:42PM -0800, Deepa Dinamani wrote:
> struct timeval which is part of struct input_event to
> maintain the event times is not y2038 safe.
>
> Real time timestamps are also not ideal for input_event
> as this time can go backwards as noted in the patch
> a80b83b7b8 by John Stultz.
>
> The patch switches the timestamps to use monotonic time
> from realtime time. This is assuming no one is using
> absolute times from these timestamps.
>
> The structure to maintain input events will be changed
> in a different patch.
>
> Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
> Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Applied, thank you.
> ---
> drivers/input/misc/uinput.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index 91df0df15e68..9251765645d1 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -84,11 +84,14 @@ static int uinput_dev_event(struct input_dev *dev,
> unsigned int type, unsigned int code, int value)
> {
> struct uinput_device *udev = input_get_drvdata(dev);
> + struct timespec64 ts;
>
> udev->buff[udev->head].type = type;
> udev->buff[udev->head].code = code;
> udev->buff[udev->head].value = value;
> - do_gettimeofday(&udev->buff[udev->head].time);
> + ktime_get_ts64(&ts);
> + udev->buff[udev->head].time.tv_sec = ts.tv_sec;
> + udev->buff[udev->head].time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
> udev->head = (udev->head + 1) % UINPUT_BUFFER_SIZE;
>
> wake_up_interruptible(&udev->waitq);
> --
> 2.14.1
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v5 2/3] input: evdev: Replace timeval with timespec64
From: Dmitry Torokhov @ 2018-01-02 6:46 UTC (permalink / raw)
To: Deepa Dinamani; +Cc: linux-input, linux-kernel, peter.hutterer, arnd, y2038
In-Reply-To: <20171218051844.10193-3-deepa.kernel@gmail.com>
Hi Deepa,
On Sun, Dec 17, 2017 at 09:18:43PM -0800, Deepa Dinamani wrote:
> struct timeval is not y2038 safe.
>
> All references to timeval in the kernel will be replaced
> by y2038 safe structures.
> Replace all references to timeval with y2038 safe
> struct timespec64 here.
>
> struct input_event will be changed in a different patch.
>
> Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
> ---
> drivers/input/evdev.c | 37 +++++++++++++++++++++++--------------
> 1 file changed, 23 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index 0193dd4f0452..3171c4882d80 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -156,15 +156,22 @@ static void __evdev_flush_queue(struct evdev_client *client, unsigned int type)
> static void __evdev_queue_syn_dropped(struct evdev_client *client)
> {
> struct input_event ev;
> - ktime_t time;
> + struct timespec64 ts;
>
> - time = client->clk_type == EV_CLK_REAL ?
> - ktime_get_real() :
> - client->clk_type == EV_CLK_MONO ?
> - ktime_get() :
> - ktime_get_boottime();
> + switch (client->clk_type) {
> + case EV_CLK_REAL:
> + ktime_get_real_ts64(&ts);
> + break;
> + case EV_CLK_MONO:
> + ktime_get_ts64(&ts);
> + break;
> + case EV_CLK_BOOT:
> + get_monotonic_boottime64(&ts);
> + break;
> + }
>
> - ev.time = ktime_to_timeval(time);
> + ev.time.tv_sec = ts.tv_sec;
> + ev.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
> ev.type = EV_SYN;
> ev.code = SYN_DROPPED;
> ev.value = 0;
> @@ -257,17 +264,20 @@ static void __pass_event(struct evdev_client *client,
>
> static void evdev_pass_values(struct evdev_client *client,
> const struct input_value *vals, unsigned int count,
> - ktime_t *ev_time)
> + struct timespec64 *ev_time)
> {
> struct evdev *evdev = client->evdev;
> const struct input_value *v;
> struct input_event event;
> + struct timespec64 ts;
> bool wakeup = false;
>
> if (client->revoked)
> return;
>
> - event.time = ktime_to_timeval(ev_time[client->clk_type]);
> + ts = ev_time[client->clk_type];
> + event.time.tv_sec = ts.tv_sec;
> + event.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
>
> /* Interrupts are disabled, just acquire the lock. */
> spin_lock(&client->buffer_lock);
> @@ -304,12 +314,11 @@ static void evdev_events(struct input_handle *handle,
> {
> struct evdev *evdev = handle->private;
> struct evdev_client *client;
> - ktime_t ev_time[EV_CLK_MAX];
> + struct timespec64 ev_time[EV_CLK_MAX];
>
> - ev_time[EV_CLK_MONO] = ktime_get();
> - ev_time[EV_CLK_REAL] = ktime_mono_to_real(ev_time[EV_CLK_MONO]);
> - ev_time[EV_CLK_BOOT] = ktime_mono_to_any(ev_time[EV_CLK_MONO],
> - TK_OFFS_BOOT);
> + ktime_get_ts64(&ev_time[EV_CLK_MONO]);
> + ktime_get_real_ts64(&ev_time[EV_CLK_REAL]);
> + get_monotonic_boottime64(&ev_time[EV_CLK_BOOT]);
This may result in different ev_time[] members holding different times,
whereas the original code would take one time sample and convert it to
different clocks.
Also, why can't we keep using ktime_t internally? It is y2038 safe,
right? I think you should drop this patch and adjust the 3rd one to
massage the input event timestamp patch to do ktime->timespec64->input
timestamp conversion.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: xps 15 9560 touchpad high interrupts
From: Javad Karabi @ 2018-01-01 23:18 UTC (permalink / raw)
To: Baruch Siach; +Cc: linux-input, linux-i2c
In-Reply-To: <20180101061441.mi3fxata4prkt4eu@sapphire.tkos.co.il>
On Mon, Jan 1, 2018 at 12:14 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Javad Karabi,
>
> Added linux-i2c to Cc.
>
> On Sun, Dec 31, 2017 at 03:58:57PM -0600, Javad Karabi wrote:
>> On Sun, Dec 31, 2017 at 12:25 AM, Baruch Siach <baruch@tkos.co.il> wrote:
>> > Added linux-input list to Cc.
>> >
>> > On Sat, Dec 30, 2017 at 05:10:06PM -0600, Javad Karabi wrote:
>> > > im trying to figure out why i get like 7000 interrupts a second simply by
>> > > resting my finger on the touchpad (not even moving it)
>> > > this is on a xps 15 9560
>> > > and the touchpad is at
>> > > DLL07BE:01 06CB:7A13 Touchpad as
>> > > /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/
>> > i2c-DLL07BE:01/0018:06CB:7A13.0009/input/input58
>> > >
>> > > could you provide me with any advice as to where i should look to figure
>> > > this out?
>> > > i have already tried adding code to i2c-designware-platdrv.c
>> > > i added
>> > > dev->clk_freq = 100000;
>> > > in dw_i2c_plat_probe, but it still shoots off thousands of interrupts a
>> > > second (and they are apparently spurious interrupts, atleast accoding
>> > > to /proc/irq/17/spurious
>> > >
>> > > could you provide any guidance at all? would be much appreciated.. i
>> > > would love to fix this issue and get it upstreamed in the kernel if
>> > > possible.
>> > > thank you
>> >
>> > i2c_designware is a I2C bus master driver. It allows the host to
>> > communicate with various devices. Your touchpad is apparently one such
>> > device. But each device on the I2C bus needs its own driver. I have no
>> > idea which driver handles your touchpad device. Maybe someone on the
>> > linux-input list knows.
>> >
>> > Specifically, the interrupts handling has nothing to do with the I2C bus.
>> > Unlike PCIe, I2C provides no in-bus interrupt delivery facility. I2C
>> > devices usually use a separate dedicated interrupt line. So the spurious
>> > interrupts that you see must be handled at the touchpad input driver
>> > level.
>> >
>> > One thing that might help others help you is the version of the kernel you
>> > are running. Please provide the output of 'uname -rv' on your machine.
>>
>> uname -rv
>> 4.15.0-rc5 #2 SMP Thu Dec 28 18:21:06 CST 2017
>>
>> for what its worth, i think it might be hid_multitouch that is handling the
>> touchpad, since when i rmmod it, my touchpad is no longer active.
>
> The hid-multitouch driver handles USB devices, not I2C. The code at
> drivers/hid/hid-multitouch.c shows a few supported USB_VENDOR_ID_SYNAPTICS
> (0x06cb) devices, but the 0x7a13 device ID does not appear there as of
> v4.15-rc6. Maybe your kernel is patched to add support for that device.
>
> I guess that i2c_designware appears on the device hierarchy because the
> "smart" USB hub on your system is controlled over the I2C bus.
>
>> when you say that the touchpad driver handles the irq stuff... i am a
>> little confused because i2c-designware-platdrv.c contains this line:
>> irq = platform_get_irq(pdev, 0);
>
> Do you have an indication that irq 17 belongs to i2c-designware?
>
> The i2c-designware driver uses an interrupt to handle its hardware buffer, and
> to receive transactions status. I2C is a slow protocol, so most controller
> implementations are asynchronous. If this irq misbehaves, then there is most
> likely a problem with the i2c-designware driver.
>
>> i would assume that hid_multitouch would contain irq related code if i am
>> understanding you correctly?
>> am i misunderstanding?
>
> Since hid-multitouch is a USB driver, the irq handle itself is in the USB bus
> driver.
>
> baruch
>
> --
> http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
uname -rv:
4.15.0-rc5-00248-gf39d7d78b70e #2 SMP Sun Dec 31 18:17:25 CST 2017
the git commit i am at is f39d7d78b70e0f39facb1e4fab77ad3df5c52a35
> Do you have an indication that irq 17 belongs to i2c-designware?
from /proc/interrupts:
17: 47105193 0 0 0 0
0 0 0 IR-IO-APIC 17-fasteoi idma64.1,
i2c_designware.1
if i rmmod idma64, the behavior remains the same, so im assuming this
is all i2c_designware thats causing this problem.
> then there is most likely a problem with the i2c-designware driver.
do you have any idea what the problem might be? i know i should look
in the code for i2c-designware, but why would a touchpad be shooting
off interrupts like that with my finger simply resting on it?
i have a theory, could you tell me if this makes sense?
perhaps the touchpad hardware is configured with a very high
sensitivity. so in theory if the sensitivity was decreased, then
resting my finger would not trigger interrupts until i move it a
larger amount?
^ permalink raw reply
* Re: xps 15 9560 touchpad high interrupts
From: Baruch Siach @ 2018-01-01 6:14 UTC (permalink / raw)
To: Javad Karabi; +Cc: linux-input, linux-i2c
In-Reply-To: <CAEOHGOks90Am19G4-YALXq6vL8GOM9V0Mmf65-rUNYOvf5Rhyw@mail.gmail.com>
Hi Javad Karabi,
Added linux-i2c to Cc.
On Sun, Dec 31, 2017 at 03:58:57PM -0600, Javad Karabi wrote:
> On Sun, Dec 31, 2017 at 12:25 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > Added linux-input list to Cc.
> >
> > On Sat, Dec 30, 2017 at 05:10:06PM -0600, Javad Karabi wrote:
> > > im trying to figure out why i get like 7000 interrupts a second simply by
> > > resting my finger on the touchpad (not even moving it)
> > > this is on a xps 15 9560
> > > and the touchpad is at
> > > DLL07BE:01 06CB:7A13 Touchpad as
> > > /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/
> > i2c-DLL07BE:01/0018:06CB:7A13.0009/input/input58
> > >
> > > could you provide me with any advice as to where i should look to figure
> > > this out?
> > > i have already tried adding code to i2c-designware-platdrv.c
> > > i added
> > > dev->clk_freq = 100000;
> > > in dw_i2c_plat_probe, but it still shoots off thousands of interrupts a
> > > second (and they are apparently spurious interrupts, atleast accoding
> > > to /proc/irq/17/spurious
> > >
> > > could you provide any guidance at all? would be much appreciated.. i
> > > would love to fix this issue and get it upstreamed in the kernel if
> > > possible.
> > > thank you
> >
> > i2c_designware is a I2C bus master driver. It allows the host to
> > communicate with various devices. Your touchpad is apparently one such
> > device. But each device on the I2C bus needs its own driver. I have no
> > idea which driver handles your touchpad device. Maybe someone on the
> > linux-input list knows.
> >
> > Specifically, the interrupts handling has nothing to do with the I2C bus.
> > Unlike PCIe, I2C provides no in-bus interrupt delivery facility. I2C
> > devices usually use a separate dedicated interrupt line. So the spurious
> > interrupts that you see must be handled at the touchpad input driver
> > level.
> >
> > One thing that might help others help you is the version of the kernel you
> > are running. Please provide the output of 'uname -rv' on your machine.
>
> uname -rv
> 4.15.0-rc5 #2 SMP Thu Dec 28 18:21:06 CST 2017
>
> for what its worth, i think it might be hid_multitouch that is handling the
> touchpad, since when i rmmod it, my touchpad is no longer active.
The hid-multitouch driver handles USB devices, not I2C. The code at
drivers/hid/hid-multitouch.c shows a few supported USB_VENDOR_ID_SYNAPTICS
(0x06cb) devices, but the 0x7a13 device ID does not appear there as of
v4.15-rc6. Maybe your kernel is patched to add support for that device.
I guess that i2c_designware appears on the device hierarchy because the
"smart" USB hub on your system is controlled over the I2C bus.
> when you say that the touchpad driver handles the irq stuff... i am a
> little confused because i2c-designware-platdrv.c contains this line:
> irq = platform_get_irq(pdev, 0);
Do you have an indication that irq 17 belongs to i2c-designware?
The i2c-designware driver uses an interrupt to handle its hardware buffer, and
to receive transactions status. I2C is a slow protocol, so most controller
implementations are asynchronous. If this irq misbehaves, then there is most
likely a problem with the i2c-designware driver.
> i would assume that hid_multitouch would contain irq related code if i am
> understanding you correctly?
> am i misunderstanding?
Since hid-multitouch is a USB driver, the irq handle itself is in the USB bus
driver.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH v2] input: pxrc: new driver for PhoenixRC Flight Controller Adapter
From: Marcus Folkesson @ 2017-12-31 20:48 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Marcus Folkesson,
Tomohiro Yoshidomi, David Herrmann, Philippe Ombredanne,
Kate Stewart, Greg Kroah-Hartman
Cc: linux-input, linux-doc, linux-kernel
This driver let you plug in your RC controller to the adapter and
use it as input device in various RC simulators.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
---
v2:
- Change module license to GPLv2 to match SPDX tag
Documentation/input/devices/pxrc.rst | 57 ++++++++
drivers/input/joystick/Kconfig | 9 ++
drivers/input/joystick/Makefile | 1 +
drivers/input/joystick/pxrc.c | 254 +++++++++++++++++++++++++++++++++++
4 files changed, 321 insertions(+)
create mode 100644 Documentation/input/devices/pxrc.rst
create mode 100644 drivers/input/joystick/pxrc.c
diff --git a/Documentation/input/devices/pxrc.rst b/Documentation/input/devices/pxrc.rst
new file mode 100644
index 000000000000..0ec466c58958
--- /dev/null
+++ b/Documentation/input/devices/pxrc.rst
@@ -0,0 +1,57 @@
+=======================================================
+pxrc - PhoenixRC Flight Controller Adapter
+=======================================================
+
+:Author: Marcus Folkesson <marcus.folkesson@gmail.com>
+
+This driver let you use your own RC controller plugged into the
+adapter that comes with PhoenixRC [1]_ or other compatible adapters.
+
+The adapter supports 7 analog channels and 1 digital input switch.
+
+Notes
+=====
+
+Many RC controllers is able to configure which stick goes to which channel.
+This is also configurable in most simulators, so a matching is not necessary.
+
+The driver is generating the following input event for analog channels:
+
++---------+----------------+
+| Channel | Event |
++=========+================+
+| 1 | ABS_X |
++---------+----------------+
+| 2 | ABS_Y |
++---------+----------------+
+| 3 | ABS_RX |
++---------+----------------+
+| 4 | ABS_RY |
++---------+----------------+
+| 5 | ABS_TILT_X |
++---------+----------------+
+| 6 | ABS_TILT_Y |
++---------+----------------+
+| 7 | ABS_THROTTLE |
++---------+----------------+
+
+The digital input switch is generated as an `BTN_A` event.
+
+Manual Testing
+==============
+
+To test this driver's functionality you may use `input-event` which is part of
+the `input layer utilities` suite [2]_.
+
+For example::
+
+ > modprobe pxrc
+ > input-events <devnr>
+
+To print all input events from input `devnr`.
+
+References
+==========
+
+.. [1] http://www.phoenix-sim.com/
+.. [2] https://www.kraxel.org/cgit/input/
diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index f3c2f6ea8b44..18ab6dafff41 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -351,4 +351,13 @@ config JOYSTICK_PSXPAD_SPI_FF
To drive rumble motor a dedicated power supply is required.
+config JOYSTICK_PXRC
+ tristate "PhoenixRC Flight Controller Adapter"
+ depends on USB_ARCH_HAS_HCD
+ select USB
+ help
+ Say Y here if you want to use the PhoenixRC Flight Controller Adapter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called pxrc.
endif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 67651efda2e1..dd0492ebbed7 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_JOYSTICK_JOYDUMP) += joydump.o
obj-$(CONFIG_JOYSTICK_MAGELLAN) += magellan.o
obj-$(CONFIG_JOYSTICK_MAPLE) += maplecontrol.o
obj-$(CONFIG_JOYSTICK_PSXPAD_SPI) += psxpad-spi.o
+obj-$(CONFIG_JOYSTICK_PXRC) += pxrc.o
obj-$(CONFIG_JOYSTICK_SIDEWINDER) += sidewinder.o
obj-$(CONFIG_JOYSTICK_SPACEBALL) += spaceball.o
obj-$(CONFIG_JOYSTICK_SPACEORB) += spaceorb.o
diff --git a/drivers/input/joystick/pxrc.c b/drivers/input/joystick/pxrc.c
new file mode 100644
index 000000000000..2bec99df97e2
--- /dev/null
+++ b/drivers/input/joystick/pxrc.c
@@ -0,0 +1,254 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for Phoenix RC Flight Controller Adapter
+ *
+ * Copyright (C) 2018 Marcus Folkesson <marcus.folkesson@gmail.com>
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/kref.h>
+#include <linux/uaccess.h>
+#include <linux/usb.h>
+#include <linux/mutex.h>
+#include <linux/input.h>
+
+#define PXRC_VENDOR_ID (0x1781)
+#define PXRC_PRODUCT_ID (0x0898)
+
+static const struct usb_device_id pxrc_table[] = {
+ { USB_DEVICE(PXRC_VENDOR_ID, PXRC_PRODUCT_ID) },
+ { }
+};
+MODULE_DEVICE_TABLE(usb, pxrc_table);
+
+struct usb_pxrc {
+ struct input_dev *input_dev;
+ struct usb_device *udev;
+ struct usb_interface *interface;
+ struct usb_anchor anchor;
+ __u8 epaddr;
+ char phys[64];
+ unsigned char *data;
+ size_t bsize;
+ struct kref kref;
+};
+
+#define to_pxrc_dev(d) container_of(d, struct usb_pxrc, kref)
+static void pxrc_delete(struct kref *kref)
+{
+ struct usb_pxrc *pxrc = to_pxrc_dev(kref);
+
+ usb_put_dev(pxrc->udev);
+}
+
+static void pxrc_usb_irq(struct urb *urb)
+{
+ struct usb_pxrc *pxrc = urb->context;
+
+ switch (urb->status) {
+ case 0:
+ /* success */
+ break;
+ case -ETIME:
+ /* this urb is timing out */
+ dev_dbg(&pxrc->interface->dev,
+ "%s - urb timed out - was the device unplugged?\n",
+ __func__);
+ return;
+ case -ECONNRESET:
+ case -ENOENT:
+ case -ESHUTDOWN:
+ case -EPIPE:
+ /* this urb is terminated, clean up */
+ dev_dbg(&pxrc->interface->dev, "%s - urb shutting down with status: %d\n",
+ __func__, urb->status);
+ return;
+ default:
+ dev_dbg(&pxrc->interface->dev, "%s - nonzero urb status received: %d\n",
+ __func__, urb->status);
+ goto exit;
+ }
+
+ if (urb->actual_length == 8) {
+ input_report_abs(pxrc->input_dev, ABS_X, pxrc->data[0]);
+ input_report_abs(pxrc->input_dev, ABS_Y, pxrc->data[2]);
+ input_report_abs(pxrc->input_dev, ABS_RX, pxrc->data[3]);
+ input_report_abs(pxrc->input_dev, ABS_RY, pxrc->data[4]);
+ input_report_abs(pxrc->input_dev, ABS_TILT_X, pxrc->data[5]);
+ input_report_abs(pxrc->input_dev, ABS_TILT_Y, pxrc->data[6]);
+ input_report_abs(pxrc->input_dev, ABS_THROTTLE, pxrc->data[7]);
+
+ input_report_key(pxrc->input_dev, BTN_A, pxrc->data[1]);
+ }
+
+exit:
+ /* Resubmit to fetch new fresh URBs */
+ usb_anchor_urb(urb, &pxrc->anchor);
+ if (usb_submit_urb(urb, GFP_ATOMIC) < 0)
+ usb_unanchor_urb(urb);
+}
+
+static int pxrc_submit_intr_urb(struct usb_pxrc *pxrc)
+{
+ struct urb *urb;
+ unsigned int pipe;
+ int err;
+
+ urb = usb_alloc_urb(0, GFP_KERNEL);
+ if (!urb)
+ return -ENOMEM;
+
+ pipe = usb_rcvintpipe(pxrc->udev, pxrc->epaddr),
+ usb_fill_int_urb(urb, pxrc->udev, pipe, pxrc->data, pxrc->bsize,
+ pxrc_usb_irq, pxrc, 1);
+ usb_anchor_urb(urb, &pxrc->anchor);
+ err = usb_submit_urb(urb, GFP_KERNEL);
+ if (err < 0)
+ usb_unanchor_urb(urb);
+
+ usb_free_urb(urb);
+ return err;
+}
+
+static int pxrc_open(struct input_dev *input)
+{
+ struct usb_pxrc *pxrc = input_get_drvdata(input);
+ int err;
+
+ err = pxrc_submit_intr_urb(pxrc);
+ if (err < 0)
+ goto error;
+
+ kref_get(&pxrc->kref);
+ return 0;
+
+error:
+ usb_kill_anchored_urbs(&pxrc->anchor);
+ return err;
+}
+
+static void pxrc_close(struct input_dev *input)
+{
+ struct usb_pxrc *pxrc = input_get_drvdata(input);
+
+ usb_kill_anchored_urbs(&pxrc->anchor);
+ kref_put(&pxrc->kref, pxrc_delete);
+}
+
+static int pxrc_input_init(struct usb_pxrc *pxrc)
+{
+ pxrc->input_dev = devm_input_allocate_device(&pxrc->interface->dev);
+ if (pxrc->input_dev == NULL) {
+ dev_err(&pxrc->interface->dev, "couldn't allocate input device\n");
+ return -ENOMEM;
+ }
+
+ pxrc->input_dev->name = "PXRC Flight Controller Adapter";
+ pxrc->input_dev->phys = pxrc->phys;
+ pxrc->input_dev->id.bustype = BUS_USB;
+ pxrc->input_dev->id.vendor = PXRC_VENDOR_ID;
+ pxrc->input_dev->id.product = PXRC_PRODUCT_ID;
+ pxrc->input_dev->id.version = 0x01;
+
+ pxrc->input_dev->open = pxrc_open;
+ pxrc->input_dev->close = pxrc_close;
+
+ pxrc->input_dev->evbit[0] = BIT_MASK(EV_ABS) | BIT_MASK(EV_KEY);
+ pxrc->input_dev->absbit[0] = BIT_MASK(ABS_X) |
+ BIT_MASK(ABS_Y) |
+ BIT_MASK(ABS_RY) |
+ BIT_MASK(ABS_RX) |
+ BIT_MASK(ABS_THROTTLE) |
+ BIT_MASK(ABS_TILT_X) |
+ BIT_MASK(ABS_TILT_Y);
+
+ pxrc->input_dev->keybit[BIT_WORD(BTN_JOYSTICK)] = BIT_MASK(BTN_A);
+
+ input_set_abs_params(pxrc->input_dev, ABS_X, 0, 255, 0, 0);
+ input_set_abs_params(pxrc->input_dev, ABS_Y, 0, 255, 0, 0);
+ input_set_abs_params(pxrc->input_dev, ABS_RX, 0, 255, 0, 0);
+ input_set_abs_params(pxrc->input_dev, ABS_RY, 0, 255, 0, 0);
+ input_set_abs_params(pxrc->input_dev, ABS_TILT_X, 0, 255, 0, 0);
+ input_set_abs_params(pxrc->input_dev, ABS_TILT_Y, 0, 255, 0, 0);
+ input_set_abs_params(pxrc->input_dev, ABS_THROTTLE, 0, 255, 0, 0);
+
+ input_set_drvdata(pxrc->input_dev, pxrc);
+
+ return input_register_device(pxrc->input_dev);
+}
+
+static int pxrc_probe(struct usb_interface *interface,
+ const struct usb_device_id *id)
+{
+ struct usb_pxrc *pxrc;
+ struct usb_endpoint_descriptor *epirq;
+ int retval;
+
+ pxrc = devm_kzalloc(&interface->dev, sizeof(*pxrc), GFP_KERNEL);
+
+ if (!pxrc)
+ return -ENOMEM;
+
+ kref_init(&pxrc->kref);
+ init_usb_anchor(&pxrc->anchor);
+
+ pxrc->udev = usb_get_dev(interface_to_usbdev(interface));
+ pxrc->interface = interface;
+
+ /* Set up the endpoint information */
+ /* This device only has an interrupt endpoint */
+ retval = usb_find_common_endpoints(interface->cur_altsetting,
+ NULL, NULL, &epirq, NULL);
+ if (retval) {
+ dev_err(&interface->dev,
+ "Could not find endpoint\n");
+ goto error;
+ }
+
+ pxrc->bsize = usb_endpoint_maxp(epirq);
+ pxrc->epaddr = epirq->bEndpointAddress;
+ pxrc->data = devm_kmalloc(&interface->dev, pxrc->bsize, GFP_KERNEL);
+ if (!pxrc->data) {
+ retval = -ENOMEM;
+ goto error;
+ }
+
+ usb_set_intfdata(interface, pxrc);
+ usb_make_path(pxrc->udev, pxrc->phys, sizeof(pxrc->phys));
+
+ retval = pxrc_input_init(pxrc);
+ if (retval)
+ goto error;
+
+ return 0;
+
+error:
+ /* this frees allocated memory */
+ kref_put(&pxrc->kref, pxrc_delete);
+
+ return retval;
+}
+
+static void pxrc_disconnect(struct usb_interface *interface)
+{
+ struct usb_pxrc *pxrc = usb_get_intfdata(interface);
+
+ kref_put(&pxrc->kref, pxrc_delete);
+}
+
+static struct usb_driver pxrc_driver = {
+ .name = "pxrc",
+ .probe = pxrc_probe,
+ .disconnect = pxrc_disconnect,
+ .id_table = pxrc_table,
+};
+
+module_usb_driver(pxrc_driver);
+
+MODULE_AUTHOR("Marcus Folkesson <marcus.folkesson@gmail.com>");
+MODULE_DESCRIPTION("PhoenixRC Flight Controller Adapter");
+MODULE_LICENSE("GPL v2");
--
2.15.1
^ permalink raw reply related
* Re: [PATCH] input: pxrc: new driver for PhoenixRC Flight Controller Adapter
From: Philippe Ombredanne @ 2017-12-31 20:26 UTC (permalink / raw)
To: Marcus Folkesson
Cc: Dmitry Torokhov, Jonathan Corbet, Tomohiro Yoshidomi,
David Herrmann, Kate Stewart, Greg Kroah-Hartman, linux-input,
linux-doc, LKML
In-Reply-To: <20171231200925.26424-1-marcus.folkesson@gmail.com>
Markus,
On Sun, Dec 31, 2017 at 9:09 PM, Marcus Folkesson
<marcus.folkesson@gmail.com> wrote:
> This driver let you plug in your RC controller to the adapter and
> use it as input device in various RC simulators.
>
> Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
<snip>
> --- /dev/null
> +++ b/drivers/input/joystick/pxrc.c
> @@ -0,0 +1,254 @@
> +// SPDX-License-Identifier: GPL-2.0
<snip>
> +MODULE_LICENSE("GPL");
This MODULE_LICENSE means GPL 2.0 or later per module.h and this does
not match your top level SPDX tag which means GPL 2.0 only.
Could you make sure they are in sync?
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH] input: pxrc: new driver for PhoenixRC Flight Controller Adapter
From: Marcus Folkesson @ 2017-12-31 20:09 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Corbet, Marcus Folkesson,
Tomohiro Yoshidomi, David Herrmann, Philippe Ombredanne,
Kate Stewart, Greg Kroah-Hartman
Cc: linux-input, linux-doc, linux-kernel
This driver let you plug in your RC controller to the adapter and
use it as input device in various RC simulators.
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
---
Happy New Year!
Documentation/input/devices/pxrc.rst | 57 ++++++++
drivers/input/joystick/Kconfig | 9 ++
drivers/input/joystick/Makefile | 1 +
drivers/input/joystick/pxrc.c | 254 +++++++++++++++++++++++++++++++++++
4 files changed, 321 insertions(+)
create mode 100644 Documentation/input/devices/pxrc.rst
create mode 100644 drivers/input/joystick/pxrc.c
diff --git a/Documentation/input/devices/pxrc.rst b/Documentation/input/devices/pxrc.rst
new file mode 100644
index 000000000000..0ec466c58958
--- /dev/null
+++ b/Documentation/input/devices/pxrc.rst
@@ -0,0 +1,57 @@
+=======================================================
+pxrc - PhoenixRC Flight Controller Adapter
+=======================================================
+
+:Author: Marcus Folkesson <marcus.folkesson@gmail.com>
+
+This driver let you use your own RC controller plugged into the
+adapter that comes with PhoenixRC [1]_ or other compatible adapters.
+
+The adapter supports 7 analog channels and 1 digital input switch.
+
+Notes
+=====
+
+Many RC controllers is able to configure which stick goes to which channel.
+This is also configurable in most simulators, so a matching is not necessary.
+
+The driver is generating the following input event for analog channels:
+
++---------+----------------+
+| Channel | Event |
++=========+================+
+| 1 | ABS_X |
++---------+----------------+
+| 2 | ABS_Y |
++---------+----------------+
+| 3 | ABS_RX |
++---------+----------------+
+| 4 | ABS_RY |
++---------+----------------+
+| 5 | ABS_TILT_X |
++---------+----------------+
+| 6 | ABS_TILT_Y |
++---------+----------------+
+| 7 | ABS_THROTTLE |
++---------+----------------+
+
+The digital input switch is generated as an `BTN_A` event.
+
+Manual Testing
+==============
+
+To test this driver's functionality you may use `input-event` which is part of
+the `input layer utilities` suite [2]_.
+
+For example::
+
+ > modprobe pxrc
+ > input-events <devnr>
+
+To print all input events from input `devnr`.
+
+References
+==========
+
+.. [1] http://www.phoenix-sim.com/
+.. [2] https://www.kraxel.org/cgit/input/
diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index f3c2f6ea8b44..18ab6dafff41 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -351,4 +351,13 @@ config JOYSTICK_PSXPAD_SPI_FF
To drive rumble motor a dedicated power supply is required.
+config JOYSTICK_PXRC
+ tristate "PhoenixRC Flight Controller Adapter"
+ depends on USB_ARCH_HAS_HCD
+ select USB
+ help
+ Say Y here if you want to use the PhoenixRC Flight Controller Adapter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called pxrc.
endif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 67651efda2e1..dd0492ebbed7 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_JOYSTICK_JOYDUMP) += joydump.o
obj-$(CONFIG_JOYSTICK_MAGELLAN) += magellan.o
obj-$(CONFIG_JOYSTICK_MAPLE) += maplecontrol.o
obj-$(CONFIG_JOYSTICK_PSXPAD_SPI) += psxpad-spi.o
+obj-$(CONFIG_JOYSTICK_PXRC) += pxrc.o
obj-$(CONFIG_JOYSTICK_SIDEWINDER) += sidewinder.o
obj-$(CONFIG_JOYSTICK_SPACEBALL) += spaceball.o
obj-$(CONFIG_JOYSTICK_SPACEORB) += spaceorb.o
diff --git a/drivers/input/joystick/pxrc.c b/drivers/input/joystick/pxrc.c
new file mode 100644
index 000000000000..87a9c09124b4
--- /dev/null
+++ b/drivers/input/joystick/pxrc.c
@@ -0,0 +1,254 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for Phoenix RC Flight Controller Adapter
+ *
+ * Copyright (C) 2018 Marcus Folkesson <marcus.folkesson@gmail.com>
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/kref.h>
+#include <linux/uaccess.h>
+#include <linux/usb.h>
+#include <linux/mutex.h>
+#include <linux/input.h>
+
+#define PXRC_VENDOR_ID (0x1781)
+#define PXRC_PRODUCT_ID (0x0898)
+
+static const struct usb_device_id pxrc_table[] = {
+ { USB_DEVICE(PXRC_VENDOR_ID, PXRC_PRODUCT_ID) },
+ { }
+};
+MODULE_DEVICE_TABLE(usb, pxrc_table);
+
+struct usb_pxrc {
+ struct input_dev *input_dev;
+ struct usb_device *udev;
+ struct usb_interface *interface;
+ struct usb_anchor anchor;
+ __u8 epaddr;
+ char phys[64];
+ unsigned char *data;
+ size_t bsize;
+ struct kref kref;
+};
+
+#define to_pxrc_dev(d) container_of(d, struct usb_pxrc, kref)
+static void pxrc_delete(struct kref *kref)
+{
+ struct usb_pxrc *pxrc = to_pxrc_dev(kref);
+
+ usb_put_dev(pxrc->udev);
+}
+
+static void pxrc_usb_irq(struct urb *urb)
+{
+ struct usb_pxrc *pxrc = urb->context;
+
+ switch (urb->status) {
+ case 0:
+ /* success */
+ break;
+ case -ETIME:
+ /* this urb is timing out */
+ dev_dbg(&pxrc->interface->dev,
+ "%s - urb timed out - was the device unplugged?\n",
+ __func__);
+ return;
+ case -ECONNRESET:
+ case -ENOENT:
+ case -ESHUTDOWN:
+ case -EPIPE:
+ /* this urb is terminated, clean up */
+ dev_dbg(&pxrc->interface->dev, "%s - urb shutting down with status: %d\n",
+ __func__, urb->status);
+ return;
+ default:
+ dev_dbg(&pxrc->interface->dev, "%s - nonzero urb status received: %d\n",
+ __func__, urb->status);
+ goto exit;
+ }
+
+ if (urb->actual_length == 8) {
+ input_report_abs(pxrc->input_dev, ABS_X, pxrc->data[0]);
+ input_report_abs(pxrc->input_dev, ABS_Y, pxrc->data[2]);
+ input_report_abs(pxrc->input_dev, ABS_RX, pxrc->data[3]);
+ input_report_abs(pxrc->input_dev, ABS_RY, pxrc->data[4]);
+ input_report_abs(pxrc->input_dev, ABS_TILT_X, pxrc->data[5]);
+ input_report_abs(pxrc->input_dev, ABS_TILT_Y, pxrc->data[6]);
+ input_report_abs(pxrc->input_dev, ABS_THROTTLE, pxrc->data[7]);
+
+ input_report_key(pxrc->input_dev, BTN_A, pxrc->data[1]);
+ }
+
+exit:
+ /* Resubmit to fetch new fresh URBs */
+ usb_anchor_urb(urb, &pxrc->anchor);
+ if (usb_submit_urb(urb, GFP_ATOMIC) < 0)
+ usb_unanchor_urb(urb);
+}
+
+static int pxrc_submit_intr_urb(struct usb_pxrc *pxrc)
+{
+ struct urb *urb;
+ unsigned int pipe;
+ int err;
+
+ urb = usb_alloc_urb(0, GFP_KERNEL);
+ if (!urb)
+ return -ENOMEM;
+
+ pipe = usb_rcvintpipe(pxrc->udev, pxrc->epaddr),
+ usb_fill_int_urb(urb, pxrc->udev, pipe, pxrc->data, pxrc->bsize,
+ pxrc_usb_irq, pxrc, 1);
+ usb_anchor_urb(urb, &pxrc->anchor);
+ err = usb_submit_urb(urb, GFP_KERNEL);
+ if (err < 0)
+ usb_unanchor_urb(urb);
+
+ usb_free_urb(urb);
+ return err;
+}
+
+static int pxrc_open(struct input_dev *input)
+{
+ struct usb_pxrc *pxrc = input_get_drvdata(input);
+ int err;
+
+ err = pxrc_submit_intr_urb(pxrc);
+ if (err < 0)
+ goto error;
+
+ kref_get(&pxrc->kref);
+ return 0;
+
+error:
+ usb_kill_anchored_urbs(&pxrc->anchor);
+ return err;
+}
+
+static void pxrc_close(struct input_dev *input)
+{
+ struct usb_pxrc *pxrc = input_get_drvdata(input);
+
+ usb_kill_anchored_urbs(&pxrc->anchor);
+ kref_put(&pxrc->kref, pxrc_delete);
+}
+
+static int pxrc_input_init(struct usb_pxrc *pxrc)
+{
+ pxrc->input_dev = devm_input_allocate_device(&pxrc->interface->dev);
+ if (pxrc->input_dev == NULL) {
+ dev_err(&pxrc->interface->dev, "couldn't allocate input device\n");
+ return -ENOMEM;
+ }
+
+ pxrc->input_dev->name = "PXRC Flight Controller Adapter";
+ pxrc->input_dev->phys = pxrc->phys;
+ pxrc->input_dev->id.bustype = BUS_USB;
+ pxrc->input_dev->id.vendor = PXRC_VENDOR_ID;
+ pxrc->input_dev->id.product = PXRC_PRODUCT_ID;
+ pxrc->input_dev->id.version = 0x01;
+
+ pxrc->input_dev->open = pxrc_open;
+ pxrc->input_dev->close = pxrc_close;
+
+ pxrc->input_dev->evbit[0] = BIT_MASK(EV_ABS) | BIT_MASK(EV_KEY);
+ pxrc->input_dev->absbit[0] = BIT_MASK(ABS_X) |
+ BIT_MASK(ABS_Y) |
+ BIT_MASK(ABS_RY) |
+ BIT_MASK(ABS_RX) |
+ BIT_MASK(ABS_THROTTLE) |
+ BIT_MASK(ABS_TILT_X) |
+ BIT_MASK(ABS_TILT_Y);
+
+ pxrc->input_dev->keybit[BIT_WORD(BTN_JOYSTICK)] = BIT_MASK(BTN_A);
+
+ input_set_abs_params(pxrc->input_dev, ABS_X, 0, 255, 0, 0);
+ input_set_abs_params(pxrc->input_dev, ABS_Y, 0, 255, 0, 0);
+ input_set_abs_params(pxrc->input_dev, ABS_RX, 0, 255, 0, 0);
+ input_set_abs_params(pxrc->input_dev, ABS_RY, 0, 255, 0, 0);
+ input_set_abs_params(pxrc->input_dev, ABS_TILT_X, 0, 255, 0, 0);
+ input_set_abs_params(pxrc->input_dev, ABS_TILT_Y, 0, 255, 0, 0);
+ input_set_abs_params(pxrc->input_dev, ABS_THROTTLE, 0, 255, 0, 0);
+
+ input_set_drvdata(pxrc->input_dev, pxrc);
+
+ return input_register_device(pxrc->input_dev);
+}
+
+static int pxrc_probe(struct usb_interface *interface,
+ const struct usb_device_id *id)
+{
+ struct usb_pxrc *pxrc;
+ struct usb_endpoint_descriptor *epirq;
+ int retval;
+
+ pxrc = devm_kzalloc(&interface->dev, sizeof(*pxrc), GFP_KERNEL);
+
+ if (!pxrc)
+ return -ENOMEM;
+
+ kref_init(&pxrc->kref);
+ init_usb_anchor(&pxrc->anchor);
+
+ pxrc->udev = usb_get_dev(interface_to_usbdev(interface));
+ pxrc->interface = interface;
+
+ /* Set up the endpoint information */
+ /* This device only has an interrupt endpoint */
+ retval = usb_find_common_endpoints(interface->cur_altsetting,
+ NULL, NULL, &epirq, NULL);
+ if (retval) {
+ dev_err(&interface->dev,
+ "Could not find endpoint\n");
+ goto error;
+ }
+
+ pxrc->bsize = usb_endpoint_maxp(epirq);
+ pxrc->epaddr = epirq->bEndpointAddress;
+ pxrc->data = devm_kmalloc(&interface->dev, pxrc->bsize, GFP_KERNEL);
+ if (!pxrc->data) {
+ retval = -ENOMEM;
+ goto error;
+ }
+
+ usb_set_intfdata(interface, pxrc);
+ usb_make_path(pxrc->udev, pxrc->phys, sizeof(pxrc->phys));
+
+ retval = pxrc_input_init(pxrc);
+ if (retval)
+ goto error;
+
+ return 0;
+
+error:
+ /* this frees allocated memory */
+ kref_put(&pxrc->kref, pxrc_delete);
+
+ return retval;
+}
+
+static void pxrc_disconnect(struct usb_interface *interface)
+{
+ struct usb_pxrc *pxrc = usb_get_intfdata(interface);
+
+ kref_put(&pxrc->kref, pxrc_delete);
+}
+
+static struct usb_driver pxrc_driver = {
+ .name = "pxrc",
+ .probe = pxrc_probe,
+ .disconnect = pxrc_disconnect,
+ .id_table = pxrc_table,
+};
+
+module_usb_driver(pxrc_driver);
+
+MODULE_AUTHOR("Marcus Folkesson <marcus.folkesson@gmail.com>");
+MODULE_DESCRIPTION("PhoenixRC Flight Controller Adapter");
+MODULE_LICENSE("GPL");
--
2.15.1
^ permalink raw reply related
* Spende von € 3.400.000,00 EUR
From: foundation @ 2017-12-31 17:20 UTC (permalink / raw)
To: Recipients
Hallo, ich Roy Cockrum, 58, aus Knoxville, Tennessee Vereinigte Staaten von Amerika, du hast eine Wohltätigkeitsspende von € 3.400.000,00 EUR, ich gewann die America Lotterie in Amerika im Wert von $ 259,9 Millionen, und ich gebe einen Teil davon Zu fünf glücklichen Leuten und Wohltätigkeitshäusern in Gelübde, um die Armut vor dieser Welt zu beseitigen, ich kämpfe gegen die Armut. Kontaktieren Sie mich für weitere Details: roycockrumpovertyfoundation@gmail.com
^ permalink raw reply
* Re: [PATCH] Revert "Input: trackpoint - add new trackpoint firmware ID"
From: Aaron Ma @ 2017-12-31 8:51 UTC (permalink / raw)
To: Greg KH; +Cc: Sebastian Schmidt, linux-input, dmitry.torokhov
In-Reply-To: <20171231082646.GC25965@kroah.com>
1, Commit ec667683c53 addes support of the new trackpoint.
The trackpoint can be identified as "TPPS/2 IBM TrackPoint" and set
properties OK. Trackpoint enabled some enhanced features.
Without this commit there will be no scroll mode when xf86-input-evdev
is used.
2, trackpoint.c export a speed of sysfs,
the speed sys file can't be set right value on X1 Carbon 5th. This issue
is caused by trackpoint firmware.
Workaround is to use xinput/xorg/udev/GUI to set trackpoint speed.
3, Windowds tool Trackpointdetect.exe shows it is ELAN (ID:03) in error log.
After debugging psmouse driver on it, the IDs and FW/hardware version is
not ELAN. Forcing to load ELAN driver will not make it work.
^ permalink raw reply
* Re: [PATCH] Revert "Input: trackpoint - add new trackpoint firmware ID"
From: Greg KH @ 2017-12-31 8:26 UTC (permalink / raw)
To: Aaron Ma; +Cc: Sebastian Schmidt, linux-input, dmitry.torokhov
In-Reply-To: <dcfb84c8-4ad8-8276-5451-ee91fc84f742@canonical.com>
On Sun, Dec 31, 2017 at 12:37:56PM +0800, Aaron Ma wrote:
> Please refer to the Lenovo forum:
Please always include the proper email context, I have no idea what
you are talking about here. Remember, some people get hundreds, if not
thousands, of emails a day...
thnaks,
greg k-h
^ permalink raw reply
* Re: xps 15 9560 touchpad high interrupts
From: Baruch Siach @ 2017-12-31 6:25 UTC (permalink / raw)
To: Javad Karabi; +Cc: linux-input
In-Reply-To: <CAEOHGO=GYr4NCnwNXf=it6WFVRQ0d-eYTVKoZSiuhYhumnBK5A@mail.gmail.com>
Hi Javad Karabi,
Added linux-input list to Cc.
On Sat, Dec 30, 2017 at 05:10:06PM -0600, Javad Karabi wrote:
> im trying to figure out why i get like 7000 interrupts a second simply by
> resting my finger on the touchpad (not even moving it)
> this is on a xps 15 9560
> and the touchpad is at
> DLL07BE:01 06CB:7A13 Touchpad as
> /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-7/i2c-DLL07BE:01/0018:06CB:7A13.0009/input/input58
>
> could you provide me with any advice as to where i should look to figure
> this out?
> i have already tried adding code to i2c-designware-platdrv.c
> i added
> dev->clk_freq = 100000;
> in dw_i2c_plat_probe, but it still shoots off thousands of interrupts a
> second (and they are apparently spurious interrupts, atleast accoding
> to /proc/irq/17/spurious
>
> could you provide any guidance at all? would be much appreciated.. i would
> love to fix this issue and get it upstreamed in the kernel if possible.
> thank you
i2c_designware is a I2C bus master driver. It allows the host to communicate
with various devices. Your touchpad is apparently one such device. But each
device on the I2C bus needs its own driver. I have no idea which driver
handles your touchpad device. Maybe someone on the linux-input list knows.
Specifically, the interrupts handling has nothing to do with the I2C bus.
Unlike PCIe, I2C provides no in-bus interrupt delivery facility. I2C devices
usually use a separate dedicated interrupt line. So the spurious interrupts
that you see must be handled at the touchpad input driver level.
One thing that might help others help you is the version of the kernel you are
running. Please provide the output of 'uname -rv' on your machine.
Hope this helps,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH] Revert "Input: trackpoint - add new trackpoint firmware ID"
From: Aaron Ma @ 2017-12-31 4:37 UTC (permalink / raw)
To: Sebastian Schmidt, linux-input, dmitry.torokhov; +Cc: Greg KH
In-Reply-To: <20171230152213.GA2099@marax.lan.yath.de>
Please refer to the Lenovo forum:
https://forums.lenovo.com/t5/forums/v3_1/forumtopicpage/board-id/Special_Interest_Linux/thread-id/9645/page/23
The patch you tried to revert solved many people's issue.
Also the people who used the trackpointdetect.exe to identify their ID
as (Elan (ID:03).
The elan driver can *not* work on their trackpoint, neither does ALPS.
They didn't match the ID tables, commands on ALPS or Elan driver.
The error log of Windows firmware update tools maybe wrong, so do NOT
based on it to guess what device it is.
^ permalink raw reply
* Re: PROBLEM: Changing speed on ThinkPad X1 Carbon 5th trackpoint causes "failed to enable mouse"
From: Aaron Ma @ 2017-12-30 18:54 UTC (permalink / raw)
To: Sebastian Schmidt; +Cc: Greg KH, dmitry.torokhov, linux-input
In-Reply-To: <20171230181625.GA1687@marax.lan.yath.de>
The patch[2] is recognized to ""ImPS/2 Generic Wheel Mouse""
Please refer to link:
https://lkml.org/lkml/2017/8/21/558
Which mentioned my commit can resolve his issue.
Your scroll mode is workable by libinput and that is not enabled by
kernel driver.
People who used "xorg-input-evdev" will *NOT* enable scroll mode.
Lenovo delivered some different touchpads/trackpoint, sometimes with
broken firmwares.
I have helped one person:edvard.holst@gmail.com who had investigated
trackpoint bug for long time, he mentioned the your link[1] long time
ago. Finally it's firmware didn't respond anything through PS/2 command.
LEN009a/LEN0072 do have some difference, but for your log and e-mail, I
didn't see any difference.
^ permalink raw reply
* Re: PROBLEM: Changing speed on ThinkPad X1 Carbon 5th trackpoint causes "failed to enable mouse"
From: Sebastian Schmidt @ 2017-12-30 18:16 UTC (permalink / raw)
To: Aaron Ma; +Cc: Greg KH, dmitry.torokhov, linux-input
In-Reply-To: <02082a9b-8fdd-0878-0daa-ead72743d5fd@canonical.com>
On Sun, Dec 31, 2017 at 01:37:15AM +0800, Aaron Ma wrote:
> I don't have X1C5 now, but give a quick test on: X1 Yoga 3rd with
> trackpoint (LEN009a), X1 yoga is pretty similar as X1 Carbon on
> trackpoint/touchpad.
Aha, now we’re getting somewhere. Mine actually is LEN0072 (as far as I
can tell from the ACPI DSDT), and the Windows update utility says:
| Pst Vendor : Elan
| [ERROR]: This TrackPoint is Elan (ID:03)
In [1], there are people mentioning that newer Trackpoints changed their
ID from LEN0073 to LEN0072, and a patch[2] for adding that to the RMI
whitelist has been proposed.
Either way, I don’t believe that trackpoint.c is the right driver for
this Trackpoint. Some values are indeed changeable in sysfs, however
without noticeable effect. Setting “thresh” causes the same error as
setting speed; I didn’t check the remaining properties.
> When trackpoint(without the commit) is recognized as "PS/2 Generic
> Mouse", scroll mode does *NOT* work.
I’m not making that up. It does work. And libinput also knows about scrolling.
% xinput list-props "PS/2 Generic Mouse"
Device 'PS/2 Generic Mouse':
Device Enabled (142): 1
Coordinate Transformation Matrix (144): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
libinput Natural Scrolling Enabled (315): 0
libinput Natural Scrolling Enabled Default (316): 0
libinput Left Handed Enabled (317): 0
libinput Left Handed Enabled Default (318): 0
libinput Accel Speed (319): 0.000000
libinput Accel Speed Default (320): 0.000000
libinput Accel Profiles Available (321): 1, 1
libinput Accel Profile Enabled (322): 1, 0
libinput Accel Profile Enabled Default (323): 1, 0
libinput Scroll Methods Available (324): 0, 0, 1
libinput Scroll Method Enabled (325): 0, 0, 1
libinput Scroll Method Enabled Default (326): 0, 0, 1
libinput Button Scrolling Button (327): 2
^^^^^^^^^^^^^^^^^^^^^^^
libinput Button Scrolling Button Default (328): 2
libinput Middle Emulation Enabled (329): 0
libinput Middle Emulation Enabled Default (330): 0
libinput Send Events Modes Available (265): 1, 0
libinput Send Events Mode Enabled (266): 0, 0
libinput Send Events Mode Enabled Default (267): 0, 0
Device Node (268): "/dev/input/event2"
Device Product ID (269): 2, 1
libinput Drag Lock Buttons (331): <no items>
libinput Horizontal Scroll Enabled (332): 1
%
1: https://forums.lenovo.com/t5/forums/v3_1/forumtopicpage/board-id/Special_Interest_Linux/thread-id/9645/page/16
2: https://lkml.org/lkml/2017/8/18/861
^ permalink raw reply
* Re: PROBLEM: Changing speed on ThinkPad X1 Carbon 5th trackpoint causes "failed to enable mouse"
From: Aaron Ma @ 2017-12-30 17:37 UTC (permalink / raw)
To: Sebastian Schmidt; +Cc: Greg KH, dmitry.torokhov, linux-input
In-Reply-To: <20171230155358.GE23284@marax.lan.yath.de>
I don't have X1C5 now, but give a quick test on: X1 Yoga 3rd with
trackpoint (LEN009a), X1 yoga is pretty similar as X1 Carbon on
trackpoint/touchpad.
When trackpoint(without the commit) is recognized as "PS/2 Generic
Mouse", scroll mode does *NOT* work.
^ permalink raw reply
* Re: PROBLEM: Changing speed on ThinkPad X1 Carbon 5th trackpoint causes "failed to enable mouse"
From: Sebastian Schmidt @ 2017-12-30 15:53 UTC (permalink / raw)
To: Aaron Ma; +Cc: Greg KH, dmitry.torokhov, linux-input
In-Reply-To: <0eb65344-d160-bb14-723a-1d06ac3e1b33@canonical.com>
On Sat, Dec 30, 2017 at 11:46:53PM +0800, Aaron Ma wrote:
> Without my commit the trackpoint is identified to "generic PS/2 mouse",
> some features like the scroll mode (middle button and trackpoint) can
> not work.
Actually, this used to work even prior to your patch for me. So we
apparently have different types of Trackpoint.
^ permalink raw reply
* Re: PROBLEM: Changing speed on ThinkPad X1 Carbon 5th trackpoint causes "failed to enable mouse"
From: Aaron Ma @ 2017-12-30 15:46 UTC (permalink / raw)
To: Greg KH; +Cc: Sebastian Schmidt, dmitry.torokhov, linux-input
In-Reply-To: <20171230152616.GA26378@kroah.com>
Without my commit the trackpoint is identified to "generic PS/2 mouse",
some features like the scroll mode (middle button and trackpoint) can
not work.
And there is no speed in sysfs that can control the mouse speed.
With my commit, it includes trackpoint features like scroll mode.
But it failed to set speed in sysfs,
The real issue: the firmware of trackpoint is failed to responded the
commands of speed.
But user can use xinput/xorg/udev to set the speed correctly.
Reverting this patch will not make things better or work properly.
So I don't think it should be reverted.
Sorry for my poor English.
Thanks,
Aaron
^ permalink raw reply
* Re: [PATCH] Revert "Input: trackpoint - add new trackpoint firmware ID"
From: Sebastian Schmidt @ 2017-12-30 15:41 UTC (permalink / raw)
To: Greg KH; +Cc: linux-input, dmitry.torokhov, Aaron Ma
In-Reply-To: <20171230153213.GA28219@kroah.com>
On Sat, Dec 30, 2017 at 04:32:13PM +0100, Greg KH wrote:
> On Sat, Dec 30, 2017 at 04:22:13PM +0100, Sebastian Schmidt wrote:
> > This reverts commit ec667683c532c93fb41e100e5d61a518971060e2, which
> > breaks the Trackpoint on ThinkPad X1 Carbon Gen5 (Model 20HR). That
> > commit intended to add support for later firmware versions to the
> > trackpoint driver, however, the version is reported in the second byte
> > whereas the change was made to the magic byte preceding that version.
> > The update package linked by Lenovo suggests that 20HR models use an
> > ALPS Touchpad instead.
> >
> > Signed-off-by: Sebastian Schmidt <yath@yath.de>
> > Acked-by: Greg KH <gregkh@linuxfoundation.org>
>
> Um, I didn't ack this patch, don't ever put something like that on a
> patch unless it is offered by the person.
Sorry. :( Should I re-send the amended patch?
Sebastian
^ permalink raw reply
* Re: [PATCH] Revert "Input: trackpoint - add new trackpoint firmware ID"
From: Greg KH @ 2017-12-30 15:32 UTC (permalink / raw)
To: Sebastian Schmidt; +Cc: linux-input, dmitry.torokhov, Aaron Ma
In-Reply-To: <20171230152213.GA2099@marax.lan.yath.de>
On Sat, Dec 30, 2017 at 04:22:13PM +0100, Sebastian Schmidt wrote:
> This reverts commit ec667683c532c93fb41e100e5d61a518971060e2, which
> breaks the Trackpoint on ThinkPad X1 Carbon Gen5 (Model 20HR). That
> commit intended to add support for later firmware versions to the
> trackpoint driver, however, the version is reported in the second byte
> whereas the change was made to the magic byte preceding that version.
> The update package linked by Lenovo suggests that 20HR models use an
> ALPS Touchpad instead.
>
> Signed-off-by: Sebastian Schmidt <yath@yath.de>
> Acked-by: Greg KH <gregkh@linuxfoundation.org>
Um, I didn't ack this patch, don't ever put something like that on a
patch unless it is offered by the person.
thanks,
greg k-h
^ permalink raw reply
* Re: PROBLEM: Changing speed on ThinkPad X1 Carbon 5th trackpoint causes "failed to enable mouse"
From: Greg KH @ 2017-12-30 15:26 UTC (permalink / raw)
To: Aaron Ma; +Cc: Sebastian Schmidt, dmitry.torokhov, linux-input
In-Reply-To: <4eeea63f-3131-0571-26e4-0f645dd3bc62@canonical.com>
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Sat, Dec 30, 2017 at 11:08:44PM +0800, Aaron Ma wrote:
> Greg, Please check my last e-mail.
Define "last" :)
> My patch will enable the synaptic trackpoint features like scroll mode
> with middle button and trackpoint stick.
>
> Even there is a firmware issue that it can not be set speed on sysfs.
What does that mean?
> But it is not driver issue.
> We can NOT to make wrong code than facing the real issue.
Again, I can not parse this, sorry.
If reverting a patch causes the device to work properly again, it needs
to be reverted, right? Otherwise it is a regression, and we don't like
those at all.
thanks,
greg k-h
^ permalink raw reply
* Re: PROBLEM: Changing speed on ThinkPad X1 Carbon 5th trackpoint causes "failed to enable mouse"
From: Sebastian Schmidt @ 2017-12-30 15:24 UTC (permalink / raw)
To: Greg KH; +Cc: Aaron Ma, dmitry.torokhov, linux-input
In-Reply-To: <20171230150235.GA19890@kroah.com>
On Sat, Dec 30, 2017 at 04:02:35PM +0100, Greg KH wrote:
> On Sat, Dec 30, 2017 at 03:40:40PM +0100, Sebastian Schmidt wrote:
> > Because reverting your commit fixes the issue for me.
>
> Great, it should be reverted then. Care to send the patch that does the
> revert to make it easy for Dmitry to apply it?
Sent, thanks.
Sebastian
^ permalink raw reply
* [PATCH] Revert "Input: trackpoint - add new trackpoint firmware ID"
From: Sebastian Schmidt @ 2017-12-30 15:22 UTC (permalink / raw)
To: linux-input, dmitry.torokhov; +Cc: Greg KH, Aaron Ma
This reverts commit ec667683c532c93fb41e100e5d61a518971060e2, which
breaks the Trackpoint on ThinkPad X1 Carbon Gen5 (Model 20HR). That
commit intended to add support for later firmware versions to the
trackpoint driver, however, the version is reported in the second byte
whereas the change was made to the magic byte preceding that version.
The update package linked by Lenovo suggests that 20HR models use an
ALPS Touchpad instead.
Signed-off-by: Sebastian Schmidt <yath@yath.de>
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
---
drivers/input/mouse/trackpoint.c | 3 +--
drivers/input/mouse/trackpoint.h | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/input/mouse/trackpoint.c b/drivers/input/mouse/trackpoint.c
index 0871010f18d5..20b5b21c1bba 100644
--- a/drivers/input/mouse/trackpoint.c
+++ b/drivers/input/mouse/trackpoint.c
@@ -265,8 +265,7 @@ static int trackpoint_start_protocol(struct psmouse *psmouse, unsigned char *fir
if (ps2_command(&psmouse->ps2dev, param, MAKE_PS2_CMD(0, 2, TP_READ_ID)))
return -1;
- /* add new TP ID. */
- if (!(param[0] & TP_MAGIC_IDENT))
+ if (param[0] != TP_MAGIC_IDENT)
return -1;
if (firmware_id)
diff --git a/drivers/input/mouse/trackpoint.h b/drivers/input/mouse/trackpoint.h
index 88055755f82e..5617ed3a7d7a 100644
--- a/drivers/input/mouse/trackpoint.h
+++ b/drivers/input/mouse/trackpoint.h
@@ -21,9 +21,8 @@
#define TP_COMMAND 0xE2 /* Commands start with this */
#define TP_READ_ID 0xE1 /* Sent for device identification */
-#define TP_MAGIC_IDENT 0x03 /* Sent after a TP_READ_ID followed */
+#define TP_MAGIC_IDENT 0x01 /* Sent after a TP_READ_ID followed */
/* by the firmware ID */
- /* Firmware ID includes 0x1, 0x2, 0x3 */
/*
--
2.15.1
^ permalink raw reply related
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