* Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
From: AJ Guillon @ 2014-01-20 4:55 UTC (permalink / raw)
To: Vadim Klishko; +Cc: linux-input, Tommy Will
In-Reply-To: <9A2D41DC5C294BAE8568615F106C72F2@HITLER>
Hi Vadim,
I am currently on Kubuntu 12.04 (3.2.0-29-generic), and this device is
not recognized as a touchpad. I have not yet tested a nightly build
with a recent kernel to see if that works.
It is detected and works as a mouse right now, but my understanding is
that if it is recognized as a touchpad I can do more interesting things
with it ;-)
AJ
On 14-01-19 11:41 PM, Vadim Klishko wrote:
> Hello AJ,
>
> I thought it was I who was supposed to be helping. :-)
>
> Can you please describe the problem?
>
> Vadim
>
>
> ----- Original Message -----
> From: "AJ Guillon" <aj.guillon@gmail.com>
> To: "Tommy Will" <tommywill2011@gmail.com>; <vadim@cirque.com>
> Cc: <linux-input@vger.kernel.org>
> Sent: Sunday, January 19, 2014 9:08 PM
> Subject: Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
>
>
> Hi,
>
> Thanks Tommy!
>
> Vadim: Let me know what I can do to help.
>
> AJ
>
> On 14-01-19 08:06 PM, Tommy Will wrote:
>> Hi AJ,
>>
>> Sorry for reply late. I have got the positive reply from my Cirque's
>> colleague and please allow me to introduce Vadim to you.
>> He's now main for S/W development of Cirque's product and he would
>> help you of your "Cirque Smart Cat Pro AG Touchpad".
>>
>> Thanks
>>
>
^ permalink raw reply
* Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
From: Vadim Klishko @ 2014-01-20 4:41 UTC (permalink / raw)
To: AJ Guillon; +Cc: linux-input, Tommy Will
In-Reply-To: <52DCA136.5030207@gmail.com>
Hello AJ,
I thought it was I who was supposed to be helping. :-)
Can you please describe the problem?
Vadim
----- Original Message -----
From: "AJ Guillon" <aj.guillon@gmail.com>
To: "Tommy Will" <tommywill2011@gmail.com>; <vadim@cirque.com>
Cc: <linux-input@vger.kernel.org>
Sent: Sunday, January 19, 2014 9:08 PM
Subject: Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
Hi,
Thanks Tommy!
Vadim: Let me know what I can do to help.
AJ
On 14-01-19 08:06 PM, Tommy Will wrote:
> Hi AJ,
>
> Sorry for reply late. I have got the positive reply from my Cirque's
> colleague and please allow me to introduce Vadim to you.
> He's now main for S/W development of Cirque's product and he would
> help you of your "Cirque Smart Cat Pro AG Touchpad".
>
> Thanks
>
--
This message and any attachment are confidential. It may also be privileged
or otherwise protected by work product immunity or other legal rules. If
you have received it by mistake, please let us know by e-mail reply and
delete it from your system, you may not copy this message or disclose its
contents to anyone.
Cirque Corporation
^ permalink raw reply
* Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
From: AJ Guillon @ 2014-01-20 4:08 UTC (permalink / raw)
To: Tommy Will, vadim; +Cc: linux-input@vger.kernel.org
In-Reply-To: <CA+F6ckP1JHJF0q8HZXKFPf1on8PB+QX6suNmavu8eWT4gSK0rA@mail.gmail.com>
Hi,
Thanks Tommy!
Vadim: Let me know what I can do to help.
AJ
On 14-01-19 08:06 PM, Tommy Will wrote:
> Hi AJ,
>
> Sorry for reply late. I have got the positive reply from my Cirque's
> colleague and please allow me to introduce Vadim to you.
> He's now main for S/W development of Cirque's product and he would
> help you of your "Cirque Smart Cat Pro AG Touchpad".
>
> Thanks
>
^ permalink raw reply
* Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
From: Tommy Will @ 2014-01-20 1:06 UTC (permalink / raw)
To: AJ Guillon, vadim; +Cc: linux-input@vger.kernel.org
In-Reply-To: <CA+F6ckPDkigiy1qKPTXE7Ec1xgj3Jk-fXa-vrpjwd_vJmzU2Yg@mail.gmail.com>
Hi AJ,
Sorry for reply late. I have got the positive reply from my Cirque's
colleague and please allow me to introduce Vadim to you.
He's now main for S/W development of Cirque's product and he would
help you of your "Cirque Smart Cat Pro AG Touchpad".
Thanks
--
Best Regards,
Tommy
2014/1/18 Tommy Will <tommywill2011@gmail.com>:
> Hi AJ,
>
>> Here is the touchpad I bought:
>> http://www.cirque.com/desktoptouchpad/productsandorders/smartcatpro.aspx
>> (the black USB one).
>
> Thanks for your info.
>
>> It works somewhat as a mouse, but isn't recognized as a touchpad.
>>
>> If there is no chance for Linux support, I'll just return it and
>> exchange for a brand that does support Linux. If there is something I
>> can do to help it be supported, I'm happy to do so.
>>
>
> First, so thanks for you'll be happy to try the patch if we can
> provide. However, I'm not
> the manager of Cirque who can decide if we'll support the device.
> I have sent the request mail to my Cirque's colleague and please wait
> my feedback until
> next week. Sorry for the inconvenience!
>
> Thanks
> --
> Best Regards,
> Tommy
>
>> AJ
>>
>> On 14-01-17 11:01 AM, Tommy Will wrote:
>>> Hi AJ,
>>>
>>> This is Tommy from ALPS. From the PCI ID you attached, it looks like
>>> an external USB touchpad (?)
>>> If so, modify alps.c may not let touchpad work since its only for PS/2 device.
>>>
>>> I'm sorry although I work in ALPS, I'm not so familar with the
>>> products made by Cirque.
>>> However, I'll try to ask our Cirque's colleagues if they have schedule
>>> to support their products for Linux mainstring.
>>> Thanks !
>>>
^ permalink raw reply
* Re: Re: [PATCH] Introduce Naming Convention in Input Subsystem
From: Aniroop Mathur @ 2014-01-19 15:19 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Aniroop Mathur, linux-input@vger.kernel.org, cpgs .
In-Reply-To: <20140110214604.GA19779@core.coreip.homeip.net>
Hello Mr.Torokhov
Greetings of the day !!
I have sent you a mail few days back but unfortunately did not
received a mail back.
Thereore, sending mail again.
I hope to hear from you soon.
On Sat, Jan 11, 2014 at 3:16 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Sat, Jan 11, 2014 at 02:55:33AM +0530, Aniroop Mathur wrote:
>> Hello Mr. Torokhov,
>> Greetings!
>>
>> First of all, So sorry, unfortunately i used HTML text again.
>> and Many thanks for all replies.
>>
>> Sending email again in plain text.
>>
>>
>> On Sat, Jan 11, 2014 at 12:41 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > Hi Aniroop,
>> >
>> > On Fri, Jan 10, 2014 at 04:49:43PM +0000, Aniroop Mathur wrote:
>> >> Hello Mr. Torokhov,
>> >> Greetings!
>> >>
>> >> On Thu, Jan 09, 2014 at 10:27:56AM +0530, Aniroop Mathur wrote:
>> >> > This patch allows user(driver) to set sysfs node name of input
>> >> > devices. To set sysfs node name, user(driver) just needs to set
>> >> > node_name_unique variable. If node_name_unique is not set, default
>> >> > name is given(as before). So, this patch is completely
>> >> > backward-compatible.
>> >> >
>> >> > Sysfs Input node name format is: input_
>> >> > Sysfs Event node name format is: event_
>> >> >
>> >> > This "name" is given by user and automatically, prefix(input and
>> >> > event) is added by input core.
>> >> >
>> >> > This name must be unique among all input devices and driver(user) has
>> >> > the responsibility to ensure it. If same name is used again for other
>> >> > input device, registration of that input device will fail because two
>> >> > input devices cannot have same name.
>> >> >
>> >> > Advantages of this patch are:
>> >> >
>> >> > 1. Reduces Booting Time of HAL/Upper-Layer because now HAL or
>> >> > Upper-Layer do not need to search input/event number corresponding to
>> >> > each input device in /dev/input/... This searching in /dev/input/ was
>> >> > taking too much time. (Especially in mobile devices, where there are
>> >> > many input devices (many sensors, touchscreen, etc), it reduces a lot
>> >> > of booting time)
>> >>
>> >> I am sorry, how much time does it take to scan a directory of what, 20
>> >> devices? If it such a factor have udev create nodes that are easier for
>> >> you to locate, similarly how we already create nodes by-id and by-path.
>> >> For example you can encode major:minor in device name.
>> >>
>> >> Re: (Aniroop Mathur)
>> >
>> > First of all, it would be great if you could use MUA that can properly
>> > quote and wrap long lines...
>> >
>> >> Its correct that we can set name of a device node using udev. Yes,
>> >> this will change the name of device node(/dev/...) but not sysfs
>> >> node.(/sys/class/input/...) So now, the problem area will shift from
>> >> dev path to sysfs path, because now we dont know which sysfs node to
>> >> refer for a particular input device and hence HAL/Upper-Layer will
>> >> need to search in /sys/class/input/... instead of /dev/... directory.
>> >
>> > [dtor@dtor-d630 ~]$ mkdir my-sysfs-view
>> > [dtor@dtor-d630 ~]$ ln -s
>> > /sys/devices/platform/i8042/serio1/input/input6
>> > my-sysfs-view/input_touchpad
>> > [dtor@dtor-d630 ~]$ ls my-sysfs-view/input_touchpad/
>> > capabilities/ event6/ modalias name power/
>> > subsystem/ uniq
>> > device/ id/ mouse1/ phys properties
>> > uevent
>> > [dtor@dtor-d630 ~]$ ls my-sysfs-view/input_touchpad/
>> > capabilities device event6 id modalias mouse1 name phys power
>> > properties subsystem uevent uniq
>> > [dtor@dtor-d630 ~]$ ls my-sysfs-view/input_touchpad/event6/
>> > dev device power subsystem uevent
>> >
>> > Mmmmkay?
>> >
>>
>> Yes, agreed, we can use udev and soft links to achieve this.
>> But i think there is something more to take care.
>>
>> So far, as per discussion, i understood that if an end user wants to use
>> node names instead of numbers, he/she has to do the following things:
>
> No, not the end user, system integrator, which is quite different
> beast.
>
Umm.. Sorry, i used wrong word "end user".
I meant to say "system integrator" only all the time.
>> 1. Create rules for all input devices in udev rule file i.e. set atleast
>> unique id and unique name.
>> (end user need to determine unique id too for every input device)
>> 2. Create links for all input device nodes using names.
>> (in probe function, after input_register_device)
>>
>> By following above two steps, the file structure will look like:
>> devfs - /dev/input_proximity
>> sysfs - my-sysfs-view/input_proximity --> sys/class/input/input2
>> sysfs - my-sysfs-view/event_proximity --> sys/class/input/event2
>>
>> But my concern is why to create trouble for end user to perform
>> and spend time for two extra steps, when an easy way is possible
>> to achieve the same task ?
>>
>> With this patch, end user only need to set node_name_unique variable
>> and right after that, both for devfs and sysfs,same node name is set.
>> End user does not need to do or take care of any other extra work,
>> like creating entry in udev rules, creating links, etc
>>
>> Also, with creating links for all input devices and checking udev rules
>> before actually creating a device node, will only increase computation
>> and time in kernel code.
>
> So do not create links, use something else to track devices. You are
> getting uevents, that is all you need.
>
Firstly,
For input device event node, (/input/input1/event1)
we get below 7 uevents only:
Action, Devpath, Subsystem, Major, Minor, Devname, Seqnum
It is impossible to uniquely identify the device using
these 7 uevent variables, because all this is set in
input subsystem and not by driver developer or system integrator.
Devpath, Devname, minor is all set by input subsytem.
So, these uevents are not sufficient to identify the device.
Secondly,
For input device input node (/input/input1),
I know we get more uevents like Name, Phys, etc,
But problem area is not input node because that we can
already do this using dev_set_name(input_dev->dev) or
using init_name variable in driver code.
But evdev (event device) structure is not accessible to driver
so we cannot use the same for this.
Thirdly,
I know if these default uevents are not sufficient,
additionally, we can read sysfs attribute to identify device,
but as i already said, all this(udev rules or links),
will only increase computation time, and my purpose is to save time
and achieving the same task all together.
>>
>> My purpose is to avoid extra work load and directly create node names
>> within input subsystem. Also backward compatibility is there.
>> So i think, it is better than the other alternative way.
>> Isn't this more easy ? Is there any side-effect or drawback of this patch ?
>
> Yes, there is huge side effect - it is maintenance nightmare, where one
> driver can now cause failure for others. What if I have 2 proximity
> sensors? 2 accelerometers? How will generic drivers select names that
> will satisfy all boards that might use the chips out there? Are you
> proposing to put this data in device tree for example? Board files?
>
> IOW no, this is not right solution and the patch will not be accepted.
>
Firstly,
Yes, i will put name of all input devices in one place i.e.
in board file or device tree. With this, it is very easy for system
integrator to assign unique names for all input devices.
Secondly,
As already mentioned, this patch is backward compatible.
It is not compulsory to use node_name_unique variable.
So generic drivers can still use the same numbering system.
Also, if there are two accelerometers, system integrator can
easily give "accelerometer1" and "accelerometer2" as names.
Moreover, this same problem is for existing kernel system also.
As you know, using dev_set_name function or init_name variable,
we can set name of input node(not event node). So, if same name
is used, device_add of that input device will fail here also
in existing kernel code.
Thirdly,
Using the existing init_name variable also, we can add naming convention
in input subystem. I can also submit patch using this variable already present
in kernel. shall i ?
>>
>> >>
>> >> Moreover, as i know, udev is mainly for hot-pluggable devices, but my
>> >> problem is for platform devices, which are already present on the
>> >> board during boot up. (Like in Embedded devices)
>> >
>> > No, udev also manages those by requesting to replay all events that
>> > happened dyuring boot.
>> >
>> >>
>> >> To avoid confusion and make the problem more clear,
>> >> I would like to explain the problem and my suggestion by taking an example:
>> >>
>> >> Suppose in a mobile device, there are 10 embedded input devices as below:
>> >> Proximity --- /dev/input0 --- /sys/class/input/input0 --- /sys/class/input/event0
>> >> Magnetometer --- /dev/input1 --- /sys/class/input/input1 --- /sys/class/input/event1
>> >> Accelerometer --- /dev/input2 --- /sys/class/input/input2 --- /sys/class/input/event2
>> >> Touchscreen --- /dev/input3 --- /sys/class/input/input3 --- /sys/class/input/event3
>> >> ... 6 more like this
>> >> (All these are created during boot up time)
>> >>
>> >> Kernel has created all these nodes, so that HAL/UpperLayer can read or
>> >> write values from it. HAL/Upper-Layer needs to do main tasks like:
>> >> 1. Read raw data - does through /dev/input<num>
>> >> 2. Enable device - does through sys/class/input<num>/enable
>> >> 3. Set delay - does through sys/class/input<num>/delay
>> >> and many more...
>> >>
>> >> Now, Lets suppose we need to do these tasks for Accelerometer.
>> >>
>> >> If dev node name is set, HAL can directly read value from it (no
>> >> search required) But for enabling the accelerometer device or set the
>> >> delay of a hardware chip, there is no direct way, HAL can know which
>> >> input node to refer for accelerometer because the input number is
>> >> created dynamically as per device probe order, so this input number
>> >> can be anything (0,1,2,3...) So HAL will need to search every input
>> >> node and read its name attribute and keep on searching until a match
>> >> is found between the "attribute name" and "name passed as parameter".
>> >> Like for accelerometer, this searching needs to be done for all other
>> >> input devices. All of this part is done during booting and this takes
>> >> a lot for time from booting perspective.
>> >>
>> >
>> > See the above. You can very easily create your own private 'view' of
>> > sysfs, no kernel changes needed.
>> >
>> >> As I measured, if there are ten devices, it is taking 1 second to do
>> >> all this searching. (for all devices) So for 20 devices, i guess, it
>> >> could take upto 2 seconds.
>> >
>> > That seems _very_ high, maybe you need to profile your code a bit. To
>> > search though 2 directories with less than a hundred files each should
>> > not take 1 second.
>> >
>>
>> In this i am including time to open a directory, close a directory, open file of
>> that directory, close file of that directory, searching and computation part.
>> Including all these, every time for each input device.
>> All this sums upto 1 second.
>
> Why are you doing it one at at time? It appears that this happens in
> build at boot up for you...
>
Yes, this happenns at boot up of upper-layer.
Just as in kernel, probe of each device is
called by one by one, in upper-layer too, input device initialization
is done one by one in some order and input device number is searched.
So this is done every time.
Moreover, with naming convention, scanning is totally removed.
No need to scan/search even once.
>>
>> >>
>> >> With naming convention, there is no need of search neither for dev
>> >> path nor for sysfs path because HAL directly know which node to refer
>> >> for which input device and hence this 1 second is reduced to 10ms or
>> >> even less, therefore saving 990ms. I believe, this is a very good
>> >> time saving. (from device booting perspective)
>> >
>> > OK, so create your own sysfs view and use it to do direct lookups.
>> >
>> >>
>> >> (Is there any direct way, without scanning all nodes for every input
>> >> device ?)
>> >>
>> >> >
>> >> > 2. Improves Readabilty of input and event sysfs node paths because
>> >> > names are used instead of numbers.
>> >>
>> >> I do not see why it is that important. If one wants overview
>> >> /proc/bus/input/devices gives nice picture.
>> >>
>> >> Re: (Aniroop Mathur)
>> >> Its correct, we can get an overview from /proc/bus/input/devices.
>> >> And therefore using this, we can know input node number for every input device.
>> >> But there are many input devices and input numbers are not fixed,
>> >> so its quite difficult to memorize input number for all input devices.
>> >> Therefore, if a user needs to open some input node from sysfs path,
>> >> he needs to check /proc/bus/input/devices before opening because
>> >> he does not know the input number. Moreover, this applies for all other
>> >> input devices and hence a user need to check this every time.
>> >>
>> >> It improves readabilty as below
>> >>
>> >> Before: After patch:
>> >> /dev/input0 /dev/input_proximity
>> >> /dev/input1 /dev/input_accelerometer
>> >> ...many more
>> >>
>> >> /sys/class/input/input0 /sys/class/input/input_proximity
>> >> /sys/class/input/input1 /sys/class/input/input_accelerometer
>> >> ...many more
>> >>
>> >> /sys/class/input/event0 /sys/class/input/event_proximity
>> >> /sys/class/input/event1 /sys/class/input/event_accelerometer
>> >> ...many more
>> >>
>> >> So, just by looking, user can directly open or refer any input node.
>> >> (no need to refer any other path)
>> >
>> > User as in end user or your HAL layer?
>> >
>>
>> End user.
>
> Why would end user care? He wants his touchscreen to work, not fiddle
> with its settings, And we aleady discussed what system integrator should
> do.
>
Yeah, i meant system integrator only.
Sorry, not end user (i used wrong term).
System integrator or code developer cares for this.
>>
>> >>
>> >> >
>> >> > 3. Removes Input Devices Dependency. If one input device probe fails,
>> >> > other input devices still work. Before this patch, if one input
>> >> > device probe fails before input_register_device, then input number of
>> >> > other input devices changes and due to this permission settings are
>> >> > disturbed and hence HAL or upper layer cannot open the required sysfs
>> >> > node because permission denied error comes.
>> >>
>> >> I have only one suggestion here: fix your userspace so that does not
>> >> depend on device initialization ordering.
>> >>
>> >> Re: (Aniroop Mathur)
>> >> We cannot fix userspace because these input/event/dev number are
>> >> decided/allocated in kernel as per device initialization ordering
>> >> during boot up. (userspace has no role in it) So, userspace is not
>> >> aware, which exact input number corresponds to which input device so
>> >> it ends up searching/scanning every input node untill a match is
>> >> found.
>> >>
>> >> So, there is input device dependency which needs to be removed.
>> >
>> > Do not use numbers. We emit uevents describing the devices and there a
>> > _lot_ of data there that helps identifying device, such as its path,
>> > subsystem, name, etc.
>> >
>>
>> Sorry, I am not able to understand this point with respect to removing input
>> device dependency. Please elaborate a bit more.
>
> Look at the data that is passed in uevents that are sent either when new
> input device is created, or when you request replay of such evenst,
> realize that it is enough to identify the device and stop relying on
> inputX names to remain static. That's it.
>
> Thanks.
>
> --
> Dmitry
As already mentioned above, the default uevents are not sufficient to
uniquely identify the input device. Can it ?
Thanks and have a nice day,
Aniroop Mathur
^ permalink raw reply
* [PATCH] USB: input: gtco.c: fix usb_dev leak
From: Alexey Khoroshilov @ 2014-01-18 23:24 UTC (permalink / raw)
To: Dmitry Torokhov, Greg Kroah-Hartman
Cc: Alexey Khoroshilov, linux-input, linux-kernel, ldv-project
There is usb_get_dev() in gtco_probe(), but there is no usb_put_dev()
anywhere in the driver.
The patch adds usb_get_dev() to failure handling code of gtco_probe()
and to gtco_disconnect(().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
drivers/input/tablet/gtco.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
index 29e01ab6859f..6ec8a3a04672 100644
--- a/drivers/input/tablet/gtco.c
+++ b/drivers/input/tablet/gtco.c
@@ -858,7 +858,7 @@ static int gtco_probe(struct usb_interface *usbinterface,
if (!gtco->buffer) {
dev_err(&usbinterface->dev, "No more memory for us buffers\n");
error = -ENOMEM;
- goto err_free_devs;
+ goto err_put_usb;
}
/* Allocate URB for reports */
@@ -990,6 +990,8 @@ static int gtco_probe(struct usb_interface *usbinterface,
err_free_buf:
usb_free_coherent(gtco->usbdev, REPORT_MAX_SIZE,
gtco->buffer, gtco->buf_dma);
+ err_put_usb:
+ usb_put_dev(gtco->usbdev);
err_free_devs:
input_free_device(input_dev);
kfree(gtco);
@@ -1013,6 +1015,7 @@ static void gtco_disconnect(struct usb_interface *interface)
usb_free_urb(gtco->urbinfo);
usb_free_coherent(gtco->usbdev, REPORT_MAX_SIZE,
gtco->buffer, gtco->buf_dma);
+ usb_put_dev(gtco->usbdev);
kfree(gtco);
}
--
1.8.3.2
^ permalink raw reply related
* You've won
From: Chevrolet UK @ 2014-01-18 19:32 UTC (permalink / raw)
You've won 1,000,000 GBP from Chevrolet UK. To claim prize, reply to: claims@chevrolet-online.uk.com +447024044421
^ permalink raw reply
* Re: New ALPS not detected EC=88 b6 06 - Lenovo Ideapad Flex 15D
From: Tommy Will @ 2014-01-18 12:45 UTC (permalink / raw)
To: Omar Loggiodice; +Cc: linux-input@vger.kernel.org, Elaine Chen, Qiting Chen
In-Reply-To: <1390022292.30501.YahooMailNeo@web162402.mail.bf1.yahoo.com>
Hi Omar,
I'm glad to hear this good news and also thanks for your trying with
our patch : )
Thanks
--
Best Regards,
Tommy
2014/1/18 Omar Loggiodice <ologgio@yahoo.com>:
> The patch works very well! I now need to adjust the settings. I wanted to let you know two
> finger middle button works, along with two finger scrolling, circular
> scrolling, edge scrolling, right button, etc. Everything is working.
>
>
> Thank you all for the good work you do for the linux community.
>
>
>
>
>
> On Friday, January 17, 2014 9:49 PM, Tommy Will <tommywill2011@gmail.com> wrote:
> Hi Omar,
>
> Thanks for your mail. This is Tommy from ALPS.
> According to your info "E7=73 03 0a, EC=88 b6 06", I think you're now
> using ALPS_PROTO_V7 device.
> My colleague Elaine(Qiting) is now working with this touchpad's
> support and has released a patch last week.
> You can have a try ~
>
> http://www.spinics.net/lists/linux-input/msg29084.html
>
> If you find any issue or have any suggestion, please kindly let us
> know. We'll try our best to make the driver better.
>
> Thanks!
>
> --
> Best Regards,
> Tommy
>
>
> 2014/1/18 Omar Loggiodice <ologgio@yahoo.com>:
>> Hi,
>>
>>
>> First, thank you for your excellent work. I recently bought a new Lenovo Ideapad Flex 15D, it comes with Windows 8.1.
>>
>> I have been able to run linux, however the ALPS touchpad is only recognized as a PS/2 mouse. I also have some problems with the screen
>> turning off and the GPU stalling, but this is outside of the scope of
>> this list. This is what dmesg shows for the touchpad:
>>
>> psmouse serio1: alps: Unknown ALPS touchpad: E7=73 03 0a, EC=88 b6 06
>>
>> I hacked alps.c with the following code in alps_identify(...):
>>
>> [...]
>>
>> } else if (ec[0] == 0x88 && ec[1] == 0xb6 &&
>> ec[2] == 0x06 )
>> {
>> priv->proto_version = ALPS_PROTO_V5;
>> alps_set_defaults(priv);
>>
>> return 0;
>> }
>> [...]
>>
>> With this code the module seems to recognize the card and dmesg reports the following:
>>
>> [ 791.663876] input: PS/2 Mouse as /devices/platform/i8042/serio1/input/input22
>> [ 791.692023] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input21
>>
>>
>> However, the touchpad still operates only as a PS/2 mouse (no scroll, no middle
>> button emulation, no touch gestures) even if I disable the PS/2 mouse
>> with xinput.
>>
>> any help would be appreciated, I am willing to test patches if you send them to me.
>>
>> Thanks!
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-input" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v3] input/uinput: add UI_GET_SYSNAME ioctl to retrieve the sysfs path
From: David Herrmann @ 2014-01-18 10:51 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Benjamin Tissoires, Dmitry Torokhov, Peter Hutterer,
open list:HID CORE LAYER, linux-kernel
In-Reply-To: <1389985971-541-1-git-send-email-benjamin.tissoires@redhat.com>
Hi
On Fri, Jan 17, 2014 at 8:12 PM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
> Evemu [1] uses uinput to replay devices traces it has recorded. However,
> the way evemu uses uinput is slightly different from how uinput is
> supposed to be used.
> Evemu relies on libevdev, which creates the device node through uinput.
> It then injects events through the input device node directly (and it
> completely skips the uinput node).
>
> Currently, libevdev relies on an heuristic to guess which input node was
> created. The problem is that is heuristic is subjected to races between
> different uinput devices or even with physical devices. Having a way
> to retrieve the sysfs path allows us to find the event node without
> having to rely on this heuristic.
>
> [1] http://www.freedesktop.org/wiki/Evemu/
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
>
> Ok, I am resurrecting this. The original patch was sent last July here:
> https://patchwork.kernel.org/patch/2827524/
>
> changes since v2:
> - the ioctl returns only the device name, thus I renamed the ioctl to UI_GET_SYSNAME
> - reordered uinput_str_to_user() arguments
> - be sure to terminate the user string we send by \0
> - abort if udev->state is not UIST_CREATED
> - dropped the patch 1/2 (adding resolution to uinput) because I think David has
> already it in one of his queues (ABS2 IIRC)
>
> I also posted the corresponding libevdev here:
> http://lists.freedesktop.org/archives/input-tools/2014-January/000757.html
>
> Cheers,
> Benjamin
>
> drivers/input/misc/uinput.c | 46 ++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/uinput.h | 2 ++
> include/uapi/linux/uinput.h | 13 ++++++++++++-
> 3 files changed, 59 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index 7728359..0203219 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -20,6 +20,8 @@
> * Author: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
> *
> * Changes/Revisions:
> + * 0.4 01/09/2014 (Benjamin Tissoires <benjamin.tissoires@redhat.com>)
> + * - add UI_GET_SYSNAME ioctl
> * 0.3 09/04/2006 (Anssi Hannula <anssi.hannula@gmail.com>)
> * - updated ff support for the changes in kernel interface
> * - added MODULE_VERSION
> @@ -670,6 +672,27 @@ static int uinput_ff_upload_from_user(const char __user *buffer,
> __ret; \
> })
>
> +static int uinput_str_to_user(void __user *dest, const char *str,
> + unsigned int maxlen)
> +{
> + int len, ret;
> +
> + if (!str)
> + return -ENOENT;
> +
> + len = strlen(str) + 1;
> + if (len > maxlen)
> + len = maxlen;
> +
> + ret = copy_to_user(dest, str, len);
> + if (ret)
> + return -EFAULT;
> +
> + /* force terminating '\0' */
> + ret = copy_to_user(dest + len - 1, "\0", 1);
You must make sure "maxlen != 0", otherwise you write beyond buffer
boundaries here. I'd say return -EINVAL in case maxlen == 0.
btw., you can also use: put_user(0, (char*)dest + len - 1);
> + return ret ? -EFAULT : len;
> +}
> +
> static long uinput_ioctl_handler(struct file *file, unsigned int cmd,
> unsigned long arg, void __user *p)
> {
> @@ -679,6 +702,8 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd,
> struct uinput_ff_erase ff_erase;
> struct uinput_request *req;
> char *phys;
> + const char *name;
> + unsigned int size;
>
> retval = mutex_lock_interruptible(&udev->mutex);
> if (retval)
> @@ -831,7 +856,26 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd,
> break;
>
> default:
> - retval = -EINVAL;
> + retval = -EAGAIN;
> + }
> +
> + if (retval == -EAGAIN) {
Ehh, in case another ioctl returns -EAGAIN, we overwrite the error
with -EINVAL below in the "default:" clause. Maybe we should first
convert all the "break;" commands to "goto out;".
Patch looks good to me.
Thanks
David
> + size = _IOC_SIZE(cmd);
> +
> + /* Now check variable-length commands */
> + switch (cmd & ~IOCSIZE_MASK) {
> + case UI_GET_SYSNAME(0):
> + if (udev->state != UIST_CREATED) {
> + retval = -ENOENT;
> + goto out;
> + }
> + name = dev_name(&udev->dev->dev);
> + retval = uinput_str_to_user(p, name, size);
> + break;
> +
> + default:
> + retval = -EINVAL;
> + }
> }
>
> out:
> diff --git a/include/linux/uinput.h b/include/linux/uinput.h
> index 0a4487d..0994c0d 100644
> --- a/include/linux/uinput.h
> +++ b/include/linux/uinput.h
> @@ -20,6 +20,8 @@
> * Author: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
> *
> * Changes/Revisions:
> + * 0.4 01/09/2014 (Benjamin Tissoires <benjamin.tissoires@redhat.com>)
> + * - add UI_GET_SYSNAME ioctl
> * 0.3 24/05/2006 (Anssi Hannula <anssi.hannulagmail.com>)
> * - update ff support for the changes in kernel interface
> * - add UINPUT_VERSION
> diff --git a/include/uapi/linux/uinput.h b/include/uapi/linux/uinput.h
> index fe46431..0389b48 100644
> --- a/include/uapi/linux/uinput.h
> +++ b/include/uapi/linux/uinput.h
> @@ -20,6 +20,8 @@
> * Author: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
> *
> * Changes/Revisions:
> + * 0.4 01/09/2014 (Benjamin Tissoires <benjamin.tissoires@redhat.com>)
> + * - add UI_GET_SYSNAME ioctl
> * 0.3 24/05/2006 (Anssi Hannula <anssi.hannulagmail.com>)
> * - update ff support for the changes in kernel interface
> * - add UINPUT_VERSION
> @@ -35,7 +37,7 @@
> #include <linux/types.h>
> #include <linux/input.h>
>
> -#define UINPUT_VERSION 3
> +#define UINPUT_VERSION 4
>
>
> struct uinput_ff_upload {
> @@ -73,6 +75,15 @@ struct uinput_ff_erase {
> #define UI_BEGIN_FF_ERASE _IOWR(UINPUT_IOCTL_BASE, 202, struct uinput_ff_erase)
> #define UI_END_FF_ERASE _IOW(UINPUT_IOCTL_BASE, 203, struct uinput_ff_erase)
>
> +/**
> + * UI_GET_SYSNAME - get the sysfs name of the created uinput device
> + *
> + * @return the sysfs name of the created virtual input device.
> + * The complete sysfs path is then /sys/devices/virtual/input/--NAME--
> + * Usually, it is in the form "inputN"
> + */
> +#define UI_GET_SYSNAME(len) _IOC(_IOC_READ, UINPUT_IOCTL_BASE, 300, len)
> +
> /*
> * To write a force-feedback-capable driver, the upload_effect
> * and erase_effect callbacks in input_dev must be implemented.
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH v2] HID: sony: Cache the output report for the Dualshock 4
From: David Herrmann @ 2014-01-18 10:32 UTC (permalink / raw)
To: Frank Praznik; +Cc: open list:HID CORE LAYER, Jiri Kosina
In-Reply-To: <alpine.DEB.2.10.1401171443040.3454@franz-virtual-machine>
Hi
On Fri, Jan 17, 2014 at 8:46 PM, Frank Praznik <frank.praznik@oh.rr.com> wrote:
> Retrieve and cache the output report for the Dualshock 4 in sony_probe()
> instead of repeatedly walking the report list in the worker function.
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Thanks
David
> Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
>
> ---
>
> Apply against jikos/hid.git/for-3.14/sony
>
> drivers/hid/hid-sony.c | 55 ++++++++++++++++++++++++++++++++------------------
> 1 file changed, 35 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
> index edffe2c..277da77 100644
> --- a/drivers/hid/hid-sony.c
> +++ b/drivers/hid/hid-sony.c
> @@ -298,6 +298,7 @@ static const unsigned int buzz_keymap[] = {
> struct sony_sc {
> struct hid_device *hdev;
> struct led_classdev *leds[MAX_LEDS];
> + struct hid_report *output_report;
> unsigned long quirks;
> struct work_struct state_worker;
>
> @@ -743,26 +744,9 @@ static void dualshock4_state_worker(struct work_struct *work)
> {
> struct sony_sc *sc = container_of(work, struct sony_sc, state_worker);
> struct hid_device *hdev = sc->hdev;
> - struct list_head *head, *list;
> - struct hid_report *report;
> - __s32 *value;
> -
> - list = &hdev->report_enum[HID_OUTPUT_REPORT].report_list;
> -
> - list_for_each(head, list) {
> - report = list_entry(head, struct hid_report, list);
> -
> - /* Report 5 is used to send data to the controller via USB */
> - if ((sc->quirks & DUALSHOCK4_CONTROLLER_USB) && report->id == 5)
> - break;
> - }
> -
> - if (head == list) {
> - hid_err(hdev, "Dualshock 4 output report not found\n");
> - return;
> - }
> + struct hid_report *report = sc->output_report;
> + __s32 *value = report->field[0]->value;
>
> - value = report->field[0]->value;
> value[0] = 0x03;
>
> #ifdef CONFIG_SONY_FF
> @@ -822,6 +806,33 @@ static void sony_destroy_ff(struct hid_device *hdev)
> }
> #endif
>
> +static int sony_set_output_report(struct sony_sc *sc, int req_id, int req_size)
> +{
> + struct list_head *head, *list;
> + struct hid_report *report;
> + struct hid_device *hdev = sc->hdev;
> +
> + list = &hdev->report_enum[HID_OUTPUT_REPORT].report_list;
> +
> + list_for_each(head, list) {
> + report = list_entry(head, struct hid_report, list);
> +
> + if (report->id == req_id) {
> + if (report->size < req_size) {
> + hid_err(hdev, "Output report 0x%02x (%i bits) is smaller than requested size (%i bits)\n",
> + req_id, report->size, req_size);
> + return -EINVAL;
> + }
> + sc->output_report = report;
> + return 0;
> + }
> + }
> +
> + hid_err(hdev, "Unable to locate output report 0x%02x\n", req_id);
> +
> + return -EINVAL;
> +}
> +
> static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
> {
> int ret;
> @@ -866,7 +877,11 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
> else if (sc->quirks & SIXAXIS_CONTROLLER_BT)
> ret = sixaxis_set_operational_bt(hdev);
> else if (sc->quirks & DUALSHOCK4_CONTROLLER_USB) {
> - ret = 0;
> + /* Report 5 (31 bytes) is used to send data to the controller via USB */
> + ret = sony_set_output_report(sc, 0x05, 248);
> + if (ret < 0)
> + goto err_stop;
> +
> INIT_WORK(&sc->state_worker, dualshock4_state_worker);
> } else {
> ret = 0;
> --
> 1.8.3.2
>
^ permalink raw reply
* Re: [PATCH 1/3] input: appletouch: parametrize and set saner defaults for fuzz and threshold
From: Henrik Rydberg @ 2014-01-18 7:07 UTC (permalink / raw)
To: Clinton Sprain, linux-input; +Cc: Dmitry Torokhov
In-Reply-To: <52D9DF09.9090709@gmail.com>
Hi Clinton,
> Dials back the default fuzz and threshold settings for
> most devices using this driver, based on values from
> user feedback from forums and bug reports. This
> increases smoothness and movement granularity. No
> changes were made for the older devices that use the
> driver, as I did not find any user feedback for them
> regarding these settings; however, the two settings can
> also now both be specified as module parameters in case
> there is a desire to change the values for devices that
> do not have new defaults.
>
> There are also a couple of style cleanups per checkpatch.pl.
>
> Signed-off-by: Clinton Sprain <clintonsprain@gmail.com>
> ---
> drivers/input/mouse/appletouch.c | 66 ++++++++++++++++++++++++--------------
> 1 file changed, 42 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/input/mouse/appletouch.c b/drivers/input/mouse/appletouch.c
> index e42f1fa..f5a16ee 100644
> --- a/drivers/input/mouse/appletouch.c
> +++ b/drivers/input/mouse/appletouch.c
> @@ -43,12 +43,14 @@
> */
> struct atp_info {
> int xsensors; /* number of X sensors */
> - int xsensors_17; /* 17" models have more sensors */
> + int xsensors_17; /* 17" model has more sensors */
> int ysensors; /* number of Y sensors */
> int xfact; /* X multiplication factor */
> int yfact; /* Y multiplication factor */
> int datalen; /* size of USB transfers */
> void (*callback)(struct urb *); /* callback function */
> + int fuzz; /* fuzz touchpad generates */
> + int threshold; /* sensitivity threshold */
> };
>
> static void atp_complete_geyser_1_2(struct urb *urb);
> @@ -62,6 +64,8 @@ static const struct atp_info fountain_info = {
> .yfact = 43,
> .datalen = 81,
> .callback = atp_complete_geyser_1_2,
> + .fuzz = 16,
> + .threshold = 5,
> };
>
> static const struct atp_info geyser1_info = {
> @@ -72,6 +76,8 @@ static const struct atp_info geyser1_info = {
> .yfact = 43,
> .datalen = 81,
> .callback = atp_complete_geyser_1_2,
> + .fuzz = 16,
> + .threshold = 5,
> };
>
> static const struct atp_info geyser2_info = {
> @@ -82,6 +88,8 @@ static const struct atp_info geyser2_info = {
> .yfact = 43,
> .datalen = 64,
> .callback = atp_complete_geyser_1_2,
> + .fuzz = 0,
> + .threshold = 3,
> };
>
> static const struct atp_info geyser3_info = {
> @@ -91,6 +99,8 @@ static const struct atp_info geyser3_info = {
> .yfact = 64,
> .datalen = 64,
> .callback = atp_complete_geyser_3_4,
> + .fuzz = 0,
> + .threshold = 3,
> };
>
> static const struct atp_info geyser4_info = {
> @@ -100,6 +110,8 @@ static const struct atp_info geyser4_info = {
> .yfact = 64,
> .datalen = 64,
> .callback = atp_complete_geyser_3_4,
> + .fuzz = 0,
> + .threshold = 3,
> };
>
> #define ATP_DEVICE(prod, info) \
> @@ -156,18 +168,9 @@ MODULE_DEVICE_TABLE(usb, atp_table);
> #define ATP_XSENSORS 26
> #define ATP_YSENSORS 16
>
> -/* amount of fuzz this touchpad generates */
> -#define ATP_FUZZ 16
> -
> /* maximum pressure this driver will report */
> #define ATP_PRESSURE 300
>
> -/*
> - * Threshold for the touchpad sensors. Any change less than ATP_THRESHOLD is
> - * ignored.
> - */
> -#define ATP_THRESHOLD 5
> -
> /* Geyser initialization constants */
> #define ATP_GEYSER_MODE_READ_REQUEST_ID 1
> #define ATP_GEYSER_MODE_WRITE_REQUEST_ID 9
> @@ -213,14 +216,16 @@ struct atp {
> struct work_struct work;
> };
>
> -#define dbg_dump(msg, tab) \
> +#define dbg_dump(msg, tab) \
> +{ \
> if (debug > 1) { \
> int __i; \
> printk(KERN_DEBUG "appletouch: %s", msg); \
> for (__i = 0; __i < ATP_XSENSORS + ATP_YSENSORS; __i++) \
> printk(" %02x", tab[__i]); \
> printk("\n"); \
> - }
> + } \
> +}
Looks like the patch needs cleaning.
>
> #define dprintk(format, a...) \
> do { \
> @@ -236,14 +241,20 @@ MODULE_AUTHOR("Sven Anders");
> MODULE_DESCRIPTION("Apple PowerBook and MacBook USB touchpad driver");
> MODULE_LICENSE("GPL");
>
> -/*
> - * Make the threshold a module parameter
> - */
> -static int threshold = ATP_THRESHOLD;
> +static int threshold = -1;
> module_param(threshold, int, 0644);
> MODULE_PARM_DESC(threshold, "Discard any change in data from a sensor"
> " (the trackpad has many of these sensors)"
> - " less than this value.");
> + " less than this value. Devices have defaults;"
> + " this parameter overrides them.");
> +static int fuzz = -1;
> +
> +module_param(fuzz, int, 0644);
> +MODULE_PARM_DESC(fuzz, "Fuzz the trackpad generates. The higher"
> + " this is, the less sensitive the trackpad"
> + " will feel, but values too low may generate"
> + " random movement. Devices have defaults;"
> + " this parameter overrides them.");
The fuzz can be modified via the input subsystem ioctls (EVIOCSABS), so no need
to add a parameter here.
> static int debug;
> module_param(debug, int, 0644);
> @@ -363,7 +374,8 @@ static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
> (!is_increasing && xy_sensors[i - 1] < xy_sensors[i])) {
> (*fingers)++;
> is_increasing = 1;
> - } else if (i > 0 && (xy_sensors[i - 1] - xy_sensors[i] > threshold)) {
> + } else if (i > 0 && (xy_sensors[i - 1] -
> + xy_sensors[i] > threshold)) {
> is_increasing = 0;
> }
More noise, please clean the patchset.
> @@ -456,7 +468,7 @@ static void atp_detect_size(struct atp *dev)
> input_set_abs_params(dev->input, ABS_X, 0,
> (dev->info->xsensors_17 - 1) *
> dev->info->xfact - 1,
> - ATP_FUZZ, 0);
> + fuzz, 0);
where is this variable defined?
> break;
> }
> }
> @@ -513,7 +525,8 @@ static void atp_complete_geyser_1_2(struct urb *urb)
>
> /* Y values */
> dev->xy_cur[ATP_XSENSORS + i] = dev->data[5 * i + 1];
> - dev->xy_cur[ATP_XSENSORS + i + 8] = dev->data[5 * i + 3];
> + dev->xy_cur[ATP_XSENSORS + i + 8] =
> + dev->data[5 * i + 3];
> }
> }
>
> @@ -809,12 +822,17 @@ static int atp_probe(struct usb_interface *iface,
> dev->info = info;
> dev->overflow_warned = false;
>
> + if (fuzz < 0)
> + fuzz = dev->info->fuzz;
> + if (threshold < 0)
> + threshold = dev->info->threshold;
> +
> dev->urb = usb_alloc_urb(0, GFP_KERNEL);
> if (!dev->urb)
> goto err_free_devs;
>
> - dev->data = usb_alloc_coherent(dev->udev, dev->info->datalen, GFP_KERNEL,
> - &dev->urb->transfer_dma);
> + dev->data = usb_alloc_coherent(dev->udev, dev->info->datalen,
> + GFP_KERNEL, &dev->urb->transfer_dma);
> if (!dev->data)
> goto err_free_urb;
>
> @@ -844,10 +862,10 @@ static int atp_probe(struct usb_interface *iface,
>
> input_set_abs_params(input_dev, ABS_X, 0,
> (dev->info->xsensors - 1) * dev->info->xfact - 1,
> - ATP_FUZZ, 0);
> + fuzz, 0);
> input_set_abs_params(input_dev, ABS_Y, 0,
> (dev->info->ysensors - 1) * dev->info->yfact - 1,
> - ATP_FUZZ, 0);
> + fuzz, 0);
> input_set_abs_params(input_dev, ABS_PRESSURE, 0, ATP_PRESSURE, 0, 0);
>
> set_bit(EV_KEY, input_dev->evbit);
>
Thanks,
Henrik
^ permalink raw reply
* Re: New ALPS not detected EC=88 b6 06 - Lenovo Ideapad Flex 15D
From: Omar Loggiodice @ 2014-01-18 5:18 UTC (permalink / raw)
To: Tommy Will; +Cc: linux-input@vger.kernel.org, Elaine Chen, Qiting Chen
In-Reply-To: <CA+F6ckMtidbKYONs=cFLvhqePwWhg14UDRCxVZ+8eTa_8P2hAA@mail.gmail.com>
The patch works very well! I now need to adjust the settings. I wanted to let you know two
finger middle button works, along with two finger scrolling, circular
scrolling, edge scrolling, right button, etc. Everything is working.
Thank you all for the good work you do for the linux community.
On Friday, January 17, 2014 9:49 PM, Tommy Will <tommywill2011@gmail.com> wrote:
Hi Omar,
Thanks for your mail. This is Tommy from ALPS.
According to your info "E7=73 03 0a, EC=88 b6 06", I think you're now
using ALPS_PROTO_V7 device.
My colleague Elaine(Qiting) is now working with this touchpad's
support and has released a patch last week.
You can have a try ~
http://www.spinics.net/lists/linux-input/msg29084.html
If you find any issue or have any suggestion, please kindly let us
know. We'll try our best to make the driver better.
Thanks!
--
Best Regards,
Tommy
2014/1/18 Omar Loggiodice <ologgio@yahoo.com>:
> Hi,
>
>
> First, thank you for your excellent work. I recently bought a new Lenovo Ideapad Flex 15D, it comes with Windows 8.1.
>
> I have been able to run linux, however the ALPS touchpad is only recognized as a PS/2 mouse. I also have some problems with the screen
> turning off and the GPU stalling, but this is outside of the scope of
> this list. This is what dmesg shows for the touchpad:
>
> psmouse serio1: alps: Unknown ALPS touchpad: E7=73 03 0a, EC=88 b6 06
>
> I hacked alps.c with the following code in alps_identify(...):
>
> [...]
>
> } else if (ec[0] == 0x88 && ec[1] == 0xb6 &&
> ec[2] == 0x06 )
> {
> priv->proto_version = ALPS_PROTO_V5;
> alps_set_defaults(priv);
>
> return 0;
> }
> [...]
>
> With this code the module seems to recognize the card and dmesg reports the following:
>
> [ 791.663876] input: PS/2 Mouse as /devices/platform/i8042/serio1/input/input22
> [ 791.692023] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input21
>
>
> However, the touchpad still operates only as a PS/2 mouse (no scroll, no middle
> button emulation, no touch gestures) even if I disable the PS/2 mouse
> with xinput.
>
> any help would be appreciated, I am willing to test patches if you send them to me.
>
> Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: New ALPS not detected EC=88 b6 06 - Lenovo Ideapad Flex 15D
From: Tommy Will @ 2014-01-18 2:48 UTC (permalink / raw)
To: Omar Loggiodice; +Cc: linux-input@vger.kernel.org, Elaine Chen, Qiting Chen
In-Reply-To: <1390003610.16861.YahooMailNeo@web162404.mail.bf1.yahoo.com>
Hi Omar,
Thanks for your mail. This is Tommy from ALPS.
According to your info "E7=73 03 0a, EC=88 b6 06", I think you're now
using ALPS_PROTO_V7 device.
My colleague Elaine(Qiting) is now working with this touchpad's
support and has released a patch last week.
You can have a try ~
http://www.spinics.net/lists/linux-input/msg29084.html
If you find any issue or have any suggestion, please kindly let us
know. We'll try our best to make the driver better.
Thanks!
--
Best Regards,
Tommy
2014/1/18 Omar Loggiodice <ologgio@yahoo.com>:
> Hi,
>
>
> First, thank you for your excellent work. I recently bought a new Lenovo Ideapad Flex 15D, it comes with Windows 8.1.
>
> I have been able to run linux, however the ALPS touchpad is only recognized as a PS/2 mouse. I also have some problems with the screen
> turning off and the GPU stalling, but this is outside of the scope of
> this list. This is what dmesg shows for the touchpad:
>
> psmouse serio1: alps: Unknown ALPS touchpad: E7=73 03 0a, EC=88 b6 06
>
> I hacked alps.c with the following code in alps_identify(...):
>
> [...]
>
> } else if (ec[0] == 0x88 && ec[1] == 0xb6 &&
> ec[2] == 0x06 )
> {
> priv->proto_version = ALPS_PROTO_V5;
> alps_set_defaults(priv);
>
> return 0;
> }
> [...]
>
> With this code the module seems to recognize the card and dmesg reports the following:
>
> [ 791.663876] input: PS/2 Mouse as /devices/platform/i8042/serio1/input/input22
> [ 791.692023] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input21
>
>
> However, the touchpad still operates only as a PS/2 mouse (no scroll, no middle
> button emulation, no touch gestures) even if I disable the PS/2 mouse
> with xinput.
>
> any help would be appreciated, I am willing to test patches if you send them to me.
>
> Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
From: Tommy Will @ 2014-01-18 2:30 UTC (permalink / raw)
To: AJ Guillon; +Cc: linux-input
In-Reply-To: <52D955A3.9040802@gmail.com>
Hi AJ,
> Here is the touchpad I bought:
> http://www.cirque.com/desktoptouchpad/productsandorders/smartcatpro.aspx
> (the black USB one).
Thanks for your info.
> It works somewhat as a mouse, but isn't recognized as a touchpad.
>
> If there is no chance for Linux support, I'll just return it and
> exchange for a brand that does support Linux. If there is something I
> can do to help it be supported, I'm happy to do so.
>
First, so thanks for you'll be happy to try the patch if we can
provide. However, I'm not
the manager of Cirque who can decide if we'll support the device.
I have sent the request mail to my Cirque's colleague and please wait
my feedback until
next week. Sorry for the inconvenience!
Thanks
--
Best Regards,
Tommy
> AJ
>
> On 14-01-17 11:01 AM, Tommy Will wrote:
>> Hi AJ,
>>
>> This is Tommy from ALPS. From the PCI ID you attached, it looks like
>> an external USB touchpad (?)
>> If so, modify alps.c may not let touchpad work since its only for PS/2 device.
>>
>> I'm sorry although I work in ALPS, I'm not so familar with the
>> products made by Cirque.
>> However, I'll try to ask our Cirque's colleagues if they have schedule
>> to support their products for Linux mainstring.
>> Thanks !
>>
^ permalink raw reply
* [PATCH 3/3] input: appletouch: fix jumps when additional fingers are detected
From: Clinton Sprain @ 2014-01-18 1:58 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Henrik Rydberg
In-Reply-To: <52D9DE7A.7040509@gmail.com>
Discard cursor movements if they directly coincide with
a change in the number of fingers detected. This helps
mitigate two issues - a sudden jump of the cursor when
a second finger enters or leaves the trackpad, and an
unexpected jump in page scrolling under the same
scenario. This doesn't completely eliminate all jumps
but does greatly reduce their frequency and velocity.
Signed-off-by: Clinton Sprain <clintonsprain@gmail.com>
---
drivers/input/mouse/appletouch.c | 41 ++++++++++++++++++++++++++++++++++----
1 file changed, 37 insertions(+), 4 deletions(-)
diff --git a/drivers/input/mouse/appletouch.c b/drivers/input/mouse/appletouch.c
index 4a3bbcd..406054a 100644
--- a/drivers/input/mouse/appletouch.c
+++ b/drivers/input/mouse/appletouch.c
@@ -218,6 +218,7 @@ struct atp {
int xy_acc[ATP_XSENSORS + ATP_YSENSORS];
int idlecount; /* number of empty packets */
struct work_struct work;
+ int fingers_old; /* last # of fingers detected*/
};
#define dbg_dump(msg, tab) \
{ \
@@ -538,6 +539,7 @@ static void atp_complete_geyser_1_2(struct urb *urb)
int x, y, x_z, y_z, x_f, y_f;
int retval, i, j;
int key;
+ int fingers;
struct atp *dev = urb->context;
int status = atp_status_check(urb);
@@ -621,7 +623,16 @@ static void atp_complete_geyser_1_2(struct urb *urb)
dev->info->yfact, &y_z, &y_f);
key = dev->data[dev->info->datalen - 1] & ATP_STATUS_BUTTON;
- if (x && y) {
+ fingers = max(x_f, y_f);
+
+ /*
+ * Only act if we have valid x/y and # of fingers did not change.
+ * If the # of fingers just changed, acting on the new x/y values will
+ * cause the cursor to jump across the screen or the page to scroll
+ * unexpectedly.
+ */
+
+ if (x && y && (dev->fingers_old == fingers)) {
if (dev->x_old != -1) {
if (legacy == true) {
x = atp_smooth_legacy(x, dev->x_old);
@@ -646,7 +657,7 @@ static void atp_complete_geyser_1_2(struct urb *urb)
input_report_abs(dev->input, ABS_Y, y);
input_report_abs(dev->input, ABS_PRESSURE,
min(ATP_PRESSURE, x_z + y_z));
- atp_report_fingers(dev->input, max(x_f, y_f));
+ atp_report_fingers(dev->input, fingers);
}
atp_refresh_old_xy(x, y, dev);
@@ -661,6 +672,12 @@ static void atp_complete_geyser_1_2(struct urb *urb)
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
}
+ /* if # of fingers changed, old x/y values are no longer useful */
+ if (dev->fingers_old != fingers)
+ atp_reset_old_xy(dev);
+
+ dev->fingers_old = fingers;
+
input_report_key(dev->input, BTN_LEFT, key);
input_sync(dev->input);
@@ -679,6 +696,7 @@ static void atp_complete_geyser_3_4(struct urb *urb)
int x, y, x_z, y_z, x_f, y_f;
int retval, i, j;
int key;
+ int fingers;
struct atp *dev = urb->context;
int status = atp_status_check(urb);
@@ -740,7 +758,16 @@ static void atp_complete_geyser_3_4(struct urb *urb)
dev->info->yfact, &y_z, &y_f);
key = dev->data[dev->info->datalen - 1] & ATP_STATUS_BUTTON;
- if (x && y) {
+ fingers = max(x_f, y_f);
+
+ /*
+ * Only act if we have valid x/y and # of fingers did not change.
+ * If the # of fingers just changed, acting on the new x/y values will
+ * cause the cursor to jump across the screen or the page to scroll
+ * unexpectedly.
+ */
+
+ if (x && y && (dev->fingers_old == fingers)) {
if (dev->x_old != -1) {
if (legacy == true) {
x = atp_smooth_legacy(x, dev->x_old);
@@ -765,7 +792,7 @@ static void atp_complete_geyser_3_4(struct urb *urb)
input_report_abs(dev->input, ABS_Y, y);
input_report_abs(dev->input, ABS_PRESSURE,
min(ATP_PRESSURE, x_z + y_z));
- atp_report_fingers(dev->input, max(x_f, y_f));
+ atp_report_fingers(dev->input, fingers);
}
atp_refresh_old_xy(x, y, dev);
@@ -780,6 +807,12 @@ static void atp_complete_geyser_3_4(struct urb *urb)
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
}
+ /* if # of fingers changed, old x/y values are no longer useful */
+ if (dev->fingers_old != fingers)
+ atp_reset_old_xy(dev);
+
+ dev->fingers_old = fingers;
+
input_report_key(dev->input, BTN_LEFT, key);
input_sync(dev->input);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] input: appletouch: use better cursor movement smoothing algorithm
From: Clinton Sprain @ 2014-01-18 1:56 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Henrik Rydberg
In-Reply-To: <52D9DE7A.7040509@gmail.com>
Implements a new algorithm used to smooth cursor
movement, using a sampling of the cursor's last three
positions to modulate the next cursor movement. This
further mitigates the 'stepping' users see when moving
the cursor diagonally. A 'legacy' module parameter has
been added in case the older devices do not like the
new algorithm.
Signed-off-by: Clinton Sprain <clintonsprain@gmail.com>
---
drivers/input/mouse/appletouch.c | 99 ++++++++++++++++++++++++++++++++------
1 file changed, 83 insertions(+), 16 deletions(-)
diff --git a/drivers/input/mouse/appletouch.c b/drivers/input/mouse/appletouch.c
index f5a16ee..4a3bbcd 100644
--- a/drivers/input/mouse/appletouch.c
+++ b/drivers/input/mouse/appletouch.c
@@ -209,13 +209,16 @@ struct atp {
bool overflow_warned;
int x_old; /* last reported x/y, */
int y_old; /* used for smoothing */
+ int x_older; /* 2nd to last reported x/y,*/
+ int y_older; /* used for smoothing */
+ int x_oldest; /* 3rd to last reported x/y,*/
+ int y_oldest; /* used for smoothing */
signed char xy_cur[ATP_XSENSORS + ATP_YSENSORS];
signed char xy_old[ATP_XSENSORS + ATP_YSENSORS];
int xy_acc[ATP_XSENSORS + ATP_YSENSORS];
int idlecount; /* number of empty packets */
struct work_struct work;
};
-
#define dbg_dump(msg, tab) \
{ \
if (debug > 1) { \
@@ -260,6 +263,13 @@ static int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Activate debugging output");
+static int legacy;
+module_param(legacy, int, 0644);
+MODULE_PARM_DESC(legacy, "1 = Use old cursor movement smoothing."
+ " Older behavior averages current with"
+ " last cursor position. New behavior"
+ " uses cursor movement inertia.");
+
/*
* By default newer Geyser devices send standard USB HID mouse
* packets (Report ID 2). This code changes device mode, so it
@@ -338,6 +348,49 @@ static void atp_reinit(struct work_struct *work)
retval);
}
+static int atp_smooth_legacy(int curr, int old)
+{
+ return (old * 3 + curr) >> 2;
+}
+
+static int atp_smooth(int curr, int old, int older, int oldest)
+{
+ return (oldest + older * 2 + old * 4 + curr) >> 3;
+}
+
+static void atp_refresh_old_xy(int x, int y, struct atp *dev)
+{
+ if (legacy != true) {
+ dev->x_oldest = dev->x_older;
+ dev->y_oldest = dev->y_older;
+ dev->x_older = dev->x_old;
+ dev->y_older = dev->y_old;
+ }
+ dev->x_old = x;
+ dev->y_old = y;
+}
+
+static void atp_reset_old_xy(struct atp *dev)
+{
+ if (legacy != true) {
+ dev->x_oldest = dev->y_oldest = -1;
+ dev->x_older = dev->y_older = -1;
+ }
+ dev->x_old = dev->y_old = -1;
+}
+
+static void atp_default_old_xy(struct atp *dev)
+{
+ if (dev->x_older == -1)
+ dev->x_older = dev->x_old;
+ if (dev->y_older == -1)
+ dev->y_older = dev->y_old;
+ if (dev->x_oldest == -1)
+ dev->x_oldest = dev->x_older;
+ if (dev->y_oldest == -1)
+ dev->y_oldest = dev->y_older;
+}
+
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
int *z, int *fingers)
{
@@ -570,10 +623,18 @@ static void atp_complete_geyser_1_2(struct urb *urb)
if (x && y) {
if (dev->x_old != -1) {
- x = (dev->x_old * 3 + x) >> 2;
- y = (dev->y_old * 3 + y) >> 2;
- dev->x_old = x;
- dev->y_old = y;
+ if (legacy == true) {
+ x = atp_smooth_legacy(x, dev->x_old);
+ y = atp_smooth_legacy(y, dev->y_old);
+ } else {
+
+ atp_default_old_xy(dev);
+
+ x = atp_smooth(x, dev->x_old,
+ dev->x_older, dev->x_oldest);
+ y = atp_smooth(y, dev->y_old,
+ dev->y_older, dev->y_oldest);
+ }
if (debug > 1)
printk(KERN_DEBUG "appletouch: "
@@ -587,12 +648,11 @@ static void atp_complete_geyser_1_2(struct urb *urb)
min(ATP_PRESSURE, x_z + y_z));
atp_report_fingers(dev->input, max(x_f, y_f));
}
- dev->x_old = x;
- dev->y_old = y;
+ atp_refresh_old_xy(x, y, dev);
} else if (!x && !y) {
- dev->x_old = dev->y_old = -1;
+ atp_reset_old_xy(dev);
input_report_key(dev->input, BTN_TOUCH, 0);
input_report_abs(dev->input, ABS_PRESSURE, 0);
atp_report_fingers(dev->input, 0);
@@ -682,10 +742,18 @@ static void atp_complete_geyser_3_4(struct urb *urb)
if (x && y) {
if (dev->x_old != -1) {
- x = (dev->x_old * 3 + x) >> 2;
- y = (dev->y_old * 3 + y) >> 2;
- dev->x_old = x;
- dev->y_old = y;
+ if (legacy == true) {
+ x = atp_smooth_legacy(x, dev->x_old);
+ y = atp_smooth_legacy(y, dev->y_old);
+ } else {
+
+ atp_default_old_xy(dev);
+
+ x = atp_smooth(x, dev->x_old,
+ dev->x_older, dev->x_oldest);
+ y = atp_smooth(y, dev->y_old,
+ dev->y_older, dev->y_oldest);
+ }
if (debug > 1)
printk(KERN_DEBUG "appletouch: X: %3d Y: %3d "
@@ -699,12 +767,11 @@ static void atp_complete_geyser_3_4(struct urb *urb)
min(ATP_PRESSURE, x_z + y_z));
atp_report_fingers(dev->input, max(x_f, y_f));
}
- dev->x_old = x;
- dev->y_old = y;
+ atp_refresh_old_xy(x, y, dev);
} else if (!x && !y) {
- dev->x_old = dev->y_old = -1;
+ atp_reset_old_xy(dev);
input_report_key(dev->input, BTN_TOUCH, 0);
input_report_abs(dev->input, ABS_PRESSURE, 0);
atp_report_fingers(dev->input, 0);
@@ -730,7 +797,7 @@ static void atp_complete_geyser_3_4(struct urb *urb)
if (!x && !y && !key) {
dev->idlecount++;
if (dev->idlecount == 10) {
- dev->x_old = dev->y_old = -1;
+ atp_reset_old_xy(dev);
dev->idlecount = 0;
schedule_work(&dev->work);
/* Don't resubmit urb here, wait for reinit */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] input: appletouch: parametrize and set saner defaults for fuzz and threshold
From: Clinton Sprain @ 2014-01-18 1:55 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Henrik Rydberg
In-Reply-To: <52D9DE7A.7040509@gmail.com>
Dials back the default fuzz and threshold settings for
most devices using this driver, based on values from
user feedback from forums and bug reports. This
increases smoothness and movement granularity. No
changes were made for the older devices that use the
driver, as I did not find any user feedback for them
regarding these settings; however, the two settings can
also now both be specified as module parameters in case
there is a desire to change the values for devices that
do not have new defaults.
There are also a couple of style cleanups per checkpatch.pl.
Signed-off-by: Clinton Sprain <clintonsprain@gmail.com>
---
drivers/input/mouse/appletouch.c | 66 ++++++++++++++++++++++++--------------
1 file changed, 42 insertions(+), 24 deletions(-)
diff --git a/drivers/input/mouse/appletouch.c b/drivers/input/mouse/appletouch.c
index e42f1fa..f5a16ee 100644
--- a/drivers/input/mouse/appletouch.c
+++ b/drivers/input/mouse/appletouch.c
@@ -43,12 +43,14 @@
*/
struct atp_info {
int xsensors; /* number of X sensors */
- int xsensors_17; /* 17" models have more sensors */
+ int xsensors_17; /* 17" model has more sensors */
int ysensors; /* number of Y sensors */
int xfact; /* X multiplication factor */
int yfact; /* Y multiplication factor */
int datalen; /* size of USB transfers */
void (*callback)(struct urb *); /* callback function */
+ int fuzz; /* fuzz touchpad generates */
+ int threshold; /* sensitivity threshold */
};
static void atp_complete_geyser_1_2(struct urb *urb);
@@ -62,6 +64,8 @@ static const struct atp_info fountain_info = {
.yfact = 43,
.datalen = 81,
.callback = atp_complete_geyser_1_2,
+ .fuzz = 16,
+ .threshold = 5,
};
static const struct atp_info geyser1_info = {
@@ -72,6 +76,8 @@ static const struct atp_info geyser1_info = {
.yfact = 43,
.datalen = 81,
.callback = atp_complete_geyser_1_2,
+ .fuzz = 16,
+ .threshold = 5,
};
static const struct atp_info geyser2_info = {
@@ -82,6 +88,8 @@ static const struct atp_info geyser2_info = {
.yfact = 43,
.datalen = 64,
.callback = atp_complete_geyser_1_2,
+ .fuzz = 0,
+ .threshold = 3,
};
static const struct atp_info geyser3_info = {
@@ -91,6 +99,8 @@ static const struct atp_info geyser3_info = {
.yfact = 64,
.datalen = 64,
.callback = atp_complete_geyser_3_4,
+ .fuzz = 0,
+ .threshold = 3,
};
static const struct atp_info geyser4_info = {
@@ -100,6 +110,8 @@ static const struct atp_info geyser4_info = {
.yfact = 64,
.datalen = 64,
.callback = atp_complete_geyser_3_4,
+ .fuzz = 0,
+ .threshold = 3,
};
#define ATP_DEVICE(prod, info) \
@@ -156,18 +168,9 @@ MODULE_DEVICE_TABLE(usb, atp_table);
#define ATP_XSENSORS 26
#define ATP_YSENSORS 16
-/* amount of fuzz this touchpad generates */
-#define ATP_FUZZ 16
-
/* maximum pressure this driver will report */
#define ATP_PRESSURE 300
-/*
- * Threshold for the touchpad sensors. Any change less than ATP_THRESHOLD is
- * ignored.
- */
-#define ATP_THRESHOLD 5
-
/* Geyser initialization constants */
#define ATP_GEYSER_MODE_READ_REQUEST_ID 1
#define ATP_GEYSER_MODE_WRITE_REQUEST_ID 9
@@ -213,14 +216,16 @@ struct atp {
struct work_struct work;
};
-#define dbg_dump(msg, tab) \
+#define dbg_dump(msg, tab) \
+{ \
if (debug > 1) { \
int __i; \
printk(KERN_DEBUG "appletouch: %s", msg); \
for (__i = 0; __i < ATP_XSENSORS + ATP_YSENSORS; __i++) \
printk(" %02x", tab[__i]); \
printk("\n"); \
- }
+ } \
+}
#define dprintk(format, a...) \
do { \
@@ -236,14 +241,20 @@ MODULE_AUTHOR("Sven Anders");
MODULE_DESCRIPTION("Apple PowerBook and MacBook USB touchpad driver");
MODULE_LICENSE("GPL");
-/*
- * Make the threshold a module parameter
- */
-static int threshold = ATP_THRESHOLD;
+static int threshold = -1;
module_param(threshold, int, 0644);
MODULE_PARM_DESC(threshold, "Discard any change in data from a sensor"
" (the trackpad has many of these sensors)"
- " less than this value.");
+ " less than this value. Devices have defaults;"
+ " this parameter overrides them.");
+static int fuzz = -1;
+
+module_param(fuzz, int, 0644);
+MODULE_PARM_DESC(fuzz, "Fuzz the trackpad generates. The higher"
+ " this is, the less sensitive the trackpad"
+ " will feel, but values too low may generate"
+ " random movement. Devices have defaults;"
+ " this parameter overrides them.");
static int debug;
module_param(debug, int, 0644);
@@ -363,7 +374,8 @@ static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
(!is_increasing && xy_sensors[i - 1] < xy_sensors[i])) {
(*fingers)++;
is_increasing = 1;
- } else if (i > 0 && (xy_sensors[i - 1] - xy_sensors[i] > threshold)) {
+ } else if (i > 0 && (xy_sensors[i - 1] -
+ xy_sensors[i] > threshold)) {
is_increasing = 0;
}
@@ -456,7 +468,7 @@ static void atp_detect_size(struct atp *dev)
input_set_abs_params(dev->input, ABS_X, 0,
(dev->info->xsensors_17 - 1) *
dev->info->xfact - 1,
- ATP_FUZZ, 0);
+ fuzz, 0);
break;
}
}
@@ -513,7 +525,8 @@ static void atp_complete_geyser_1_2(struct urb *urb)
/* Y values */
dev->xy_cur[ATP_XSENSORS + i] = dev->data[5 * i + 1];
- dev->xy_cur[ATP_XSENSORS + i + 8] = dev->data[5 * i + 3];
+ dev->xy_cur[ATP_XSENSORS + i + 8] =
+ dev->data[5 * i + 3];
}
}
@@ -809,12 +822,17 @@ static int atp_probe(struct usb_interface *iface,
dev->info = info;
dev->overflow_warned = false;
+ if (fuzz < 0)
+ fuzz = dev->info->fuzz;
+ if (threshold < 0)
+ threshold = dev->info->threshold;
+
dev->urb = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->urb)
goto err_free_devs;
- dev->data = usb_alloc_coherent(dev->udev, dev->info->datalen, GFP_KERNEL,
- &dev->urb->transfer_dma);
+ dev->data = usb_alloc_coherent(dev->udev, dev->info->datalen,
+ GFP_KERNEL, &dev->urb->transfer_dma);
if (!dev->data)
goto err_free_urb;
@@ -844,10 +862,10 @@ static int atp_probe(struct usb_interface *iface,
input_set_abs_params(input_dev, ABS_X, 0,
(dev->info->xsensors - 1) * dev->info->xfact - 1,
- ATP_FUZZ, 0);
+ fuzz, 0);
input_set_abs_params(input_dev, ABS_Y, 0,
(dev->info->ysensors - 1) * dev->info->yfact - 1,
- ATP_FUZZ, 0);
+ fuzz, 0);
input_set_abs_params(input_dev, ABS_PRESSURE, 0, ATP_PRESSURE, 0, 0);
set_bit(EV_KEY, input_dev->evbit);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/3] input: appletouch: fixes for jagged/uneven cursor movement
From: Clinton Sprain @ 2014-01-18 1:52 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Henrik Rydberg
Resubmitting the appletouch patches from last week with a couple of
updates, as no one's taken a look yet.
The appletouch driver can make some trackpads feel insensitive, with movement
that tends to jerk in steps. This is particularly evident when moving
diagonally. This can greatly hamper the trackpad's usability. These patches
address this by dialing back the fuzz and threshold parameters, by
implementing a new cursor movement smoothing algorithm and by discarding
movements that directly coincide with a change in the number of fingers
detected on the trackpad.
Revisions since last week:
Patch 1/3: Fuzz/threshold fix is identical, except for a typo (2 -> 3)
Patch 2/3: Smoothing algorithm is no longer inertia-based and is more
predictable / less complicated. I also dropped a change in atp_calculate_abs
that I couldn't definitively prove was beneficial.
Patch 3/3: (New) Addresses issues related to when a second finger enters
or leaves the trackpad, causing the cursor to jump or the page to scroll
unexpectedly; now, we discard any movement that happens at the exact moment
we detect a change in the number of fingers touching the trackpad.
Signed-off-by: Clinton Sprain <clintonsprain@gmail.com>
drivers/input/mouse/appletouch.c | 206 ++++++++++++++++++++++++++++++--------
1 file changed, 162 insertions(+), 44 deletions(-)
--
1.7.9.5
^ permalink raw reply
* New ALPS not detected EC=88 b6 06 - Lenovo Ideapad Flex 15D
From: Omar Loggiodice @ 2014-01-18 0:06 UTC (permalink / raw)
To: linux-input@vger.kernel.org
Hi,
First, thank you for your excellent work. I recently bought a new Lenovo Ideapad Flex 15D, it comes with Windows 8.1.
I have been able to run linux, however the ALPS touchpad is only recognized as a PS/2 mouse. I also have some problems with the screen
turning off and the GPU stalling, but this is outside of the scope of
this list. This is what dmesg shows for the touchpad:
psmouse serio1: alps: Unknown ALPS touchpad: E7=73 03 0a, EC=88 b6 06
I hacked alps.c with the following code in alps_identify(...):
[...]
} else if (ec[0] == 0x88 && ec[1] == 0xb6 &&
ec[2] == 0x06 )
{
priv->proto_version = ALPS_PROTO_V5;
alps_set_defaults(priv);
return 0;
}
[...]
With this code the module seems to recognize the card and dmesg reports the following:
[ 791.663876] input: PS/2 Mouse as /devices/platform/i8042/serio1/input/input22
[ 791.692023] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input21
However, the touchpad still operates only as a PS/2 mouse (no scroll, no middle
button emulation, no touch gestures) even if I disable the PS/2 mouse
with xinput.
any help would be appreciated, I am willing to test patches if you send them to me.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3 1/4] DT: Add vendor prefix for Emerging Display Technologies
From: Rob Herring @ 2014-01-17 22:18 UTC (permalink / raw)
To: Lothar Waßmann
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Rob Landley, Dmitry Torokhov, Thierry Reding, Grant Likely,
Jonathan Cameron, Shawn Guo, Silvio F, Guennadi Liakhovetski,
Jingoo Han, Fugang Duan, Sachin Kamat, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-input@vger.kernel.org
In-Reply-To: <1389961718-8130-2-git-send-email-LW@KARO-electronics.de>
On Fri, Jan 17, 2014 at 6:28 AM, Lothar Waßmann <LW@karo-electronics.de> wrote:
>
> Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> ---
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Applied.
Rob
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index b458760..49774c3 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -29,6 +29,7 @@ dallas Maxim Integrated Products (formerly Dallas Semiconductor)
> davicom DAVICOM Semiconductor, Inc.
> denx Denx Software Engineering
> dmo Data Modul AG
> +edt Emerging Display Technologies
> emmicro EM Microelectronic
> epson Seiko Epson Corp.
> est ESTeem Wireless Modems
> --
> 1.7.2.5
>
^ permalink raw reply
* Re: Atmel updates to atmel_mxt_ts touch controller driver - v6
From: Nick Dyer @ 2014-01-17 20:01 UTC (permalink / raw)
To: Yufeng Shen
Cc: Dmitry Torokhov, Henrik Rydberg, Daniel Kurtz, Joonyoung Shim,
Alan Bowens, linux-input, linux-kernel, Peter Meerwald,
Benson Leung, Olof Johansson, adlr
In-Reply-To: <CAPDwgkOsP4K7r0-Mo-U52X9knRbGgbuD4dGptmj3x-LMTN75BA@mail.gmail.com>
Yufeng Shen wrote:
> On Wed, Jan 15, 2014 at 5:44 AM, Nick Dyer <nick.dyer@itdev.co.uk
> <mailto:nick.dyer@itdev.co.uk>> wrote:
> > We (Chromium authors) are planning on bringing our local tree of atmel
> > driver to be as close as possible to
> > upstream and trying to figure out what's the best tree to rebase against.
>
> I was considering picking up the patches that Dimitry has already reviewed
> and rebasing them against the current mainline to try and get things moving
> again - would that be useful?
>
> That would certainly be useful. Please let me know the branch/tag name once
> you finish that.
I've rebased Dimitry's atmel-mxt-ts branch against his dtor/next tree. You
can find it at
https://github.com/ndyer/linux/tree/for-next-20140117-dtor-rebase
I needed to update the INIT_COMPLETION api. So far I have verified it
builds, will do some testing on it next week.
I will also need to port my previous patchset on top of this branch.
^ permalink raw reply
* [PATCH v2] HID: sony: Cache the output report for the Dualshock 4
From: Frank Praznik @ 2014-01-17 19:46 UTC (permalink / raw)
To: linux-input; +Cc: Jiri Kosina, David Herrmann
Retrieve and cache the output report for the Dualshock 4 in sony_probe()
instead of repeatedly walking the report list in the worker function.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
---
Apply against jikos/hid.git/for-3.14/sony
drivers/hid/hid-sony.c | 55 ++++++++++++++++++++++++++++++++------------------
1 file changed, 35 insertions(+), 20 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index edffe2c..277da77 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -298,6 +298,7 @@ static const unsigned int buzz_keymap[] = {
struct sony_sc {
struct hid_device *hdev;
struct led_classdev *leds[MAX_LEDS];
+ struct hid_report *output_report;
unsigned long quirks;
struct work_struct state_worker;
@@ -743,26 +744,9 @@ static void dualshock4_state_worker(struct work_struct *work)
{
struct sony_sc *sc = container_of(work, struct sony_sc, state_worker);
struct hid_device *hdev = sc->hdev;
- struct list_head *head, *list;
- struct hid_report *report;
- __s32 *value;
-
- list = &hdev->report_enum[HID_OUTPUT_REPORT].report_list;
-
- list_for_each(head, list) {
- report = list_entry(head, struct hid_report, list);
-
- /* Report 5 is used to send data to the controller via USB */
- if ((sc->quirks & DUALSHOCK4_CONTROLLER_USB) && report->id == 5)
- break;
- }
-
- if (head == list) {
- hid_err(hdev, "Dualshock 4 output report not found\n");
- return;
- }
+ struct hid_report *report = sc->output_report;
+ __s32 *value = report->field[0]->value;
- value = report->field[0]->value;
value[0] = 0x03;
#ifdef CONFIG_SONY_FF
@@ -822,6 +806,33 @@ static void sony_destroy_ff(struct hid_device *hdev)
}
#endif
+static int sony_set_output_report(struct sony_sc *sc, int req_id, int req_size)
+{
+ struct list_head *head, *list;
+ struct hid_report *report;
+ struct hid_device *hdev = sc->hdev;
+
+ list = &hdev->report_enum[HID_OUTPUT_REPORT].report_list;
+
+ list_for_each(head, list) {
+ report = list_entry(head, struct hid_report, list);
+
+ if (report->id == req_id) {
+ if (report->size < req_size) {
+ hid_err(hdev, "Output report 0x%02x (%i bits) is smaller than requested size (%i bits)\n",
+ req_id, report->size, req_size);
+ return -EINVAL;
+ }
+ sc->output_report = report;
+ return 0;
+ }
+ }
+
+ hid_err(hdev, "Unable to locate output report 0x%02x\n", req_id);
+
+ return -EINVAL;
+}
+
static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
{
int ret;
@@ -866,7 +877,11 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
else if (sc->quirks & SIXAXIS_CONTROLLER_BT)
ret = sixaxis_set_operational_bt(hdev);
else if (sc->quirks & DUALSHOCK4_CONTROLLER_USB) {
- ret = 0;
+ /* Report 5 (31 bytes) is used to send data to the controller via USB */
+ ret = sony_set_output_report(sc, 0x05, 248);
+ if (ret < 0)
+ goto err_stop;
+
INIT_WORK(&sc->state_worker, dualshock4_state_worker);
} else {
ret = 0;
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH] drivers/input/mouse/elantech elantech driver for Lenovo L530 trackpoint
From: Jonathan Aquilina @ 2014-01-17 19:20 UTC (permalink / raw)
To: David Herrmann, linux-input@vger.kernel.org
Cc: Ulrik De Bie, dmitry.torokhov@gmail.com
In-Reply-To: <CANq1E4QQf62cvU0XXHRNqRCPqZfHH1PMV_MbKWNiSx-TEaxbOw@mail.gmail.com>
I tested this on another device which was not a lenovo and it sadly did not fix
the problem for me :(. But please dont let it stop you from including this for
others that have the above mentioned device.
Thanks
On Friday 17 January 2014 18:19:11 David Herrmann wrote:
> Hi
>
> According to Jonathan this patch is still not applied, would anyone
> care to resend it as proper git patch so we can review it and
> eventually apply it?
>
> Thanks
> David
>
> On Tue, Jul 30, 2013 at 11:44 PM, Ulrik De Bie
>
> <ulrik_opensource-kernel@yahoo.com> wrote:
> > Hi,
> >
> > I've a new work laptop Lenovo L530. For 3.2 and 3.9 kernel, the trackpoint
> > does not work out of the box. It gives sync errors as shown below when the
> > trackpoint or trackpoint mouse buttons are pressed and no input is
> > received by userspace: [ 29.010641] psmouse serio1: Touchpad at
> > isa0060/serio1/input0 lost sync at byte 6 The touchpad does work.
> >
> > The alternative is to do a downgrade to generic ps/2 mouse (modprobe
> > psmouse proto=bare) but this has the disadvantage that touchpad can't be
> > disabled (I want trackpoint, not touchpad).
> >
> > I did some analysis of the psmouse packets generated, and it became
> > apparent that the generated packets are according to a very strict format
> > as described in the elantech_report_trackpoint function in the patch
> > below.
> >
> > With this patch, the trackpoint is provided as another input device;
> > currently called 'My stick' The trackpoint now succesfully works and I
> > can disable the touchpad with synclient TouchPadOff=1 The patch will also
> > output messages that do not follow the expected pattern. In the mean time
> > I've seen 2 unknown packets occasionally:
> > 0x04 , 0x00 , 0x00 , 0x00 , 0x00 , 0x00
> > 0x00 , 0x00 , 0x00 , 0x02 , 0x00 , 0x00
> > I don't know what those are for, but they can be safely ignored.
> >
> > Currently all packets that are not known to v3 touchpad and where
> > packet[3] (the fourth byte) lowest nibble is 6 are now recognized as
> > PACKET_TRACKPOINT and processed by the new elantech_report_trackpoint.
> >
> >
> > The first feedback I would appreciate on the patch:
> > 1a) Do you think that the creation of the extra input device is the
> > correct way to go ? I saw also a synaptics-pt but I was not able to
> > figure it out and the extra input gave me a desirable result fast.
> >
> > 1b) What would be the requirements for the name and the phys parameter of
> > the device ?
> >
> >
> > 2) Is the patch correct with regards to ps/2 protocol semantics ? Should
> > it be more restrictive; maybe limited to the 4 patterns used to dump
> > unexpected packets ?
> >
> > 3) Would a 'trackpoint' detection be required ? I have no idea how to do
> > this because I have a lack of elantech version/capabilities samples, I
> > have just the one on my laptop: psmouse serio1: elantech: assuming
> > hardware version 3 (with firmware version 0x350f02) psmouse serio1:
> > elantech: Synaptics capabilities query result 0xb9, 0x15, 0x0c.
> >
> > 4) Is there anyone else with different hardware/firmwareversion/synaptics
> > capabilities where this patch also works ?
> >
> > The patch below was ported to 3.10.4 kernel (originally made for 3.2
> > kernel which is the default kernel on my laptop)
> >
> > Thanks for all feedback and your time,
> > Ulrik
> >
> >
> >
> >
> > diff -uprN -X linux-3.10.4-vanilla/Documentation/dontdiff
> > linux-3.10.4-vanilla/drivers/input/mouse/elantech.c
> > linux-3.10.4/drivers/input/mouse/elantech.c ---
> > linux-3.10.4-vanilla/drivers/input/mouse/elantech.c 2013-07-29
> > 01:30:49.000000000 +0200 +++ linux-3.10.4/drivers/input/mouse/elantech.c
> > 2013-07-30 23:06:12.000000000 +0200 @@ -402,6 +402,54 @@ static void
> > elantech_report_absolute_v2(
> >
> > input_sync(dev);
> >
> > }
> >
> > +static void elantech_report_trackpoint(struct psmouse *psmouse,
> > + int packet_type)
> > +{
> > + /* byte 0: 0 0 ~sx ~sy 0 M R L */
> > + /* byte 1: sx 0 0 0 0 0 0 0 */
> > + /* byte 2: sy 0 0 0 0 0 0 0 */
> > + /* byte 3: 0 0 sy sx 0 1 1 0 */
> > + /* byte 4: x7 x6 x5 x4 x3 x2 x1 x0 */
> > + /* byte 5: y7 y6 y5 y4 y3 y2 y1 y0 */
> > +
> > + /*
> > + * x and y are written in two's complement spread
> > + * over 9 bits with sx/sy the relative top bit and
> > + * x7..x0 and y7..y0 the lower bits.
> > + * The sign of y is opposite to what the input driver
> > + * expects for a relative movement
> > + */
> > +
> > + struct elantech_data *etd = psmouse->private;
> > + struct input_dev *dev2 = etd->dev2;
> > + unsigned char *packet = psmouse->packet;
> > + int x, y;
> > + input_report_key(dev2, BTN_LEFT, packet[0] & 0x01);
> > + input_report_key(dev2, BTN_RIGHT, packet[0] & 0x02);
> > + input_report_key(dev2, BTN_MIDDLE, packet[0] & 0x04);
> > + x = (s32) ((u32) ((packet[1] & 0x80) ? 0UL : 0xFFFFFF00UL) | (u32)
> > + packet[4]);
> > + y = -(s32) ((u32) ((packet[2] & 0x80) ? 0UL : 0xFFFFFF00UL) | (u32)
> > + packet[5]);
> > + input_report_rel(dev2, REL_X, x);
> > + input_report_rel(dev2, REL_Y, y);
> > + switch ((((u32) packet[0] & 0xF8) << 24) | ((u32) packet[1] << 16)
> > + | (u32) packet[2] << 8 | (u32) packet[3]) {
> > + case 0x00808036UL:
> > + case 0x10008026UL:
> > + case 0x20800016UL:
> > + case 0x30000006UL:
> > + break;
> > + default:
> > + /* Dump unexpected packet sequences if debug=1 (default) */
> > + if (etd->debug == 1)
> > + elantech_packet_dump(psmouse);
> > + break;
> > + }
> > +
> > + input_sync(dev2);
> > +}
> > +
> > /*
> >
> > * Interpret complete data packets and report absolute mode input events
> > for
> > * hardware version 3. (12 byte packets for two fingers)
> >
> > @@ -688,6 +736,8 @@ static int elantech_packet_check_v3(stru
> >
> > if ((packet[0] & 0x0c) == 0x0c && (packet[3] & 0xce) == 0x0c)
> >
> > return PACKET_V3_TAIL;
> >
> > + if ((packet[3]&0x0f) == 0x06)
> > + return PACKET_TRACKPOINT;
> >
> > return PACKET_UNKNOWN;
> >
> > }
> >
> > @@ -752,7 +802,10 @@ static psmouse_ret_t elantech_process_by
> >
> > if (packet_type == PACKET_UNKNOWN)
> >
> > return PSMOUSE_BAD_DATA;
> >
> > - elantech_report_absolute_v3(psmouse, packet_type);
> > + if (packet_type == PACKET_TRACKPOINT)
> > + elantech_report_trackpoint(psmouse, packet_type);
> > + else
> > + elantech_report_absolute_v3(psmouse, packet_type);
> >
> > break;
> >
> > case 4:
> > @@ -1236,8 +1289,10 @@ int elantech_detect(struct psmouse *psmo
> >
> > */
> >
> > static void elantech_disconnect(struct psmouse *psmouse)
> > {
> > + struct elantech_data *etd = psmouse->private;
> >
> > sysfs_remove_group(&psmouse->ps2dev.serio->dev.kobj,
> >
> > &elantech_attr_group);
> >
> > + input_unregister_device(etd->dev2);
> >
> > kfree(psmouse->private);
> > psmouse->private = NULL;
> >
> > }
> > @@ -1323,10 +1378,15 @@ int elantech_init(struct psmouse *psmous
> >
> > struct elantech_data *etd;
> > int i, error;
> > unsigned char param[3];
> >
> > + struct input_dev *dev2;
> >
> > psmouse->private = etd = kzalloc(sizeof(struct elantech_data),
> > GFP_KERNEL);
> > if (!etd)
> >
> > return -ENOMEM;
> >
> > + dev2 = input_allocate_device();
> > + if (!dev2)
> > + goto init_fail;
> > + etd->dev2 = dev2;
> >
> > psmouse_reset(psmouse);
> >
> > @@ -1386,9 +1446,26 @@ int elantech_init(struct psmouse *psmous
> >
> > psmouse->reconnect = elantech_reconnect;
> > psmouse->pktsize = etd->hw_version > 1 ? 6 : 4;
> >
> > + snprintf(etd->phys, sizeof(etd->phys), "%s/input1",
> > + psmouse->ps2dev.serio->phys);
> > + dev2->phys = etd->phys;
> > + dev2->name = "My stick";
> > + dev2->id.bustype = BUS_I8042;
> > + dev2->id.vendor = 0x0002;
> > + dev2->id.product = PSMOUSE_ELANTECH;
> > + dev2->id.version = 0x0000;
> > + dev2->dev.parent = &psmouse->ps2dev.serio->dev;
> > + dev2->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REL);
> > + dev2->relbit[BIT_WORD(REL_X)] = BIT_MASK(REL_X) | BIT_MASK(REL_Y);
> > + dev2->keybit[BIT_WORD(BTN_LEFT)] =
> > + BIT_MASK(BTN_LEFT) | BIT_MASK(BTN_MIDDLE) | BIT_MASK(BTN_RIGHT);
> > +
> > + if (input_register_device(etd->dev2))
> > + goto init_fail;
> >
> > return 0;
> >
> > init_fail:
> > + input_free_device(dev2);
> >
> > kfree(etd);
> > return -1;
> >
> > }
> > diff -uprN -X linux-3.10.4-vanilla/Documentation/dontdiff
> > linux-3.10.4-vanilla/drivers/input/mouse/elantech.h
> > linux-3.10.4/drivers/input/mouse/elantech.h ---
> > linux-3.10.4-vanilla/drivers/input/mouse/elantech.h 2013-07-29
> > 01:30:49.000000000 +0200 +++ linux-3.10.4/drivers/input/mouse/elantech.h
> > 2013-07-30 21:14:09.000000000 +0200 @@ -94,6 +94,7 @@
> > #define PACKET_V4_HEAD 0x05
> > #define PACKET_V4_MOTION 0x06
> > #define PACKET_V4_STATUS 0x07
> > +#define PACKET_TRACKPOINT 0x08
> >
> > /*
> >
> > * track up to 5 fingers for v4 hardware
> >
> > @@ -114,6 +115,8 @@ struct finger_pos {
> > };
> >
> > struct elantech_data {
> > + struct input_dev *dev2; /* Relative device */
> > + char phys[32];
> >
> > unsigned char reg_07;
> > unsigned char reg_10;
> > unsigned char reg_11;
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-input" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3] input/uinput: add UI_GET_SYSNAME ioctl to retrieve the sysfs path
From: Benjamin Tissoires @ 2014-01-17 19:12 UTC (permalink / raw)
To: Benjamin Tissoires, Dmitry Torokhov, David Herrmann,
Peter Hutterer, linux-input, linux-kernel
Evemu [1] uses uinput to replay devices traces it has recorded. However,
the way evemu uses uinput is slightly different from how uinput is
supposed to be used.
Evemu relies on libevdev, which creates the device node through uinput.
It then injects events through the input device node directly (and it
completely skips the uinput node).
Currently, libevdev relies on an heuristic to guess which input node was
created. The problem is that is heuristic is subjected to races between
different uinput devices or even with physical devices. Having a way
to retrieve the sysfs path allows us to find the event node without
having to rely on this heuristic.
[1] http://www.freedesktop.org/wiki/Evemu/
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Ok, I am resurrecting this. The original patch was sent last July here:
https://patchwork.kernel.org/patch/2827524/
changes since v2:
- the ioctl returns only the device name, thus I renamed the ioctl to UI_GET_SYSNAME
- reordered uinput_str_to_user() arguments
- be sure to terminate the user string we send by \0
- abort if udev->state is not UIST_CREATED
- dropped the patch 1/2 (adding resolution to uinput) because I think David has
already it in one of his queues (ABS2 IIRC)
I also posted the corresponding libevdev here:
http://lists.freedesktop.org/archives/input-tools/2014-January/000757.html
Cheers,
Benjamin
drivers/input/misc/uinput.c | 46 ++++++++++++++++++++++++++++++++++++++++++++-
include/linux/uinput.h | 2 ++
include/uapi/linux/uinput.h | 13 ++++++++++++-
3 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 7728359..0203219 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -20,6 +20,8 @@
* Author: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
*
* Changes/Revisions:
+ * 0.4 01/09/2014 (Benjamin Tissoires <benjamin.tissoires@redhat.com>)
+ * - add UI_GET_SYSNAME ioctl
* 0.3 09/04/2006 (Anssi Hannula <anssi.hannula@gmail.com>)
* - updated ff support for the changes in kernel interface
* - added MODULE_VERSION
@@ -670,6 +672,27 @@ static int uinput_ff_upload_from_user(const char __user *buffer,
__ret; \
})
+static int uinput_str_to_user(void __user *dest, const char *str,
+ unsigned int maxlen)
+{
+ int len, ret;
+
+ if (!str)
+ return -ENOENT;
+
+ len = strlen(str) + 1;
+ if (len > maxlen)
+ len = maxlen;
+
+ ret = copy_to_user(dest, str, len);
+ if (ret)
+ return -EFAULT;
+
+ /* force terminating '\0' */
+ ret = copy_to_user(dest + len - 1, "\0", 1);
+ return ret ? -EFAULT : len;
+}
+
static long uinput_ioctl_handler(struct file *file, unsigned int cmd,
unsigned long arg, void __user *p)
{
@@ -679,6 +702,8 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd,
struct uinput_ff_erase ff_erase;
struct uinput_request *req;
char *phys;
+ const char *name;
+ unsigned int size;
retval = mutex_lock_interruptible(&udev->mutex);
if (retval)
@@ -831,7 +856,26 @@ static long uinput_ioctl_handler(struct file *file, unsigned int cmd,
break;
default:
- retval = -EINVAL;
+ retval = -EAGAIN;
+ }
+
+ if (retval == -EAGAIN) {
+ size = _IOC_SIZE(cmd);
+
+ /* Now check variable-length commands */
+ switch (cmd & ~IOCSIZE_MASK) {
+ case UI_GET_SYSNAME(0):
+ if (udev->state != UIST_CREATED) {
+ retval = -ENOENT;
+ goto out;
+ }
+ name = dev_name(&udev->dev->dev);
+ retval = uinput_str_to_user(p, name, size);
+ break;
+
+ default:
+ retval = -EINVAL;
+ }
}
out:
diff --git a/include/linux/uinput.h b/include/linux/uinput.h
index 0a4487d..0994c0d 100644
--- a/include/linux/uinput.h
+++ b/include/linux/uinput.h
@@ -20,6 +20,8 @@
* Author: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
*
* Changes/Revisions:
+ * 0.4 01/09/2014 (Benjamin Tissoires <benjamin.tissoires@redhat.com>)
+ * - add UI_GET_SYSNAME ioctl
* 0.3 24/05/2006 (Anssi Hannula <anssi.hannulagmail.com>)
* - update ff support for the changes in kernel interface
* - add UINPUT_VERSION
diff --git a/include/uapi/linux/uinput.h b/include/uapi/linux/uinput.h
index fe46431..0389b48 100644
--- a/include/uapi/linux/uinput.h
+++ b/include/uapi/linux/uinput.h
@@ -20,6 +20,8 @@
* Author: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
*
* Changes/Revisions:
+ * 0.4 01/09/2014 (Benjamin Tissoires <benjamin.tissoires@redhat.com>)
+ * - add UI_GET_SYSNAME ioctl
* 0.3 24/05/2006 (Anssi Hannula <anssi.hannulagmail.com>)
* - update ff support for the changes in kernel interface
* - add UINPUT_VERSION
@@ -35,7 +37,7 @@
#include <linux/types.h>
#include <linux/input.h>
-#define UINPUT_VERSION 3
+#define UINPUT_VERSION 4
struct uinput_ff_upload {
@@ -73,6 +75,15 @@ struct uinput_ff_erase {
#define UI_BEGIN_FF_ERASE _IOWR(UINPUT_IOCTL_BASE, 202, struct uinput_ff_erase)
#define UI_END_FF_ERASE _IOW(UINPUT_IOCTL_BASE, 203, struct uinput_ff_erase)
+/**
+ * UI_GET_SYSNAME - get the sysfs name of the created uinput device
+ *
+ * @return the sysfs name of the created virtual input device.
+ * The complete sysfs path is then /sys/devices/virtual/input/--NAME--
+ * Usually, it is in the form "inputN"
+ */
+#define UI_GET_SYSNAME(len) _IOC(_IOC_READ, UINPUT_IOCTL_BASE, 300, len)
+
/*
* To write a force-feedback-capable driver, the upload_effect
* and erase_effect callbacks in input_dev must be implemented.
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 4/4] HID: sony: Map gyroscopes and accelerometers to axes
From: Jiri Kosina @ 2014-01-17 19:03 UTC (permalink / raw)
To: Frank Praznik; +Cc: David Herrmann, linux-input, Frank Praznik
In-Reply-To: <52D965E2.6010907@gmail.com>
On Fri, 17 Jan 2014, Frank Praznik wrote:
> Any objections to moving all of the rdesc data to an hid-sony.h header
> file?
Please don't. This doesn't really belong in a header file. Header files
are used to declare things, not to have large data structures there.
There are other drivers which contain annotated descriptor and are
readable; for example look at hid-waltop.
Thanks,
--
Jiri Kosina
SUSE Labs
^ 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