* Re: [PATCH v2 1/2] Input: edt-ft5x06 - Add support for regulator
From: Rob Herring @ 2018-01-03 19:48 UTC (permalink / raw)
To: Mylène Josserand
Cc: dmitry.torokhov, mark.rutland, linux, maxime.ripard, wens,
linux-arm-kernel, linux-input, devicetree, linux-kernel,
thomas.petazzoni, quentin.schulz
In-Reply-To: <20171228163336.28131-2-mylene.josserand@free-electrons.com>
On Thu, Dec 28, 2017 at 05:33:35PM +0100, Mylène Josserand wrote:
> Add the support of regulator to use it as VCC source.
>
> Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
> ---
> .../bindings/input/touchscreen/edt-ft5x06.txt | 1 +
> drivers/input/touchscreen/edt-ft5x06.c | 33 ++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] platform/x86: silead_dmi: Add entry for the Teclast X98 Plus II
From: Andy Shevchenko @ 2018-01-03 14:10 UTC (permalink / raw)
To: Hans de Goede
Cc: Darren Hart, Paul Cercueil, Andy Shevchenko, linux-input,
Platform Driver, Linux Kernel Mailing List
In-Reply-To: <5c5301e1-48f5-5762-b1d8-95e5f4a2bd8d@redhat.com>
On Wed, Jan 3, 2018 at 10:01 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> On 03-01-18 00:40, Darren Hart wrote:
>> On Tue, Jan 02, 2018 at 07:39:27PM +0100, Paul Cercueil wrote:
>> Generally "testing" is the branch you want to base on if linus/master
>> doesn't work as the review-* branches *will* rebase frequently.
>> Exceptions exist of course, and this patch is just fine - just for
>> future reference.
>
>
> This is my "fault", I asked Paul to rebase on top of
> review-andy as that had 1 new silead_dmi patches missing
> from testing, so otherwise we would end up with a conflict when
> merging review branches. Same reason why I've been basing my
> silead_dmi patches on top of review-andy even though that is
> an unusual base to use.
Darren, in this case it's exceptional since there is a stream of a
patches against silead_dmi. They appear faster than older appear in
testing.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [RFC PATCH] input: Add disable sysfs entry for every input device
From: Pali Rohár @ 2018-01-03 9:31 UTC (permalink / raw)
To: Bastien Nocera, Dmitry Torokhov
Cc: Ivaylo Dimitrov, Sebastian Reichel, Pavel Machek,
Mauro Carvalho Chehab, Chuck Ebbert, Henrik Rydberg, linux-input,
linux-kernel
In-Reply-To: <1514944049.2523.28.camel@hadess.net>
On Wednesday 03 January 2018 02:47:29 Bastien Nocera wrote:
> On Tue, 2018-01-02 at 22:54 +0100, Pali Rohár wrote:
> > On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > > I don't doubt that the use cases should be catered for, I
> > > essentially
> > > did that same work without kernel changes for GNOME. What I doubt
> > > is
> > > the fuzzy semantics, the fact that the device is kept opened but no
> > > data is sent (that's not power saving), that whether users are
> > > revoked
> > > or should be revoked isn't clear, and that the goal is basically to
> > > work around stupid input handling when at the console. When running
> > > a
> > > display manager, this is all avoided.
> > >
> > > If this were to go through, then the semantics and behaviour needs
> > > to
> > > be better explained, power saving actually made possible, and make
> > > sure
> > > that libinput can proxy that state to the users on the console. Or
> > > an
> > > ioctl added to the evdev device to disable them.
> >
> > So, do you mean to implement this "disable" action as ioctl for
> > particular /dev/input/event* device (instead of sysfs entry)?
>
> Yes, so the device can be powered down without the device node being
> closed and made unavailable. I don't know whether that's something
> that's already possible for all cases, but there's already
> opportunistic in a lot of drivers and subsystems.
>
> This opens up a whole new wave of potential problems, but it's a more
> generally useful mechanism, I would think.
Ok. How should API for this ioctl looks like? And do you have an idea
for name of that ioctl?
Dmitry, what do you think about it? It is acceptable for you?
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH v2] platform/x86: silead_dmi: Add entry for the Teclast X98 Plus II
From: Hans de Goede @ 2018-01-03 8:01 UTC (permalink / raw)
To: Darren Hart, Paul Cercueil
Cc: Andy Shevchenko, linux-input, platform-driver-x86, linux-kernel
In-Reply-To: <20180102234033.GB24794@fury>
Hi,
On 03-01-18 00:40, Darren Hart wrote:
> On Tue, Jan 02, 2018 at 07:39:27PM +0100, Paul Cercueil wrote:
>> Add touchscreen platform data for the Teclast X98 Plus II tablet.
>>
>> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>> Acked-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/platform/x86/silead_dmi.c | 24 ++++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> v2: Rebased on top of http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/shortlog/refs/heads/review-andy
>
> Generally "testing" is the branch you want to base on if linus/master
> doesn't work as the review-* branches *will* rebase frequently.
> Exceptions exist of course, and this patch is just fine - just for
> future reference.
This is my "fault", I asked Paul to rebase on top of
review-andy as that had 1 new silead_dmi patches missing
from testing, so otherwise we would end up with a conflict when
merging review branches. Same reason why I've been basing my
silead_dmi patches on top of review-andy even though that is
an unusual base to use.
Regards,
Hans
^ permalink raw reply
* Re: [RFC PATCH] input: Add disable sysfs entry for every input device
From: Bastien Nocera @ 2018-01-03 1:47 UTC (permalink / raw)
To: Pali Rohár
Cc: Ivaylo Dimitrov, Dmitry Torokhov, Sebastian Reichel, Pavel Machek,
Mauro Carvalho Chehab, Chuck Ebbert, Henrik Rydberg, linux-input,
linux-kernel
In-Reply-To: <20180102215437.i3x2j6jvxtac4ntt@pali>
On Tue, 2018-01-02 at 22:54 +0100, Pali Rohár wrote:
> On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > I don't doubt that the use cases should be catered for, I
> > essentially
> > did that same work without kernel changes for GNOME. What I doubt
> > is
> > the fuzzy semantics, the fact that the device is kept opened but no
> > data is sent (that's not power saving), that whether users are
> > revoked
> > or should be revoked isn't clear, and that the goal is basically to
> > work around stupid input handling when at the console. When running
> > a
> > display manager, this is all avoided.
> >
> > If this were to go through, then the semantics and behaviour needs
> > to
> > be better explained, power saving actually made possible, and make
> > sure
> > that libinput can proxy that state to the users on the console. Or
> > an
> > ioctl added to the evdev device to disable them.
>
> So, do you mean to implement this "disable" action as ioctl for
> particular /dev/input/event* device (instead of sysfs entry)?
Yes, so the device can be powered down without the device node being
closed and made unavailable. I don't know whether that's something
that's already possible for all cases, but there's already
opportunistic in a lot of drivers and subsystems.
This opens up a whole new wave of potential problems, but it's a more
generally useful mechanism, I would think.
^ permalink raw reply
* Re: [RFC PATCH] input: Add disable sysfs entry for every input device
From: Bastien Nocera @ 2018-01-03 1:43 UTC (permalink / raw)
To: Pali Rohár
Cc: Dmitry Torokhov, Sebastian Reichel, Pavel Machek,
Mauro Carvalho Chehab, Chuck Ebbert, Henrik Rydberg,
Ivaylo Dimitrov, linux-input, linux-kernel
In-Reply-To: <20180102214852.pnsocg7qaxt5y6qh@pali>
On Tue, 2018-01-02 at 22:48 +0100, Pali Rohár wrote:
> On Tuesday 03 January 2017 12:21:21 Bastien Nocera wrote:
> > On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> > > On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
> > > > On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> > > > > This patch allows user to disable events from any input
> > > > > device so
> > > > > events
> > > > > would not be delivered to userspace.
> > > > >
> > > > > Currently there is no way to disable particular input device
> > > > > by
> > > > > kernel.
> > > > > User for different reasons would need it for integrated PS/2
> > > > > keyboard or
> > > > > touchpad in notebook or touchscreen on mobile device to
> > > > > prevent
> > > > > sending
> > > > > events. E.g. mobile phone in pocket or broken integrated PS/2
> > > > > keyboard.
> > > > >
> > > > > This is just a RFC patch, not tested yet. Original post about
> > > > > motivation
> > > > > about this patch is there: https://lkml.org/lkml/2014/11/29/9
> > > > > 2
> > > >
> > > >
> > > > Having implemented something of that ilk in user-space (we
> > > > automatically disable touch devices when the associated screen
> > > > is
> > > > turned off/suspended), I think this might need more thought.
> > >
> > > How to implement such thing in userspace? I think you cannot do
> > > that
> > > without rewriting every one userspace application which uses
> > > input.
> > >
> > > > What happens when a device is opened and the device disabled
> > >
> > > through
> > > > sysfs, are the users revoked?
> > >
> > > Applications will not receive events. Same as if input device
> > > does
> > > not
> > > generates events.
> > >
> > > > Does this put the device in suspend in the same way that
> > > > closing
> > >
> > > the
> > > > device's last user does?
> > >
> > > Current code not (this is just RFC prototype), but it should be
> > > possible
> > > to implement.
> > >
> > > > Is this not better implemented in user-space at the session
> > > > level,
> > > > where it knows about which output corresponds to which input
> > >
> > > device?
> > >
> > > How to do that without rewriting existing applications?
> > >
> > > > Is this useful enough to disable misbehaving devices on
> > > > hardware,
> > >
> > > so
> > > > that the device is not effective on boot?
> > >
> > > In case integrated device is absolutely unusable and generates
> > > always
> > > random events, it does not solve problem at boot time.
> > >
> > > But more real case is laptop with closed LID press buttons and
> > > here
> > > it
> > > is useful.
> >
> > There's usually a display manager in between the application and
> > the
> > input device.
>
> But that is not always truth. In some cases there are applications
> which
> opens input device directly.
Which is why I said "usually", and not "always".
> > Whether it's X.org, or a Wayland compositor. Even David's
> > https://github.com/dvdhrm/kmscon could help for console
> > applications.
>
> That kmscon needs KMS, right? So it would not work on hardware which
> do
> not have KMS drivers.
Except that the use cases are getting smaller and smaller. At one
point, it might become easier to carry that patch in your tree, for
your use case.
It's not useful on desktop Linux, it's not useful for Android or Chrome
OS. It seems it's only really useful for the console when there's no
way to use a display manager between the console subsystem and the
"UI".
At this point I'd ask whether whatever is consuming those buttons can't
be modified instead of the kernel. You'd even get the benefit of being
able to close devices and save some power.
^ permalink raw reply
* Re: [RFC PATCH] input: Add disable sysfs entry for every input device
From: Bastien Nocera @ 2018-01-03 1:38 UTC (permalink / raw)
To: Pavel Machek
Cc: Pali Rohár, Dmitry Torokhov, Sebastian Reichel,
Mauro Carvalho Chehab, Chuck Ebbert, Henrik Rydberg,
Ivaylo Dimitrov, linux-input, linux-kernel
In-Reply-To: <20170117110711.GA26116@xo-6d-61-c0.localdomain>
On Tue, 2017-01-17 at 12:07 +0100, Pavel Machek wrote:
>
<snip>
> We'd really like it to work on plain old text console, too, because
> that's what
> I'm using on n900, and with old maemo userspace, because that's what
> everyone
> else uses.
>
> You mentioned you think X.org can do this kind of device disabling
> (and powersave).
> Would you have an idea how to activate that? I'd like to disable
> touchscreen
> and most of the buttons when the device is "in the pocket".
You need to change the "Device Enabled" property in X. What this does
depends on which Xorg driver it uses.
^ permalink raw reply
* Re: xps 15 9560 touchpad high interrupts
From: Javad Karabi @ 2018-01-03 0:24 UTC (permalink / raw)
To: Baruch Siach; +Cc: linux-input, linux-i2c
In-Reply-To: <20180102134605.km5plmeef7nqmpwg@tarshish>
On Tue, Jan 2, 2018 at 7:46 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Javad Karabi,
>
> On Mon, Jan 01, 2018 at 05:18:00PM -0600, Javad Karabi wrote:
>> On Mon, Jan 1, 2018 at 12:14 AM, Baruch Siach <baruch@tkos.co.il> wrote:
>> > 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.
>>
>> 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?
>
> It is not the touchpad that shoots the interrupts. It is the i2c-designware
> hardware module.
>
>> 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?
>
> I don't think that the touchpad sensitivity has anything to do with this
> interrupts storm.
>
> There is another possibility. The USB hub controller driver might be shooting
> i2c transactions at the USB hub. In this case the bug is not in the i2c master
> driver.
>
> Can you identify the driver that initiates the i2c transactions?
>
> baruch
>
> --
> http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
> The USB hub controller driver might be shooting
> i2c transactions at the USB hub. In this case the bug is not in the i2c master
> driver.
im still rather confused about the relationship between the i2c bus
and the usb bus.
from what i understand, you have the i2c bus, which has a touchpad,
and the touchpad sends i2c transactions
when an event has occured, e.g. i moved my finger on the touchpad...
is that correct?
> Can you identify the driver that initiates the i2c transactions?
i would be more than happy to identify that driver if you could point
me in the right direction to figure that out
^ permalink raw reply
* Re: [PATCH v2] platform/x86: silead_dmi: Add entry for the Teclast X98 Plus II
From: Darren Hart @ 2018-01-02 23:40 UTC (permalink / raw)
To: Paul Cercueil
Cc: Hans de Goede, Andy Shevchenko, linux-input, platform-driver-x86,
linux-kernel
In-Reply-To: <20180102183928.15267-1-paul@crapouillou.net>
On Tue, Jan 02, 2018 at 07:39:27PM +0100, Paul Cercueil wrote:
> Add touchscreen platform data for the Teclast X98 Plus II tablet.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Acked-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/platform/x86/silead_dmi.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> v2: Rebased on top of http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/shortlog/refs/heads/review-andy
Generally "testing" is the branch you want to base on if linus/master
doesn't work as the review-* branches *will* rebase frequently.
Exceptions exist of course, and this patch is just fine - just for
future reference.
Andy pushed his changes to testing already, so this is no longer
dependent on his review queue. I have applied to review-dvhart, will go
to testing shortly.
Thank you Paul.
--
Darren Hart
VMware Open Source Technology Center
^ permalink raw reply
* Re: [RFC PATCH] input: Add disable sysfs entry for every input device
From: Pali Rohár @ 2018-01-02 21:54 UTC (permalink / raw)
To: Bastien Nocera
Cc: Ivaylo Dimitrov, Dmitry Torokhov, Sebastian Reichel, Pavel Machek,
Mauro Carvalho Chehab, Chuck Ebbert, Henrik Rydberg, linux-input,
linux-kernel
In-Reply-To: <1483540655.2420.18.camel@hadess.net>
On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> I don't doubt that the use cases should be catered for, I essentially
> did that same work without kernel changes for GNOME. What I doubt is
> the fuzzy semantics, the fact that the device is kept opened but no
> data is sent (that's not power saving), that whether users are revoked
> or should be revoked isn't clear, and that the goal is basically to
> work around stupid input handling when at the console. When running a
> display manager, this is all avoided.
>
> If this were to go through, then the semantics and behaviour needs to
> be better explained, power saving actually made possible, and make sure
> that libinput can proxy that state to the users on the console. Or an
> ioctl added to the evdev device to disable them.
So, do you mean to implement this "disable" action as ioctl for
particular /dev/input/event* device (instead of sysfs entry)?
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [RFC PATCH] input: Add disable sysfs entry for every input device
From: Pali Rohár @ 2018-01-02 21:48 UTC (permalink / raw)
To: Bastien Nocera
Cc: Dmitry Torokhov, Sebastian Reichel, Pavel Machek,
Mauro Carvalho Chehab, Chuck Ebbert, Henrik Rydberg,
Ivaylo Dimitrov, linux-input, linux-kernel
In-Reply-To: <1483442481.2420.12.camel@hadess.net>
On Tuesday 03 January 2017 12:21:21 Bastien Nocera wrote:
> On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> > On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
> > > On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> > > > This patch allows user to disable events from any input device so
> > > > events
> > > > would not be delivered to userspace.
> > > >
> > > > Currently there is no way to disable particular input device by
> > > > kernel.
> > > > User for different reasons would need it for integrated PS/2
> > > > keyboard or
> > > > touchpad in notebook or touchscreen on mobile device to prevent
> > > > sending
> > > > events. E.g. mobile phone in pocket or broken integrated PS/2
> > > > keyboard.
> > > >
> > > > This is just a RFC patch, not tested yet. Original post about
> > > > motivation
> > > > about this patch is there: https://lkml.org/lkml/2014/11/29/92
> > >
> > > Having implemented something of that ilk in user-space (we
> > > automatically disable touch devices when the associated screen is
> > > turned off/suspended), I think this might need more thought.
> >
> > How to implement such thing in userspace? I think you cannot do that
> > without rewriting every one userspace application which uses input.
> >
> > > What happens when a device is opened and the device disabled
> > through
> > > sysfs, are the users revoked?
> >
> > Applications will not receive events. Same as if input device does
> > not
> > generates events.
> >
> > > Does this put the device in suspend in the same way that closing
> > the
> > > device's last user does?
> >
> > Current code not (this is just RFC prototype), but it should be
> > possible
> > to implement.
> >
> > > Is this not better implemented in user-space at the session level,
> > > where it knows about which output corresponds to which input
> > device?
> >
> > How to do that without rewriting existing applications?
> >
> > > Is this useful enough to disable misbehaving devices on hardware,
> > so
> > > that the device is not effective on boot?
> >
> > In case integrated device is absolutely unusable and generates
> > always
> > random events, it does not solve problem at boot time.
> >
> > But more real case is laptop with closed LID press buttons and here
> > it
> > is useful.
>
> There's usually a display manager in between the application and the
> input device.
But that is not always truth. In some cases there are applications which
opens input device directly.
> Whether it's X.org, or a Wayland compositor. Even David's
> https://github.com/dvdhrm/kmscon could help for console applications.
That kmscon needs KMS, right? So it would not work on hardware which do
not have KMS drivers.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH] synaptics: fix rmi4 bus dependencies
From: Andrew Duggan @ 2018-01-02 19:37 UTC (permalink / raw)
To: Dmitry Torokhov, Matteo Croce; +Cc: linux-input
In-Reply-To: <20180102192143.egooy4onto73qd3y@dtor-ws>
On 01/02/2018 11:21 AM, Dmitry Torokhov wrote:
> On Tue, Jan 02, 2018 at 08:16:09PM +0100, Matteo Croce wrote:
>> Make MOUSE_PS2_SYNAPTICS_SMBUS select MOUSE_PS2_SYNAPTICS because if
>> the latter is disabled the detection and switching code isn't being run.
> Hmm, it should. In synaptics.c:
>
> #if defined(CONFIG_MOUSE_PS2_SYNAPTICS) || \
> defined(CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS)
>
> int synaptics_init(struct psmouse *psmouse)
> {
> struct synaptics_device_info info;
> int error;
> int retval;
>
> psmouse_reset(psmouse);
> ...
> }
>
> The intent was to allow disabling the PS/2 portion of Synaptics driver
> while retaining the switching to SMbus capability.
Oh, I suggested to Matteo that this patch might be needed off list. I
clearly didn't look closely enough to see that MOUSE_PS2_SYNAPTICS_SMBUS
is intended to be able to be used independently of MOUSE_PS2_SYNAPTICS.
However, he did seem to see behavior where the mode switch did not occur
when MOUSE_PS2_SYNAPTICS was disabled, but MOUSE_PS2_SYNAPTICS_SMBUS was
enabled. That will need to be investigated further.
Andrew
> Thanks.
>
>> Signed-off-by: Matteo Croce <mcroce@redhat.com>
>> ---
>> drivers/input/mouse/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
>> index 89ebb8f39fee..77a0bcb611a4 100644
>> --- a/drivers/input/mouse/Kconfig
>> +++ b/drivers/input/mouse/Kconfig
>> @@ -83,6 +83,7 @@ config MOUSE_PS2_SYNAPTICS_SMBUS
>> default y
>> depends on MOUSE_PS2
>> depends on I2C=y || I2C=MOUSE_PS2
>> + select MOUSE_PS2_SYNAPTICS
>> select MOUSE_PS2_SMBUS
>> help
>> Say Y here if you have a Synaptics RMI4 touchpad connected to
>> --
>> 2.14.3
>>
^ permalink raw reply
* Re: [PATCH] synaptics: fix rmi4 bus dependencies
From: Dmitry Torokhov @ 2018-01-02 19:21 UTC (permalink / raw)
To: Matteo Croce; +Cc: linux-input, Andrew Duggan
In-Reply-To: <20180102191609.21460-1-mcroce@redhat.com>
On Tue, Jan 02, 2018 at 08:16:09PM +0100, Matteo Croce wrote:
> Make MOUSE_PS2_SYNAPTICS_SMBUS select MOUSE_PS2_SYNAPTICS because if
> the latter is disabled the detection and switching code isn't being run.
Hmm, it should. In synaptics.c:
#if defined(CONFIG_MOUSE_PS2_SYNAPTICS) || \
defined(CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS)
int synaptics_init(struct psmouse *psmouse)
{
struct synaptics_device_info info;
int error;
int retval;
psmouse_reset(psmouse);
...
}
The intent was to allow disabling the PS/2 portion of Synaptics driver
while retaining the switching to SMbus capability.
Thanks.
>
> Signed-off-by: Matteo Croce <mcroce@redhat.com>
> ---
> drivers/input/mouse/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
> index 89ebb8f39fee..77a0bcb611a4 100644
> --- a/drivers/input/mouse/Kconfig
> +++ b/drivers/input/mouse/Kconfig
> @@ -83,6 +83,7 @@ config MOUSE_PS2_SYNAPTICS_SMBUS
> default y
> depends on MOUSE_PS2
> depends on I2C=y || I2C=MOUSE_PS2
> + select MOUSE_PS2_SYNAPTICS
> select MOUSE_PS2_SMBUS
> help
> Say Y here if you have a Synaptics RMI4 touchpad connected to
> --
> 2.14.3
>
--
Dmitry
^ permalink raw reply
* [PATCH] synaptics: fix rmi4 bus dependencies
From: Matteo Croce @ 2018-01-02 19:16 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input; +Cc: Andrew Duggan
Make MOUSE_PS2_SYNAPTICS_SMBUS select MOUSE_PS2_SYNAPTICS because if
the latter is disabled the detection and switching code isn't being run.
Signed-off-by: Matteo Croce <mcroce@redhat.com>
---
drivers/input/mouse/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index 89ebb8f39fee..77a0bcb611a4 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -83,6 +83,7 @@ config MOUSE_PS2_SYNAPTICS_SMBUS
default y
depends on MOUSE_PS2
depends on I2C=y || I2C=MOUSE_PS2
+ select MOUSE_PS2_SYNAPTICS
select MOUSE_PS2_SMBUS
help
Say Y here if you have a Synaptics RMI4 touchpad connected to
--
2.14.3
^ permalink raw reply related
* [PATCH v2] platform/x86: silead_dmi: Add entry for the Teclast X98 Plus II
From: Paul Cercueil @ 2018-01-02 18:39 UTC (permalink / raw)
To: Hans de Goede, Darren Hart, Andy Shevchenko
Cc: linux-input, platform-driver-x86, linux-kernel, Paul Cercueil
In-Reply-To: <20180102134239.3579-1-paul@crapouillou.net>
Add touchscreen platform data for the Teclast X98 Plus II tablet.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/platform/x86/silead_dmi.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
v2: Rebased on top of http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/shortlog/refs/heads/review-andy
diff --git a/drivers/platform/x86/silead_dmi.c b/drivers/platform/x86/silead_dmi.c
index 713446ee3b61..ee8d8e844eb0 100644
--- a/drivers/platform/x86/silead_dmi.c
+++ b/drivers/platform/x86/silead_dmi.c
@@ -247,6 +247,22 @@ static const struct silead_ts_dmi_data trekstor_primebook_c13_data = {
.properties = trekstor_primebook_c13_props,
};
+static const struct property_entry teclast_x98plus2_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 2048),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1280),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-x"),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+ PROPERTY_ENTRY_STRING("firmware-name",
+ "gsl1686-teclast_x98plus2.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ { }
+};
+
+static const struct silead_ts_dmi_data teclast_x98plus2_data = {
+ .acpi_name = "MSSL1680:00",
+ .properties = teclast_x98plus2_props,
+};
+
static const struct dmi_system_id silead_ts_dmi_table[] = {
{
/* CUBE iwork8 Air */
@@ -388,6 +404,14 @@ static const struct dmi_system_id silead_ts_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "Primebook C13"),
},
},
+ {
+ /* Teclast X98 Plus II */
+ .driver_data = (void *)&teclast_x98plus2_data,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TECLAST"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X98 Plus II"),
+ },
+ },
{ },
};
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] xen/input: do not advertise multi-touch pressure support
From: Dmitry Torokhov @ 2018-01-02 17:39 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: xen-devel, linux-kernel, linux-input, Oleksandr Andrushchenko,
Andrii Chepurnyi
In-Reply-To: <1514880775-31185-1-git-send-email-andr2000@gmail.com>
On Tue, Jan 02, 2018 at 10:12:55AM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>
> Some user-space applications expect multi-touch pressure
> on contact to be reported if it is advertised in device
> properties. Otherwise, such applications may treat reports
> not as actual touches, but hovering. Currently this is
> only advertised, but not reported.
> Fix this by not advertising that ABS_MT_PRESSURE is supported.
>
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> Signed-off-by: Andrii Chepurnyi <andrii_chepurnyi@epam.com>
Applied, thank you.
> ---
> drivers/input/misc/xen-kbdfront.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
> index 6bf56bb5f8d9..d91f3b1c5375 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -326,8 +326,6 @@ static int xenkbd_probe(struct xenbus_device *dev,
> 0, width, 0, 0);
> input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
> 0, height, 0, 0);
> - input_set_abs_params(mtouch, ABS_MT_PRESSURE,
> - 0, 255, 0, 0);
>
> ret = input_mt_init_slots(mtouch, num_cont, INPUT_MT_DIRECT);
> if (ret) {
> --
> 2.7.4
>
--
Dmitry
^ permalink raw reply
* [PATCH 2/2] HID: i2c-hid: Fix resume issue on Raydium touchscreen device
From: Aaron Ma @ 2018-01-02 17:30 UTC (permalink / raw)
To: linux-kernel, linux-input, jikos, benjamin.tissoires, aaron.ma
In-Reply-To: <20180102173006.506-1-aaron.ma@canonical.com>
When Rayd touchscreen resumed from S3, it issues too many errors like:
i2c_hid i2c-RAYD0001:00: i2c_hid_get_input: incomplete report (58/5442)
And all the report data are corrupted, touchscreen is unresponsive.
Fix this by re-sending report description command after resume.
Add device ID as a quirk.
Cc: stable@vger.kernel.org
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
---
drivers/hid/hid-ids.h | 3 +++
drivers/hid/i2c-hid/i2c-hid.c | 13 +++++++++++++
2 files changed, 16 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 5da3d6256d25..753cc10aa699 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -516,6 +516,9 @@
#define I2C_VENDOR_ID_HANTICK 0x0911
#define I2C_PRODUCT_ID_HANTICK_5288 0x5288
+#define I2C_VENDOR_ID_RAYD 0x2386
+#define I2C_PRODUCT_ID_RAYD_3118 0x3118
+
#define USB_VENDOR_ID_HANWANG 0x0b57
#define USB_DEVICE_ID_HANWANG_TABLET_FIRST 0x5000
#define USB_DEVICE_ID_HANWANG_TABLET_LAST 0x8fff
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 09404ffdb08b..57a447a9d40e 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -47,6 +47,7 @@
/* quirks to control the device */
#define I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV BIT(0)
#define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET BIT(1)
+#define I2C_HID_QUIRK_RESEND_REPORT_DESCR BIT(2)
/* flags */
#define I2C_HID_STARTED 0
@@ -171,6 +172,8 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
{ I2C_VENDOR_ID_HANTICK, I2C_PRODUCT_ID_HANTICK_5288,
I2C_HID_QUIRK_NO_IRQ_AFTER_RESET },
+ { I2C_VENDOR_ID_RAYD, I2C_PRODUCT_ID_RAYD_3118,
+ I2C_HID_QUIRK_RESEND_REPORT_DESCR },
{ 0, 0 }
};
@@ -1211,6 +1214,16 @@ static int i2c_hid_resume(struct device *dev)
if (ret)
return ret;
+ /* RAYDIUM device (2386:3118) need to re-send report descr cmd
+ * after resume, after this it will be back normal.
+ * otherwise it issues too many incomplete reports.
+ */
+ if (ihid->quirks & I2C_HID_QUIRK_RESEND_REPORT_DESCR) {
+ ret = i2c_hid_command(client, &hid_report_descr_cmd, NULL, 0);
+ if (!ret)
+ return ret;
+ }
+
if (hid->driver && hid->driver->reset_resume) {
ret = hid->driver->reset_resume(hid);
return ret;
--
2.14.3
^ permalink raw reply related
* [PATCH 1/2] HID: core: i2c-hid: fix size check and type usage
From: Aaron Ma @ 2018-01-02 17:30 UTC (permalink / raw)
To: linux-kernel, linux-input, jikos, benjamin.tissoires, aaron.ma
When convert char array with signed int, if the inbuf[x] is negative then
upper bits will be set to 1. Fix this by using u8 instead of char.
ret_size has to be at least 3, hid_input_report use it after minus 2 bytes.
size should be more than 0 to keep memset safe.
Cc: stable@vger.kernel.org
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
---
drivers/hid/hid-core.c | 4 ++--
drivers/hid/i2c-hid/i2c-hid.c | 10 +++++-----
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 0c3f608131cf..992547771d96 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1506,7 +1506,7 @@ int hid_report_raw_event(struct hid_device *hid, int type, u8 *data, int size,
if (rsize > HID_MAX_BUFFER_SIZE)
rsize = HID_MAX_BUFFER_SIZE;
- if (csize < rsize) {
+ if ((csize < rsize) && (csize > 0)) {
dbg_hid("report %d is too short, (%d < %d)\n", report->id,
csize, rsize);
memset(cdata + csize, 0, rsize - csize);
@@ -1566,7 +1566,7 @@ int hid_input_report(struct hid_device *hid, int type, u8 *data, int size, int i
report_enum = hid->report_enum + type;
hdrv = hid->driver;
- if (!size) {
+ if (size <= 0) {
dbg_hid("empty report\n");
ret = -1;
goto unlock;
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index e054ee43c1e2..09404ffdb08b 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -144,10 +144,10 @@ struct i2c_hid {
* register of the HID
* descriptor. */
unsigned int bufsize; /* i2c buffer size */
- char *inbuf; /* Input buffer */
- char *rawbuf; /* Raw Input buffer */
- char *cmdbuf; /* Command buffer */
- char *argsbuf; /* Command arguments buffer */
+ u8 *inbuf; /* Input buffer */
+ u8 *rawbuf; /* Raw Input buffer */
+ u8 *cmdbuf; /* Command buffer */
+ u8 *argsbuf; /* Command arguments buffer */
unsigned long flags; /* device flags */
unsigned long quirks; /* Various quirks */
@@ -473,7 +473,7 @@ static void i2c_hid_get_input(struct i2c_hid *ihid)
ret_size = ihid->inbuf[0] | ihid->inbuf[1] << 8;
- if (!ret_size) {
+ if (ret_size <= 2) {
/* host or device initiated RESET completed */
if (test_and_clear_bit(I2C_HID_RESET_PENDING, &ihid->flags))
wake_up(&ihid->wait);
--
2.14.3
^ permalink raw reply related
* Re: [PATCH v5 2/3] input: evdev: Replace timeval with timespec64
From: Arnd Bergmann @ 2018-01-02 15:35 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Deepa Dinamani, open list:HID CORE LAYER,
Linux Kernel Mailing List, Peter Hutterer, y2038 Mailman List
In-Reply-To: <20180102064617.zmv6ospfkectaa37@dtor-ws>
On Tue, Jan 2, 2018 at 7:46 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Sun, Dec 17, 2017 at 09:18:43PM -0800, Deepa Dinamani wrote:
>> @@ -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.
Is this important? On each client we only return one of the two
times, and I would guess that you cannot rely on a correlation
between timestamps on different devices, since the boot and real
offsets can change over time.
> Also, why can't we keep using ktime_t internally? It is y2038 safe,
> right?
Correct, but there may also be a performance difference if we get
a lot of events, not sure if that matters.
> 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.
The change in __evdev_queue_syn_dropped still seems useful to me
as ktime_get_*ts64() is a bit more efficient than ktime_get*() followed by
a slow ktime_to_timespec64() or ktime_to_timeval().
For evdev_events(), doing a single ktime_get() followed by a
ktime_to_timespec64/ktime_to_timeval can be faster than three
ktime_get_*ts64 (depending on the hardware clock source), or
it can be slower depending on the CPU and the clocksource
hardware. Again, no idea if this matters at the usual rate of
input events.
I guess dropping the evdev_events() change and replacing it with a
ktime_to_timespec64 change in evdev_pass_values()
would be fine here, it should keep the current performance
behavior and get rid of the timeval.
Arnd
^ permalink raw reply
* Re: [PATCH] platform/x86: silead_dmi: Add entry for the Teclast X98 Plus II
From: Hans de Goede @ 2018-01-02 15:34 UTC (permalink / raw)
To: Paul Cercueil, Darren Hart, Andy Shevchenko
Cc: linux-input, platform-driver-x86, linux-kernel
In-Reply-To: <20180102134239.3579-1-paul@crapouillou.net>
Hi,
On 02-01-18 14:42, Paul Cercueil wrote:
> Add touchscreen platform data for the Teclast X98 Plus II tablet.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Looks good to me:
Acked-by: Hans de Goede <hdegoede@redhat.com>
You should probably send a v2 rebased on top of:
http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/shortlog/refs/heads/review-andy
Which has several additional entries compared to the version you
used as base.
Regards,
Hans
> ---
> drivers/platform/x86/silead_dmi.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/platform/x86/silead_dmi.c b/drivers/platform/x86/silead_dmi.c
> index 266535c2a72f..ebe8692a2868 100644
> --- a/drivers/platform/x86/silead_dmi.c
> +++ b/drivers/platform/x86/silead_dmi.c
> @@ -171,6 +171,22 @@ static const struct silead_ts_dmi_data digma_citi_e200_data = {
> .properties = digma_citi_e200_props,
> };
>
> +static const struct property_entry teclast_x98plus2_props[] = {
> + PROPERTY_ENTRY_U32("touchscreen-size-x", 2048),
> + PROPERTY_ENTRY_U32("touchscreen-size-y", 1280),
> + PROPERTY_ENTRY_BOOL("touchscreen-inverted-x"),
> + PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
> + PROPERTY_ENTRY_STRING("firmware-name",
> + "gsl1686-teclast_x98plus2.fw"),
> + PROPERTY_ENTRY_U32("silead,max-fingers", 10),
> + { }
> +};
> +
> +static const struct silead_ts_dmi_data teclast_x98plus2_data = {
> + .acpi_name = "MSSL1680:00",
> + .properties = teclast_x98plus2_props,
> +};
> +
> static const struct dmi_system_id silead_ts_dmi_table[] = {
> {
> /* CUBE iwork8 Air */
> @@ -271,6 +287,14 @@ static const struct dmi_system_id silead_ts_dmi_table[] = {
> DMI_MATCH(DMI_BOARD_NAME, "Cherry Trail CR"),
> },
> },
> + {
> + /* Teclast X98 Plus II */
> + .driver_data = (void *)&teclast_x98plus2_data,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "TECLAST"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "X98 Plus II"),
> + },
> + },
> { },
> };
>
>
^ permalink raw reply
* Re: [PATCH] Revert "Input: trackpoint - add new trackpoint firmware ID"
From: Aaron Ma @ 2018-01-02 13:57 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Greg KH, Sebastian Schmidt, linux-input
In-Reply-To: <20180102070811.p7gfaq3vr55sdbd3@dtor-ws>
No, it is not a regression of this commit.
ThinkPad X1 Yoga 2nd:
trackpoint (ID: 01)
ThinkPad X1 Yoga 3rd:
trackpoint (ID: 03)
Both laptop's trackpoints have the same behavior.
Writing "speed" of sysfs is failed.
Override the ID and force loading drivers/input/mouse/elantech.c,
it causes too many failure and trackpoint stops work.
The ID of "2.4.18 READ SECONDARY ID (x"E1")" in TrackPoint specification
does not indicate any other vendors but only trackpoint.
Elantech uses 0x03e9.
ALPS uses 0x00e6/0x00e7/0x00ec.
Maybe the windows tool's is wrong like Linux driver before.
^ permalink raw reply
* Re: xps 15 9560 touchpad high interrupts
From: Baruch Siach @ 2018-01-02 13:46 UTC (permalink / raw)
To: Javad Karabi; +Cc: linux-input, linux-i2c
In-Reply-To: <CAEOHGOkWni9J_abVidDgvyQj0ae7UNUOwmfxHWBTTcaNQ7LNAw@mail.gmail.com>
Hi Javad Karabi,
On Mon, Jan 01, 2018 at 05:18:00PM -0600, Javad Karabi wrote:
> On Mon, Jan 1, 2018 at 12:14 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > 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.
>
> 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?
It is not the touchpad that shoots the interrupts. It is the i2c-designware
hardware module.
> 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?
I don't think that the touchpad sensitivity has anything to do with this
interrupts storm.
There is another possibility. The USB hub controller driver might be shooting
i2c transactions at the USB hub. In this case the bug is not in the i2c master
driver.
Can you identify the driver that initiates the i2c transactions?
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH] platform/x86: silead_dmi: Add entry for the Teclast X98 Plus II
From: Paul Cercueil @ 2018-01-02 13:42 UTC (permalink / raw)
To: Hans de Goede, Darren Hart, Andy Shevchenko
Cc: linux-input, platform-driver-x86, linux-kernel, Paul Cercueil
Add touchscreen platform data for the Teclast X98 Plus II tablet.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
drivers/platform/x86/silead_dmi.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/platform/x86/silead_dmi.c b/drivers/platform/x86/silead_dmi.c
index 266535c2a72f..ebe8692a2868 100644
--- a/drivers/platform/x86/silead_dmi.c
+++ b/drivers/platform/x86/silead_dmi.c
@@ -171,6 +171,22 @@ static const struct silead_ts_dmi_data digma_citi_e200_data = {
.properties = digma_citi_e200_props,
};
+static const struct property_entry teclast_x98plus2_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 2048),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1280),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-x"),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+ PROPERTY_ENTRY_STRING("firmware-name",
+ "gsl1686-teclast_x98plus2.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ { }
+};
+
+static const struct silead_ts_dmi_data teclast_x98plus2_data = {
+ .acpi_name = "MSSL1680:00",
+ .properties = teclast_x98plus2_props,
+};
+
static const struct dmi_system_id silead_ts_dmi_table[] = {
{
/* CUBE iwork8 Air */
@@ -271,6 +287,14 @@ static const struct dmi_system_id silead_ts_dmi_table[] = {
DMI_MATCH(DMI_BOARD_NAME, "Cherry Trail CR"),
},
},
+ {
+ /* Teclast X98 Plus II */
+ .driver_data = (void *)&teclast_x98plus2_data,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TECLAST"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X98 Plus II"),
+ },
+ },
{ },
};
--
2.11.0
^ permalink raw reply related
* [PATCH] xen/input: do not advertise multi-touch pressure support
From: Oleksandr Andrushchenko @ 2018-01-02 8:12 UTC (permalink / raw)
To: xen-devel, linux-kernel, linux-input, dmitry.torokhov
Cc: andr2000, Oleksandr Andrushchenko, Andrii Chepurnyi
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Some user-space applications expect multi-touch pressure
on contact to be reported if it is advertised in device
properties. Otherwise, such applications may treat reports
not as actual touches, but hovering. Currently this is
only advertised, but not reported.
Fix this by not advertising that ABS_MT_PRESSURE is supported.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Andrii Chepurnyi <andrii_chepurnyi@epam.com>
---
drivers/input/misc/xen-kbdfront.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index 6bf56bb5f8d9..d91f3b1c5375 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -326,8 +326,6 @@ static int xenkbd_probe(struct xenbus_device *dev,
0, width, 0, 0);
input_set_abs_params(mtouch, ABS_MT_POSITION_Y,
0, height, 0, 0);
- input_set_abs_params(mtouch, ABS_MT_PRESSURE,
- 0, 255, 0, 0);
ret = input_mt_init_slots(mtouch, num_cont, INPUT_MT_DIRECT);
if (ret) {
--
2.7.4
^ permalink raw reply related
* 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
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