* [PATCH] Add HID's to hid-microsoft driver of Surface Type/Touch Cover 2 to fix bug
From: Reyad Attiyat @ 2014-01-21 0:42 UTC (permalink / raw)
To: linux-input, linux-kernel
The below patch fixes a bug 64811
(https://bugzilla.kernel.org/show_bug.cgi?id=64811) of the Microsoft
Surface Type/Touch cover 2 devices being detected as a multitouch
device.
The fix adds the HID of the two devices to hid-microsoft driver. This
ensures that hid-input will eventually be used for the device and not
hid-multitouch.
>From 866c814f3f6740a5a79858fdf8bf5bbcdc3b57f8 Mon Sep 17 00:00:00 2001
From: Reyad Attiyat <reyad.attiyat@gmail.com>
Date: Mon, 20 Jan 2014 16:24:49 -0600
Subject: [PATCH 1/2] Added in ID's for Surface Type/Touch cover 2 to the
hid-microsoft driver
---
drivers/hid/hid-ids.h | 4 +++-
drivers/hid/hid-microsoft.c | 4 ++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index f9304cb..b523a8b 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -611,7 +611,9 @@
#define USB_DEVICE_ID_MS_PRESENTER_8K_USB 0x0713
#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K 0x0730
#define USB_DEVICE_ID_MS_COMFORT_MOUSE_4500 0x076c
-
+#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
+#define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
+
#define USB_VENDOR_ID_MOJO 0x8282
#define USB_DEVICE_ID_RETRO_ADAPTER 0x3201
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 551795b..2599de8 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -207,6 +207,10 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
.driver_data = MS_DUPLICATE_USAGES },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_2),
+ .driver_data = 0 },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TOUCH_COVER_2),
+ .driver_data = 0 },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_PRESENTER_8K_BT),
.driver_data = MS_PRESENTER },
--
1.8.4.2
^ permalink raw reply related
* Re: Regression: commit e696c68363740d3a8fe495e353de3ff26b86257a prevents Linux 3.13 from booting on Lenovo X1 Carbon.
From: Jens Taprogge @ 2014-01-21 0:20 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Dmitry Torokhov, Thomas Hellstrom, linux-input
In-Reply-To: <20140120235358.GC5012@kroah.com>
On Mon, Jan 20, 2014 at 03:53:58PM -0800, Greg Kroah-Hartman wrote:
> On Tue, Jan 21, 2014 at 12:26:52AM +0100, Jens Taprogge wrote:
> > Hello,
> >
> > I have bisected the boot failure of a Lenovo Thinkpad X1 Carbon to the
> > merge ea4ebd1cb093c8ec5d7f4bf9070dc444184c3971. What I call "boot
> > failure" refers to the fact that no console is shown, the machine only
> > reads from the disc for a very short time, and the machine does not
> > respond to Ctrl-Alt-Del, etc.
> >
> > As it turns out reverting e696c68363740d3a8fe495e353de3ff26b86257a
> > (Input: serio - fix sysfs layout) on top of v3.13 makes the machine boot
> > again. So far I have now clue how this commit can affect early boot
> > / showing of the console.
> >
> > Does it ring any bells for you?
>
> No, not at all, I don't see how that patch could prevent booting,
> especially as it is fixing a regression (i.e. putting things back the
> way they originally were.)
>
> very odd.
>
> greg k-h
I agree. This machine had some very weird boot issues a while ago.
I was starting to suspect it had some alignment issue of some vector
that the EFI firmware uses when handing over control to the kernel.
(Note that I know very little about EFI.) Does that make any sense?
See this thread http://www.spinics.net/lists/stable/msg09886.html for
the old discussion. Back then, the problem disappeared with later
version of the kernel / compiler.
Best Regards,
Jens
^ permalink raw reply
* Regression: commit e696c68363740d3a8fe495e353de3ff26b86257a prevents Linux 3.13 from booting on Lenovo X1 Carbon.
From: Jens Taprogge @ 2014-01-20 23:26 UTC (permalink / raw)
To: Dmitry Torokhov, Greg Kroah-Hartman, Thomas Hellstrom; +Cc: linux-input
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
Hello,
I have bisected the boot failure of a Lenovo Thinkpad X1 Carbon to the
merge ea4ebd1cb093c8ec5d7f4bf9070dc444184c3971. What I call "boot
failure" refers to the fact that no console is shown, the machine only
reads from the disc for a very short time, and the machine does not
respond to Ctrl-Alt-Del, etc.
As it turns out reverting e696c68363740d3a8fe495e353de3ff26b86257a
(Input: serio - fix sysfs layout) on top of v3.13 makes the machine boot
again. So far I have now clue how this commit can affect early boot
/ showing of the console.
Does it ring any bells for you?
Please find the .config used attached.
Best Regards,
Jens
[-- Attachment #2: config3.13.gz --]
[-- Type: application/octet-stream, Size: 22997 bytes --]
^ permalink raw reply
* Re: Regression: commit e696c68363740d3a8fe495e353de3ff26b86257a prevents Linux 3.13 from booting on Lenovo X1 Carbon.
From: Greg Kroah-Hartman @ 2014-01-20 23:53 UTC (permalink / raw)
To: Jens Taprogge; +Cc: Dmitry Torokhov, Thomas Hellstrom, linux-input
In-Reply-To: <20140120232652.GA5815@weetamoe.luzern.taprogge.wh>
On Tue, Jan 21, 2014 at 12:26:52AM +0100, Jens Taprogge wrote:
> Hello,
>
> I have bisected the boot failure of a Lenovo Thinkpad X1 Carbon to the
> merge ea4ebd1cb093c8ec5d7f4bf9070dc444184c3971. What I call "boot
> failure" refers to the fact that no console is shown, the machine only
> reads from the disc for a very short time, and the machine does not
> respond to Ctrl-Alt-Del, etc.
>
> As it turns out reverting e696c68363740d3a8fe495e353de3ff26b86257a
> (Input: serio - fix sysfs layout) on top of v3.13 makes the machine boot
> again. So far I have now clue how this commit can affect early boot
> / showing of the console.
>
> Does it ring any bells for you?
No, not at all, I don't see how that patch could prevent booting,
especially as it is fixing a regression (i.e. putting things back the
way they originally were.)
very odd.
greg k-h
^ permalink raw reply
* Re: [PATCH v3] input/uinput: add UI_GET_SYSNAME ioctl to retrieve the sysfs path
From: Peter Hutterer @ 2014-01-20 22:56 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dmitry Torokhov, Benjamin Tissoires, David Herrmann, linux-input,
linux-kernel@vger.kernel.org
In-Reply-To: <CAN+gG=EPXLR5H_h0UgaMOmAbwAivxCohtg3Gocws5fJucz4+eg@mail.gmail.com>
On Mon, Jan 20, 2014 at 05:17:08PM -0500, Benjamin Tissoires wrote:
> On Mon, Jan 20, 2014 at 4:53 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > Hi Benjamin,
> >
> > On Fri, Jan 17, 2014 at 02:12:51PM -0500, Benjamin Tissoires 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.
> >
> > I have been thinking about it and I think that providing tight coupling
> > between uinput and resulting event device is wrong thing to do. We do
> > allow sending input events through uinput interface and I think evemu
> > should be using it, instead of going halfway through uinput and halfway
> > though evdev. Replaying though uinput would actually be more correct as
> > it would involve the same code paths throgugh input core as with using
> > real devices (see input_event() vs. input_inject_event() that is used by
> > input handlers).
> >
>
> Yes, I am perfectly aware of the fact that evemu is not using uinput
> in the way it is intended to be.
> I agree that it should be using the uinput node to inject events but
> this means that only the process which has created the virtual device
> can access it. It seems weird, I know, but the typical use of evemu is
> the following:
> - in a first terminal: $> sudo evemu-device mydevice.desc
> - In a second: $> sudo evemu-play /dev/input/event12 < mydevice.events
>
> It looks weird here, but it allows to inject different events
> recording for the same virtual device node.
it also allows replaying an event through the device it was recorded on.
it's not always necessary or desirable to create a uinput device, sometimes
replaying it through the actual device is better to reproduce a certain bug.
Cheers,
Peter
> Using the uinput node to
> inject events will force us to change the user "interface" and rely on
> pipes to get the same separation of describe/inject.
> Note that I am modifying evemu-play to be able to also create the
> virtual device, so I am not entirely convinced about this argument
> (but we have users).
>
> The other use case I should have mentioned in the commit message is
> that we extensively rely on evemu for the xorg-integration-tests (and
> the upcoming wayland test suite if I am not wrong).
> The tests are fully automatized, and we need to know which input node
> has just been created to record the correct one and test against it.
>
>
> Ok, I am stopping here because Peter already answered about this in his mail :)
>
> Cheers,
> Benjamin
^ permalink raw reply
* Re: [PATCH v3] input/uinput: add UI_GET_SYSNAME ioctl to retrieve the sysfs path
From: Benjamin Tissoires @ 2014-01-20 22:17 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Benjamin Tissoires, David Herrmann, Peter Hutterer, linux-input,
linux-kernel@vger.kernel.org
In-Reply-To: <20140120215313.GB4270@core.coreip.homeip.net>
On Mon, Jan 20, 2014 at 4:53 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Benjamin,
>
> On Fri, Jan 17, 2014 at 02:12:51PM -0500, Benjamin Tissoires 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.
>
> I have been thinking about it and I think that providing tight coupling
> between uinput and resulting event device is wrong thing to do. We do
> allow sending input events through uinput interface and I think evemu
> should be using it, instead of going halfway through uinput and halfway
> though evdev. Replaying though uinput would actually be more correct as
> it would involve the same code paths throgugh input core as with using
> real devices (see input_event() vs. input_inject_event() that is used by
> input handlers).
>
Yes, I am perfectly aware of the fact that evemu is not using uinput
in the way it is intended to be.
I agree that it should be using the uinput node to inject events but
this means that only the process which has created the virtual device
can access it. It seems weird, I know, but the typical use of evemu is
the following:
- in a first terminal: $> sudo evemu-device mydevice.desc
- In a second: $> sudo evemu-play /dev/input/event12 < mydevice.events
It looks weird here, but it allows to inject different events
recording for the same virtual device node. Using the uinput node to
inject events will force us to change the user "interface" and rely on
pipes to get the same separation of describe/inject.
Note that I am modifying evemu-play to be able to also create the
virtual device, so I am not entirely convinced about this argument
(but we have users).
The other use case I should have mentioned in the commit message is
that we extensively rely on evemu for the xorg-integration-tests (and
the upcoming wayland test suite if I am not wrong).
The tests are fully automatized, and we need to know which input node
has just been created to record the correct one and test against it.
Ok, I am stopping here because Peter already answered about this in his mail :)
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH v3] input/uinput: add UI_GET_SYSNAME ioctl to retrieve the sysfs path
From: Peter Hutterer @ 2014-01-20 22:18 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Benjamin Tissoires, Benjamin Tissoires, David Herrmann,
linux-input, linux-kernel
In-Reply-To: <20140120215313.GB4270@core.coreip.homeip.net>
On Mon, Jan 20, 2014 at 01:53:13PM -0800, Dmitry Torokhov wrote:
> Hi Benjamin,
>
> On Fri, Jan 17, 2014 at 02:12:51PM -0500, Benjamin Tissoires 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.
>
> I have been thinking about it and I think that providing tight coupling
> between uinput and resulting event device is wrong thing to do. We do
> allow sending input events through uinput interface and I think evemu
> should be using it, instead of going halfway through uinput and halfway
> though evdev. Replaying though uinput would actually be more correct as
> it would involve the same code paths throgugh input core as with using
> real devices (see input_event() vs. input_inject_event() that is used by
> input handlers).
this isn't just about evemu. I've got a fair number of tests that create a
uinput device and then pass the device node to the next level. for example,
you may want to create a synaptics touchpad through uinput and then test the
xorg driver against it. I can't pass the uinput fd to the xorg driver, it
only takes a device node. in fact, virtually all the interactions I have
with uinput is of that form - create a device, hook something up to the
device and then do stuff. it's not the writing side that I need this ioctl
for, it's making sure whatever is _reading_ from it is hooked up to the
right device.
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH v3] input/uinput: add UI_GET_SYSNAME ioctl to retrieve the sysfs path
From: Dmitry Torokhov @ 2014-01-20 21:53 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Benjamin Tissoires, David Herrmann, Peter Hutterer, linux-input,
linux-kernel
In-Reply-To: <1389985971-541-1-git-send-email-benjamin.tissoires@redhat.com>
Hi Benjamin,
On Fri, Jan 17, 2014 at 02:12:51PM -0500, Benjamin Tissoires 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.
I have been thinking about it and I think that providing tight coupling
between uinput and resulting event device is wrong thing to do. We do
allow sending input events through uinput interface and I think evemu
should be using it, instead of going halfway through uinput and halfway
though evdev. Replaying though uinput would actually be more correct as
it would involve the same code paths throgugh input core as with using
real devices (see input_event() vs. input_inject_event() that is used by
input handlers).
Thanks.
--
Dmitry
^ permalink raw reply
* Re: Re: [PATCH] Introduce Naming Convention in Input Subsystem
From: Dmitry Torokhov @ 2014-01-20 21:49 UTC (permalink / raw)
To: Aniroop Mathur; +Cc: Benjamin Tissoires, linux-input, cpgs ., Aniroop Mathur
In-Reply-To: <CADYu309oDWRZGfnnNaBrwsP_uzCZsA_MS7KxOMBrGKPV9H6X8w@mail.gmail.com>
Hi Aniroop,
On Tue, Jan 21, 2014 at 01:34:07AM +0530, Aniroop Mathur wrote:
> Hello Mr Tissoires
> Greetings !!
>
> On Jan 20, 2014 11:54 PM, "Benjamin Tissoires" <benjamin.tissoires@gmail.com>
> wrote:
> >
> > Hi Aniroop,
> >
> > [sorry for top posting, but I really don't know where to put this
> regarding your answers].
> >
> No problem at all.
> In fact I am quite happy to hear from
> Linux community again
> Its my pleasure.
>
> > I _think_ I get one of the reasons you don't understand Dmitry, and why
> Dmitry does not understand you. From the different mails, I would say that
> you are referring to an Android platform.
> > If it's not the case, then sorry for the noise.
> >
> No I am not specifically referring to
> Android platform
> But yes, I am from android background
> and through android only I came up with
> this idea.
>
> > So, the last time I checked with android, this system does _not_ have an
> udev user-space daemon, which means that what you seem to be doing is
> parsing manually the sysfs tree to retrieve the inputs and their properties.
> > This, IMO, is a very bad idea. Parsing the entire sysfs tree is indeed
> costly and you will have to build everything by hand.
> >
> No, Android also have a daemon but it is not udev daemon. There is a
> separate daemon in android different from generic
> udev daemon. It is different but basic is
> still same.
> Just like udev daemon, android daemon
> also receives uevents from kernel
> and creates devfs nodes for us,
> that is /Dev/input/event1/2/3... based
> on uevent env variables.
> Android daemon is different from generic
> daemon in a sense it does not see any file
> like udev rules before creating nodes. Instead it directly create nodes as
> per uevent env variables in the structure.
> So without opening any extra udev rule
> file, it create nodes.
> So I understand it has also a limitation that it only has to be dependent
> only on default uevents and cannot read any sysfs attribute to identify the
> device if default uevents are not sufficient.
Why can it not?
>
> But the problem I am referring is for both in case of generic kernel and
> android kernel.
So far I really do not see it as generic kernel problem since we do have
existing infrastructure in userspace that is quite efficient.
>
> > On regular distros, we use udev. This daemon builds its device database
> from the events generated by the kernels directly (the uevents). Once the
> events are emitted, we never (except for some user-space drivers) use them
> in the kernel drivers (at least, I never saw that).
> >
> > So if you want to create symlinks, then indeed, you just add 2 or 3 rules
> in /etc/udev/rules.d, and then the user space (and the system integrator)
> can see the different devices with the "correct" symlink.
> > However, the kernel developer will never see them (and especially in the
> ->probe callback). However, the user-space tools which receives the udev
> events (emitted from udev, not the kernel this time) can easily retrieve
> many information from the event. Just run "udevadm info --export-db" on a
> regular Linux, and you will see that the device which presents the event
> node (/dev/input/eventX) has all the requirements to identify itself (VID,
> PID, path, etc...)
> >
> Yes udev gives so many uevents but as I checked through logs specifically
> in case of /Dev/input/event1/2/3/4....it does not give sufficient uevents
> to identify the device.
> As I found in logs it gives only 7 env variable like action, subsystem, Dev
> name, Dev path, major, minor and seq number.
> It does not give vendor Id or pid.
> Now with these uevent we cannot identify the input device whether its
> accelerometer or touchscreen. Can we ??
While information sent in uevent emitted for creation of event device
might not be enough to identify and classify input device you can:
1. Capture udevent sent a few moments earlier for the input device
itself, or
2. Read /sys/class/$DEVNAME/device/uevent to retrieve input device's
uevent data:
[dtor@dtor-d630 work]$ cat /sys/class/input/event6/uevent
MAJOR=13
MINOR=70
DEVNAME=input/event6
[dtor@dtor-d630 work]$ cat /sys/class/input/event6/device/uevent
PRODUCT=11/2/8/300
NAME="AlpsPS/2 ALPS DualPoint TouchPad"
PHYS="isa0060/serio1/input0"
PROP=8
EV=b
KEY=e420 70000 0 0 0 0
ABS=260800001000003
MODALIAS=input:b0011v0002p0008e0300-e0,1,3,k110,111,112,145,14A,14D,14E,14F,ra0,1,18,2F,35,36,39,mlsfw
[dtor@dtor-d630 work]$
That should give you plenty data to work with. Yes, the 2nd option
involves additional filesystem operations, but this is sysfs (so you are
not hitting real media) and you only need a few (open, read, and close)
per device.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
From: Vadim Klishko @ 2014-01-20 20:01 UTC (permalink / raw)
To: AJ Guillon; +Cc: linux-input, Tommy Will
In-Reply-To: <52DCB922.7020300@gmail.com>
Hello AJ,
I have heard from our customers before that using a touchpad is easier on one's hand than a mouse. Using a touchpad for moving and pointing should already reduce the strain. Being able to adjust touchpad settings may not give you any additional strain reduction benefits, but it could certainly make the experience of using a touchpad more pleasant.
But that is really beside the point. I am not trying to tell you what you need or don't need. You have the right to want a driver for your touchpad for whatever reason, and I sincerely apologize that we don't have one for Linux. We would really love to be able to provide one, but, unfortunately, we don't have one available. If we had, it would be a closed source user-space driver.
I can raise the question of reviving our Linux driver project with our management, but it might take a while before it is completed.
Can you suggest any other solution?
Sincerely,
Vadim
----- Original Message -----
From: "AJ Guillon" <aj.guillon@gmail.com>
To: "Vadim Klishko" <vadim@cirque.com>
Cc: <linux-input@vger.kernel.org>; "Tommy Will" <tommywill2011@gmail.com>
Sent: Sunday, January 19, 2014 10:50 PM
Subject: Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
> Hi Vadim,
>
> I'm a professional developer and it was suggested to me that I use a
> Cirque touchpad to reduce strain based on my work habits. Since 100% of
> my development is done on Linux systems, this touchpad is only useful to
> me in that environment.
>
> I'm not entirely sure what features this touchpad actually supports, but
> it would be nice if I could use it to its full potential. The side
> buttons, I suppose, are programmable so it would be nice for me to be
> able to set them to switch desktops or something. Ideally, I would like
> to script this touchpad as much as I can to reduce potential for injury.
>
> AJ
>
> On 14-01-20 12:40 AM, Vadim Klishko wrote:
>> Hi AJ,
>>
>> Apparently, the Linux kernel doesn't have support for that touchpad. In fact, I am not sure it has support for any USB touchpads.
>>
>> At one point, Cirque tried to create a driver for Linux, but we ran into legal issues with the GPL. We then started working on a user-space driver, but there didn't seem to be enough demand or interest in it, so we have never finished it.
>>
>> What kind of interesting things are you looking to do with the touchpad?
>>
>> Vadim
>>
>>
>> ----- Original Message -----
>> From: "AJ Guillon" <aj.guillon@gmail.com>
>> To: "Vadim Klishko" <vadim@cirque.com>
>> Cc: <linux-input@vger.kernel.org>; "Tommy Will" <tommywill2011@gmail.com>
>> Sent: Sunday, January 19, 2014 10:24 PM
>> Subject: Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
>>
>>
>> USB. Model GP415U-5321.
>>
>> AJ
>>
>> On 14-01-20 12:23 AM, Vadim Klishko wrote:
>>> Is it a USB or PS/2 touchpad?
>>>
>>>
>>> ----- Original Message -----
>>> From: "AJ Guillon" <aj.guillon@gmail.com>
>>> To: "Vadim Klishko" <vadim@cirque.com>
>>> Cc: <linux-input@vger.kernel.org>; "Tommy Will" <tommywill2011@gmail.com>
>>> Sent: Sunday, January 19, 2014 9:55 PM
>>> Subject: Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
>>>
>>>
>>> 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
>>>>>
>>>>
>>>
>>
--
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: Justin Clift @ 2014-01-20 19:13 UTC (permalink / raw)
To: Vadim Klishko; +Cc: linux-input, Tommy Will
In-Reply-To: <98E846BA153041B8A4860E2F12558E64@cirque.local>
On Mon, 20 Jan 2014 11:43:35 -0700
"Vadim Klishko" <vadim@cirque.com> wrote:
> On Sun, 20 Jan 2014 11:32 -0700
> "Justin Clift" <justin@gluster.org> wrote:
<snip>
> > Out of curiosity, do you remember offhand what the legal
> > issues you ran into are?
> >
> Yes, of course, I do. GPL doesn't allow closed source in kernel.
Ahhh, got it. :)
Yeah, wanting to keep the driver code closed source would
definitely be a problem there. ;>
> > If it's useful, we could (nicely) ask Red Hat's Legal team
> > for their insight and general thoughts/advice if they have
> > the time (no idea if they do).
> >
> > They're very good, and have lots of experience working
> > through GPL legal issues, figuring out practical
> > approaches/solutions.
> >
> > ?
>
> I doubt it will help.
You could be right. The only thing I can think of, is that
they might know of good ways for Cirque for become ok with
going open source for the USB touchpad drivers, instead of
keeping closed source.
eg some way to make the benefits of going open source be
greater than the benefits of keeping closed source
But, up to you. Not going to push it if you're not really
interested. :)
Regards and best wishes,
Justin Clift
--
GlusterFS Project: http://www.gluster.org
Justin Clift <justin@gluster.org>
^ permalink raw reply
* Re: [PATCH v3] input/uinput: add UI_GET_SYSNAME ioctl to retrieve the sysfs path
From: Benjamin Tissoires @ 2014-01-20 18:59 UTC (permalink / raw)
To: David Herrmann
Cc: Benjamin Tissoires, Dmitry Torokhov, Peter Hutterer,
open list:HID CORE LAYER, linux-kernel
In-Reply-To: <CANq1E4SHqy4Q3+iPZMoQjJnoNZTUw0YstLnsvto2E5GKv6XaSw@mail.gmail.com>
Hi David,
thanks for the review
On Sat, Jan 18, 2014 at 5:51 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> 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.
oh, yes, you are right.
>
> btw., you can also use: put_user(0, (char*)dest + len - 1);
k, will amend
>
>> + 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;".
yep, that was one of the thing which also made me some trouble by
re-reading the patch after this amount of time.
Either I can make a "goto out" patch before, or I can just add a bool
probe_variable_length which would be set be the previous default case.
The latter implies less changes, but might be more ugly than the previous.
Any preferences?
>
> Patch looks good to me.
Thanks!
Cheers,
Benjamin
> 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: ALPS: Cirque Smart Cat Pro AG Touchpad Support
From: Vadim Klishko @ 2014-01-20 18:43 UTC (permalink / raw)
To: Justin Clift; +Cc: linux-input, Tommy Will
In-Reply-To: <20140120183223.a68ab1f874c9d845082d9039@gluster.org>
----- Original Message -----
From: "Justin Clift" <justin@gluster.org>
To: "Vadim Klishko" <vadim@cirque.com>
Cc: <linux-input@vger.kernel.org>; "Tommy Will" <tommywill2011@gmail.com>
Sent: Monday, January 20, 2014 11:32 AM
Subject: Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
> On Sun, 19 Jan 2014 22:40:12 -0700
> "Vadim Klishko" <vadim@cirque.com> wrote:
> <snip>
>> At one point, Cirque tried to create a driver for Linux,
>> but we ran into legal issues with the GPL.
>
> Out of curiosity, do you remember offhand what the legal
> issues you ran into are?
>
Yes, of course, I do. GPL doesn't allow closed source in kernel.
> If it's useful, we could (nicely) ask Red Hat's Legal team
> for their insight and general thoughts/advice if they have
> the time (no idea if they do).
>
> They're very good, and have lots of experience working
> through GPL legal issues, figuring out practical
> approaches/solutions.
>
> ?
I doubt it will help.
>
> Regards and best wishes,
>
> Justin Clift
>
> --
> GlusterFS Project: http://cp.mcafee.com/d/avndy0OczhJ5AQsTjoj7cECXCQQkmnSjhOOM-rjhhpsjKC-Crjhhps78EIK6QQkmn6nChO9IPG4BglqkhpL-ndSB4mr_BPuWgsggjvW_9CzB5VBNXHTbFTopVx4QsFK9LYJt6OaaGaafaxVZicHs3jq9J4TvAm4TDNOb2pEVdTdw0y9Xt9_7w09IhrFek0khfrFfUY01dFLIc6MnWhEw40G5xx8Qg2kEyPvCy0olScPh09rcQg1qdjh0818Qg0CHtyqSE6y0ormmH6pKVIPQMguVePDaW
> Justin Clift <justin@gluster.org>
>
--
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: Justin Clift @ 2014-01-20 18:32 UTC (permalink / raw)
To: Vadim Klishko; +Cc: linux-input, Tommy Will
In-Reply-To: <4451DE5582E243FDA7455A649E172C7F@HITLER>
On Sun, 19 Jan 2014 22:40:12 -0700
"Vadim Klishko" <vadim@cirque.com> wrote:
<snip>
> At one point, Cirque tried to create a driver for Linux,
> but we ran into legal issues with the GPL.
Out of curiosity, do you remember offhand what the legal
issues you ran into are?
If it's useful, we could (nicely) ask Red Hat's Legal team
for their insight and general thoughts/advice if they have
the time (no idea if they do).
They're very good, and have lots of experience working
through GPL legal issues, figuring out practical
approaches/solutions.
?
Regards and best wishes,
Justin Clift
--
GlusterFS Project: http://www.gluster.org
Justin Clift <justin@gluster.org>
^ permalink raw reply
* Re: Re: [PATCH] Introduce Naming Convention in Input Subsystem
From: Benjamin Tissoires @ 2014-01-20 18:27 UTC (permalink / raw)
To: Aniroop Mathur
Cc: Dmitry Torokhov, Aniroop Mathur, linux-input@vger.kernel.org,
cpgs .
In-Reply-To: <CAN+gG=HXcjmBcaxaBJczMWjNdKXdFiZzQGducQwMU6mdrS-R0Q@mail.gmail.com>
OK, sorry for the noise, my previous message contained HTML and was
refused by the server... Re-posting it
Cheers,
Benjamin
On Mon, Jan 20, 2014 at 1:24 PM, Benjamin Tissoires
<benjamin.tissoires@gmail.com> wrote:
> Hi Aniroop,
>
> [sorry for top posting, but I really don't know where to put this regarding
> your answers].
>
> I _think_ I get one of the reasons you don't understand Dmitry, and why
> Dmitry does not understand you. From the different mails, I would say that
> you are referring to an Android platform.
> If it's not the case, then sorry for the noise.
>
> So, the last time I checked with android, this system does _not_ have an
> udev user-space daemon, which means that what you seem to be doing is
> parsing manually the sysfs tree to retrieve the inputs and their properties.
> This, IMO, is a very bad idea. Parsing the entire sysfs tree is indeed
> costly and you will have to build everything by hand.
>
> On regular distros, we use udev. This daemon builds its device database from
> the events generated by the kernels directly (the uevents). Once the events
> are emitted, we never (except for some user-space drivers) use them in the
> kernel drivers (at least, I never saw that).
>
> So if you want to create symlinks, then indeed, you just add 2 or 3 rules in
> /etc/udev/rules.d, and then the user space (and the system integrator) can
> see the different devices with the "correct" symlink.
> However, the kernel developer will never see them (and especially in the
> ->probe callback). However, the user-space tools which receives the udev
> events (emitted from udev, not the kernel this time) can easily retrieve
> many information from the event. Just run "udevadm info --export-db" on a
> regular Linux, and you will see that the device which presents the event
> node (/dev/input/eventX) has all the requirements to identify itself (VID,
> PID, path, etc...)
>
> Without udev, you are basically screwed, and I think it is definitively not
> the fault of the kernel, but of android. They had their reasons to not
> include it, so I hope they have an equivalent to help system integrators to
> do their job.
>
> Cheers,
> Benjamin
>
>
>
> On Sun, Jan 19, 2014 at 10:19 AM, Aniroop Mathur <aniroop.mathur@gmail.com>
> wrote:
>>
>> 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
>> --
>> 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: LOCAL MAP OPTIMIZATION FOR : mail-archive.com (Less Than $99/Month)
From: airstream58429 @ 2014-01-20 17:52 UTC (permalink / raw)
To: linux-input
Good Morning Sir / Mam
Is your business ranking in local maps shown on PAGE 1 of google ? With new
google policies they have specifically asked local business owners to
optimize their website for local maps rather than JUST organics. Do you know
the reason why you are not ranked well on google MAPs or why there is drop
in your website rankings? Prime reason for bad rankings for a busniess is
lack of local presence and local citations ie getting your business listed
on directories like YELP, MANTA & Many more. These websites not just give
your business a push but also help you Maintain a good Online Reputation.
Why you need to optimize your website for local MAP Listings ?
- MAP listings get 10 times more clicks than organic listings
- Increased conversions because of real reviews posted on your Google Plus
Page
- Every year there is 30% increase in searches for local keywords
- Increases legitimacy of a Business
We will help you get your website ranked well on google for the related
keywords in your niche. We specialize in LOCAL SEARCH ENGINE OPTIMIZATION
increasing visibility for small businesses by ranking them for
geographically-related keywords. Say for eg-: you want to search a plumber
in your city, You will be typing in keywords like Plumbers + City Or
Plumbers + IN + City. We make sure your website comes in google MAP listings
shown on page 1 for each such keyword.
Now Google believes in - BE ORIGINAL, HAVE ORIGINAL AND GIVE ORIGINAL which
means that google wants to end up that frustrating experience of users who
are searching for Service Or Product and seeing the results that are not
even close to what they are looking for. Google only wants to give their
user original and relevant results. This makes it even more important that
we showcase our business in the best possible way and make sure our website
in valued high by google.
We at TheLOCALIST will make google feel the importance of your business by
following their guidelines thus ranking your website higher in serach
results. We are presently offering LOCAL OPTIMIZATION to more than 400
websites and they all rank page 1 for all possible keywords !!! Each month
your website is submitted to more than 50 citations and social presence is
controlled by posting videos and blogs all over the web.
Email us back with your website & phone number so we can discuss this
further with you. Our Packages start from as low as 99$/month.
Thanks For Taking Time To Read Our Email
Polly Martin
Local SEO Manager ( THE Localist )
Address : 24 ST Suite 32 Downtown Provo Utah
-------------------
NOT INTERESTED ? REPLY WITH NOT INTERESTED IN THE SUBJECT LINE
^ permalink raw reply
* Re: T440s Synaptics clickpad: lost sync / KBC bad data
From: Vadim Fint @ 2014-01-20 17:50 UTC (permalink / raw)
To: linux-input
Hello!
I was having exactly the same issues with brand new T440s from Lenovo. psmouse
get lost sync every time I did a physical click on clickpad.
But for me that was HW issue: after disassembling notebook I saw touchpad
cable was not snapped into touchpad at all. Because latch (with cable) moves
2-3mm each click -- what was bad contact during that.
To deal with that issue I did removed only internal battery pack and locked a
cable on touchpad with a screwdriver :) (15-20 minutes for whole operation)
Dont know what Windows internaly do with synaptics protocol, but there was no
issues in Windows at all (but in recovery mode clickpad was not working at
all).
Anyway, no problems in Gentoo with 3.12-3-pf kernel for me now! And no more
that weird “out of sync” messages from psmouse at all.
Hope this helps!!
> Hello everyone,
>
> I hope I'm at the right address here with my problems. If not, please do
> point me in the correct direction.
>
> I have a Lenovo Thinkpad T440s with a Synaptics clickpad and an IBM
> trackpoint in it:
>
> input: PS/2 Synaptics TouchPad as
> /devices/platform/i8042/serio1/input/input120 psmouse serio1: synaptics:
> Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd001a3/0x940300/0x127c00,
> board id: 2668, fw id: 1293989 psmouse serio1: synaptics: serio: Synaptics
> pass-through port at isa0060/serio1/input0 input: SynPS/2 Synaptics
> TouchPad as /devices/platform/i8042/serio1/input/input123 psmouse serio34:
> alps: Unknown ALPS touchpad: E7=10 00 64, EC=10 00 64 psmouse serio34:
> trackpoint: IBM TrackPoint firmware: 0x0e, buttons: 3/3 input: TPPS/2 IBM
> TrackPoint as /devices/platform/i8042/serio1/serio34/input/input124
>
> The problem is that the trackpoint behaves incredibly erratic, sometimes
> working correctly for minutes at a time, sometimes just jumping around and
> many times just hanging. I need to remove and re-insert the psmouse module
> to solve that. Alongside this behaviour, my kernel log also is getting
> spammed with messages like:
>
> psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
> psmouse serio1: TouchPad at isa0060/serio1/input0 - driver resynced.
> and psmouse serio1: bad data from KBC - timeout
>
> What I've tried:
> - Tried the kernel options i8042.nomux=1 and i8042.reset=1
> - Disable acpi by passing acpi=off to the kernel
> - Disabled CPU frequency scaling
> - Trying other protocols, e.g. by doing modprobe psmouse proto=imps or
> proto=bare - Switching from vanilla 3.12 kernel to both the latest&greatest
> kernel from Linus' Git and an antique 3.1.0 kernel - Turning on
> i8042.debug. To my untrained eye, it looks like bytes of PS/2 data are just
> disappearing when the 'lost sync' messages kick in. I can give an example
> of that if needed.
>
> Strangely, the symptoms have been getting worse in the 10 days I've had this
> machine: from the first few days with no trouble to today with the mouse
> crapping out almost once every ten seconds or so. I would say it's a DOA
> and claim my warranty, if not frustratingly the machine works perfectly
> fine in Windows 8, with no touchpad trouble at all.
>
> I'm willing to try things on this machine, run patches or take any hint in
> what I can change to get this working; if it helps I can even poke an
> oscilloscope at the PS2 lines. Not having a working touchpad or touchpoint
> is getting a bit frustrating...
>
> Cheers,
> Jeroen
--
Regards,
Vadim Fint,
Moscow, Ru.
--
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 2/2] Use colors for the Dualshock 4 LED names
From: Frank Praznik @ 2014-01-20 17:27 UTC (permalink / raw)
To: linux-input; +Cc: jkosina, Frank Praznik
In-Reply-To: <1390238822-18164-1-git-send-email-frank.praznik@oh.rr.com>
Use the naming scheme 'devicename:colour' for the Dualshock 4
LED lightbar controls as specified in Documentation/leds/leds-class.txt
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
---
Apply against jikos/hid.git/for-3.14/sony
drivers/hid/hid-sony.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 62765c7..1235405 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -834,33 +834,39 @@ static int sony_leds_init(struct hid_device *hdev)
struct sony_sc *drv_data;
int n, ret = 0;
int max_brightness;
+ int use_colors;
struct led_classdev *led;
size_t name_sz;
char *name;
size_t name_len;
const char *name_fmt;
+ static const char * const color_str[] = { "red", "green", "blue" };
static const __u8 initial_values[MAX_LEDS] = { 0x00, 0x00, 0x00, 0x00 };
drv_data = hid_get_drvdata(hdev);
BUG_ON(!(drv_data->quirks & SONY_LED_SUPPORT));
if (drv_data->quirks & BUZZ_CONTROLLER) {
+ drv_data->led_count = 4;
+ max_brightness = 1;
+ use_colors = 0;
name_len = strlen("::buzz#");
name_fmt = "%s::buzz%d";
/* Validate expected report characteristics. */
if (!hid_validate_values(hdev, HID_OUTPUT_REPORT, 0, 0, 7))
return -ENODEV;
- } else {
- name_len = strlen("::sony#");
- name_fmt = "%s::sony%d";
- }
-
- if (drv_data->quirks & DUALSHOCK4_CONTROLLER_USB) {
+ } else if (drv_data->quirks & DUALSHOCK4_CONTROLLER_USB) {
drv_data->led_count = 3;
max_brightness = 255;
+ use_colors = 1;
+ name_len = 0;
+ name_fmt = "%s:%s";
} else {
drv_data->led_count = 4;
max_brightness = 1;
+ use_colors = 0;
+ name_len = strlen("::sony#");
+ name_fmt = "%s::sony%d";
}
/* Clear LEDs as we have no way of reading their initial state. This is
@@ -871,6 +877,10 @@ static int sony_leds_init(struct hid_device *hdev)
name_sz = strlen(dev_name(&hdev->dev)) + name_len + 1;
for (n = 0; n < drv_data->led_count; n++) {
+
+ if (use_colors)
+ name_sz = strlen(dev_name(&hdev->dev)) + strlen(color_str[n]) + 2;
+
led = kzalloc(sizeof(struct led_classdev) + name_sz, GFP_KERNEL);
if (!led) {
hid_err(hdev, "Couldn't allocate memory for LED %d\n", n);
@@ -879,7 +889,10 @@ static int sony_leds_init(struct hid_device *hdev)
}
name = (void *)(&led[1]);
- snprintf(name, name_sz, name_fmt, dev_name(&hdev->dev), n + 1);
+ if (use_colors)
+ snprintf(name, name_sz, name_fmt, dev_name(&hdev->dev), color_str[n]);
+ else
+ snprintf(name, name_sz, name_fmt, dev_name(&hdev->dev), n + 1);
led->name = name;
led->brightness = 0;
led->max_brightness = max_brightness;
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/2] Add annotated HID descriptor for the Dualshock 4.
From: Frank Praznik @ 2014-01-20 17:27 UTC (permalink / raw)
To: linux-input; +Cc: jkosina, Frank Praznik
Add annotated HID descriptor for the Dualshock 4.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
---
Apply against jikos/hid.git/for-3.14/sony
drivers/hid/hid-sony.c | 320 +++++++++++++++++++++++++++++++++++++++----------
1 file changed, 256 insertions(+), 64 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 9013005..62765c7 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -73,71 +73,263 @@ static const u8 sixaxis_rdesc_fixup2[] = {
0xb1, 0x02, 0xc0, 0xc0,
};
+/* The default descriptor doesn't provide mapping for the accelerometers
+ * or orientation sensors. This fixed descriptor maps the accelerometers
+ * to usage values 0x40, 0x41 and 0x42 and maps the orientation sensors
+ * to usage values 0x43, 0x44 and 0x45.
+ */
static u8 dualshock4_usb_rdesc[] = {
- 0x05, 0x01, 0x09, 0x05, 0xa1, 0x01, 0x85, 0x01,
- 0x09, 0x30, 0x09, 0x31, 0x09, 0x32, 0x09, 0x35,
- 0x15, 0x00, 0x26, 0xff, 0x00, 0x75, 0x08, 0x95,
- 0x04, 0x81, 0x02, 0x09, 0x39, 0x15, 0x00, 0x25,
- 0x07, 0x35, 0x00, 0x46, 0x3b, 0x01, 0x65, 0x14,
- 0x75, 0x04, 0x95, 0x01, 0x81, 0x42, 0x65, 0x00,
- 0x05, 0x09, 0x19, 0x01, 0x29, 0x0e, 0x15, 0x00,
- 0x25, 0x01, 0x75, 0x01, 0x95, 0x0e, 0x81, 0x02,
- 0x06, 0x00, 0xff, 0x09, 0x20, 0x75, 0x06, 0x95,
- 0x01, 0x15, 0x00, 0x25, 0x7f, 0x81, 0x02, 0x05,
- 0x01, 0x09, 0x33, 0x09, 0x34, 0x15, 0x00, 0x26,
- 0xff, 0x00, 0x75, 0x08, 0x95, 0x02, 0x81, 0x02,
- 0x06, 0x00, 0xff, 0x09, 0x21, 0x95, 0x03, 0x81,
- 0x02, 0x05, 0x01, 0x19, 0x40, 0x29, 0x42, 0x16,
- 0x00, 0x80, 0x26, 0x00, 0x7f, 0x75, 0x10, 0x95,
- 0x03, 0x81, 0x02, 0x05, 0x01, 0x19, 0x43, 0x29,
- 0x45, 0x16, 0xff, 0xbf, 0x26, 0x00, 0x40, 0x95,
- 0x03, 0x81, 0x02, 0x06, 0x00, 0xff, 0x09, 0x21,
- 0x75, 0x08, 0x95, 0x27, 0x81, 0x02, 0x85, 0x05,
- 0x09, 0x22, 0x95, 0x1f, 0x91, 0x02, 0x85, 0x04,
- 0x09, 0x23, 0x95, 0x24, 0xb1, 0x02, 0x85, 0x02,
- 0x09, 0x24, 0x95, 0x24, 0xb1, 0x02, 0x85, 0x08,
- 0x09, 0x25, 0x95, 0x03, 0xb1, 0x02, 0x85, 0x10,
- 0x09, 0x26, 0x95, 0x04, 0xb1, 0x02, 0x85, 0x11,
- 0x09, 0x27, 0x95, 0x02, 0xb1, 0x02, 0x85, 0x12,
- 0x06, 0x02, 0xff, 0x09, 0x21, 0x95, 0x0f, 0xb1,
- 0x02, 0x85, 0x13, 0x09, 0x22, 0x95, 0x16, 0xb1,
- 0x02, 0x85, 0x14, 0x06, 0x05, 0xff, 0x09, 0x20,
- 0x95, 0x10, 0xb1, 0x02, 0x85, 0x15, 0x09, 0x21,
- 0x95, 0x2c, 0xb1, 0x02, 0x06, 0x80, 0xff, 0x85,
- 0x80, 0x09, 0x20, 0x95, 0x06, 0xb1, 0x02, 0x85,
- 0x81, 0x09, 0x21, 0x95, 0x06, 0xb1, 0x02, 0x85,
- 0x82, 0x09, 0x22, 0x95, 0x05, 0xb1, 0x02, 0x85,
- 0x83, 0x09, 0x23, 0x95, 0x01, 0xb1, 0x02, 0x85,
- 0x84, 0x09, 0x24, 0x95, 0x04, 0xb1, 0x02, 0x85,
- 0x85, 0x09, 0x25, 0x95, 0x06, 0xb1, 0x02, 0x85,
- 0x86, 0x09, 0x26, 0x95, 0x06, 0xb1, 0x02, 0x85,
- 0x87, 0x09, 0x27, 0x95, 0x23, 0xb1, 0x02, 0x85,
- 0x88, 0x09, 0x28, 0x95, 0x22, 0xb1, 0x02, 0x85,
- 0x89, 0x09, 0x29, 0x95, 0x02, 0xb1, 0x02, 0x85,
- 0x90, 0x09, 0x30, 0x95, 0x05, 0xb1, 0x02, 0x85,
- 0x91, 0x09, 0x31, 0x95, 0x03, 0xb1, 0x02, 0x85,
- 0x92, 0x09, 0x32, 0x95, 0x03, 0xb1, 0x02, 0x85,
- 0x93, 0x09, 0x33, 0x95, 0x0c, 0xb1, 0x02, 0x85,
- 0xa0, 0x09, 0x40, 0x95, 0x06, 0xb1, 0x02, 0x85,
- 0xa1, 0x09, 0x41, 0x95, 0x01, 0xb1, 0x02, 0x85,
- 0xa2, 0x09, 0x42, 0x95, 0x01, 0xb1, 0x02, 0x85,
- 0xa3, 0x09, 0x43, 0x95, 0x30, 0xb1, 0x02, 0x85,
- 0xa4, 0x09, 0x44, 0x95, 0x0d, 0xb1, 0x02, 0x85,
- 0xa5, 0x09, 0x45, 0x95, 0x15, 0xb1, 0x02, 0x85,
- 0xa6, 0x09, 0x46, 0x95, 0x15, 0xb1, 0x02, 0x85,
- 0xf0, 0x09, 0x47, 0x95, 0x3f, 0xb1, 0x02, 0x85,
- 0xf1, 0x09, 0x48, 0x95, 0x3f, 0xb1, 0x02, 0x85,
- 0xf2, 0x09, 0x49, 0x95, 0x0f, 0xb1, 0x02, 0x85,
- 0xa7, 0x09, 0x4a, 0x95, 0x01, 0xb1, 0x02, 0x85,
- 0xa8, 0x09, 0x4b, 0x95, 0x01, 0xb1, 0x02, 0x85,
- 0xa9, 0x09, 0x4c, 0x95, 0x08, 0xb1, 0x02, 0x85,
- 0xaa, 0x09, 0x4e, 0x95, 0x01, 0xb1, 0x02, 0x85,
- 0xab, 0x09, 0x4f, 0x95, 0x39, 0xb1, 0x02, 0x85,
- 0xac, 0x09, 0x50, 0x95, 0x39, 0xb1, 0x02, 0x85,
- 0xad, 0x09, 0x51, 0x95, 0x0b, 0xb1, 0x02, 0x85,
- 0xae, 0x09, 0x52, 0x95, 0x01, 0xb1, 0x02, 0x85,
- 0xaf, 0x09, 0x53, 0x95, 0x02, 0xb1, 0x02, 0x85,
- 0xb0, 0x09, 0x54, 0x95, 0x3f, 0xb1, 0x02, 0xc0,
+ 0x05, 0x01, /* Usage Page (Desktop), */
+ 0x09, 0x05, /* Usage (Gamepad), */
+ 0xA1, 0x01, /* Collection (Application), */
+ 0x85, 0x01, /* Report ID (1), */
+ 0x09, 0x30, /* Usage (X), */
+ 0x09, 0x31, /* Usage (Y), */
+ 0x09, 0x32, /* Usage (Z), */
+ 0x09, 0x35, /* Usage (Rz), */
+ 0x15, 0x00, /* Logical Minimum (0), */
+ 0x26, 0xFF, 0x00, /* Logical Maximum (255), */
+ 0x75, 0x08, /* Report Size (8), */
+ 0x95, 0x04, /* Report Count (4), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x09, 0x39, /* Usage (Hat Switch), */
+ 0x15, 0x00, /* Logical Minimum (0), */
+ 0x25, 0x07, /* Logical Maximum (7), */
+ 0x35, 0x00, /* Physical Minimum (0), */
+ 0x46, 0x3B, 0x01, /* Physical Maximum (315), */
+ 0x65, 0x14, /* Unit (Degrees), */
+ 0x75, 0x04, /* Report Size (4), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0x81, 0x42, /* Input (Variable, Null State), */
+ 0x65, 0x00, /* Unit, */
+ 0x05, 0x09, /* Usage Page (Button), */
+ 0x19, 0x01, /* Usage Minimum (01h), */
+ 0x29, 0x0E, /* Usage Maximum (0Eh), */
+ 0x15, 0x00, /* Logical Minimum (0), */
+ 0x25, 0x01, /* Logical Maximum (1), */
+ 0x75, 0x01, /* Report Size (1), */
+ 0x95, 0x0E, /* Report Count (14), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x06, 0x00, 0xFF, /* Usage Page (FF00h), */
+ 0x09, 0x20, /* Usage (20h), */
+ 0x75, 0x06, /* Report Size (6), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0x15, 0x00, /* Logical Minimum (0), */
+ 0x25, 0x7F, /* Logical Maximum (127), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x05, 0x01, /* Usage Page (Desktop), */
+ 0x09, 0x33, /* Usage (Rx), */
+ 0x09, 0x34, /* Usage (Ry), */
+ 0x15, 0x00, /* Logical Minimum (0), */
+ 0x26, 0xFF, 0x00, /* Logical Maximum (255), */
+ 0x75, 0x08, /* Report Size (8), */
+ 0x95, 0x02, /* Report Count (2), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x06, 0x00, 0xFF, /* Usage Page (FF00h), */
+ 0x09, 0x21, /* Usage (21h), */
+ 0x95, 0x03, /* Report Count (3), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x05, 0x01, /* Usage Page (Desktop), */
+ 0x19, 0x40, /* Usage Minimum (40h), */
+ 0x29, 0x42, /* Usage Maximum (42h), */
+ 0x16, 0x00, 0x80, /* Logical Minimum (-32768), */
+ 0x26, 0x00, 0x7F, /* Logical Maximum (32767), */
+ 0x75, 0x10, /* Report Size (16), */
+ 0x95, 0x03, /* Report Count (3), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x19, 0x43, /* Usage Minimum (43h), */
+ 0x29, 0x45, /* Usage Maximum (45h), */
+ 0x16, 0xFF, 0xBF, /* Logical Minimum (-16385), */
+ 0x26, 0x00, 0x40, /* Logical Maximum (16384), */
+ 0x95, 0x03, /* Report Count (3), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x06, 0x00, 0xFF, /* Usage Page (FF00h), */
+ 0x09, 0x21, /* Usage (21h), */
+ 0x15, 0x00, /* Logical Minimum (0), */
+ 0x25, 0xFF, /* Logical Maximum (255), */
+ 0x75, 0x08, /* Report Size (8), */
+ 0x95, 0x27, /* Report Count (39), */
+ 0x81, 0x02, /* Input (Variable), */
+ 0x85, 0x05, /* Report ID (5), */
+ 0x09, 0x22, /* Usage (22h), */
+ 0x95, 0x1F, /* Report Count (31), */
+ 0x91, 0x02, /* Output (Variable), */
+ 0x85, 0x04, /* Report ID (4), */
+ 0x09, 0x23, /* Usage (23h), */
+ 0x95, 0x24, /* Report Count (36), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x02, /* Report ID (2), */
+ 0x09, 0x24, /* Usage (24h), */
+ 0x95, 0x24, /* Report Count (36), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x08, /* Report ID (8), */
+ 0x09, 0x25, /* Usage (25h), */
+ 0x95, 0x03, /* Report Count (3), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x10, /* Report ID (16), */
+ 0x09, 0x26, /* Usage (26h), */
+ 0x95, 0x04, /* Report Count (4), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x11, /* Report ID (17), */
+ 0x09, 0x27, /* Usage (27h), */
+ 0x95, 0x02, /* Report Count (2), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x12, /* Report ID (18), */
+ 0x06, 0x02, 0xFF, /* Usage Page (FF02h), */
+ 0x09, 0x21, /* Usage (21h), */
+ 0x95, 0x0F, /* Report Count (15), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x13, /* Report ID (19), */
+ 0x09, 0x22, /* Usage (22h), */
+ 0x95, 0x16, /* Report Count (22), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x14, /* Report ID (20), */
+ 0x06, 0x05, 0xFF, /* Usage Page (FF05h), */
+ 0x09, 0x20, /* Usage (20h), */
+ 0x95, 0x10, /* Report Count (16), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x15, /* Report ID (21), */
+ 0x09, 0x21, /* Usage (21h), */
+ 0x95, 0x2C, /* Report Count (44), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x06, 0x80, 0xFF, /* Usage Page (FF80h), */
+ 0x85, 0x80, /* Report ID (128), */
+ 0x09, 0x20, /* Usage (20h), */
+ 0x95, 0x06, /* Report Count (6), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x81, /* Report ID (129), */
+ 0x09, 0x21, /* Usage (21h), */
+ 0x95, 0x06, /* Report Count (6), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x82, /* Report ID (130), */
+ 0x09, 0x22, /* Usage (22h), */
+ 0x95, 0x05, /* Report Count (5), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x83, /* Report ID (131), */
+ 0x09, 0x23, /* Usage (23h), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x84, /* Report ID (132), */
+ 0x09, 0x24, /* Usage (24h), */
+ 0x95, 0x04, /* Report Count (4), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x85, /* Report ID (133), */
+ 0x09, 0x25, /* Usage (25h), */
+ 0x95, 0x06, /* Report Count (6), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x86, /* Report ID (134), */
+ 0x09, 0x26, /* Usage (26h), */
+ 0x95, 0x06, /* Report Count (6), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x87, /* Report ID (135), */
+ 0x09, 0x27, /* Usage (27h), */
+ 0x95, 0x23, /* Report Count (35), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x88, /* Report ID (136), */
+ 0x09, 0x28, /* Usage (28h), */
+ 0x95, 0x22, /* Report Count (34), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x89, /* Report ID (137), */
+ 0x09, 0x29, /* Usage (29h), */
+ 0x95, 0x02, /* Report Count (2), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x90, /* Report ID (144), */
+ 0x09, 0x30, /* Usage (30h), */
+ 0x95, 0x05, /* Report Count (5), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x91, /* Report ID (145), */
+ 0x09, 0x31, /* Usage (31h), */
+ 0x95, 0x03, /* Report Count (3), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x92, /* Report ID (146), */
+ 0x09, 0x32, /* Usage (32h), */
+ 0x95, 0x03, /* Report Count (3), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0x93, /* Report ID (147), */
+ 0x09, 0x33, /* Usage (33h), */
+ 0x95, 0x0C, /* Report Count (12), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xA0, /* Report ID (160), */
+ 0x09, 0x40, /* Usage (40h), */
+ 0x95, 0x06, /* Report Count (6), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xA1, /* Report ID (161), */
+ 0x09, 0x41, /* Usage (41h), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xA2, /* Report ID (162), */
+ 0x09, 0x42, /* Usage (42h), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xA3, /* Report ID (163), */
+ 0x09, 0x43, /* Usage (43h), */
+ 0x95, 0x30, /* Report Count (48), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xA4, /* Report ID (164), */
+ 0x09, 0x44, /* Usage (44h), */
+ 0x95, 0x0D, /* Report Count (13), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xA5, /* Report ID (165), */
+ 0x09, 0x45, /* Usage (45h), */
+ 0x95, 0x15, /* Report Count (21), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xA6, /* Report ID (166), */
+ 0x09, 0x46, /* Usage (46h), */
+ 0x95, 0x15, /* Report Count (21), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xF0, /* Report ID (240), */
+ 0x09, 0x47, /* Usage (47h), */
+ 0x95, 0x3F, /* Report Count (63), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xF1, /* Report ID (241), */
+ 0x09, 0x48, /* Usage (48h), */
+ 0x95, 0x3F, /* Report Count (63), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xF2, /* Report ID (242), */
+ 0x09, 0x49, /* Usage (49h), */
+ 0x95, 0x0F, /* Report Count (15), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xA7, /* Report ID (167), */
+ 0x09, 0x4A, /* Usage (4Ah), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xA8, /* Report ID (168), */
+ 0x09, 0x4B, /* Usage (4Bh), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xA9, /* Report ID (169), */
+ 0x09, 0x4C, /* Usage (4Ch), */
+ 0x95, 0x08, /* Report Count (8), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xAA, /* Report ID (170), */
+ 0x09, 0x4E, /* Usage (4Eh), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xAB, /* Report ID (171), */
+ 0x09, 0x4F, /* Usage (4Fh), */
+ 0x95, 0x39, /* Report Count (57), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xAC, /* Report ID (172), */
+ 0x09, 0x50, /* Usage (50h), */
+ 0x95, 0x39, /* Report Count (57), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xAD, /* Report ID (173), */
+ 0x09, 0x51, /* Usage (51h), */
+ 0x95, 0x0B, /* Report Count (11), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xAE, /* Report ID (174), */
+ 0x09, 0x52, /* Usage (52h), */
+ 0x95, 0x01, /* Report Count (1), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xAF, /* Report ID (175), */
+ 0x09, 0x53, /* Usage (53h), */
+ 0x95, 0x02, /* Report Count (2), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0x85, 0xB0, /* Report ID (176), */
+ 0x09, 0x54, /* Usage (54h), */
+ 0x95, 0x3F, /* Report Count (63), */
+ 0xB1, 0x02, /* Feature (Variable), */
+ 0xC0 /* End Collection */
};
static __u8 ps3remote_rdesc[] = {
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH v2] HID: sony: Cache the output report for the Dualshock 4
From: Jiri Kosina @ 2014-01-20 12:02 UTC (permalink / raw)
To: David Herrmann; +Cc: Frank Praznik, open list:HID CORE LAYER
In-Reply-To: <CANq1E4QH_XbShAMQrCAW46dKkP7wmz6jRjA0+3xE0ag=fhDHQQ@mail.gmail.com>
On Sat, 18 Jan 2014, David Herrmann 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>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
From: AJ Guillon @ 2014-01-20 5:50 UTC (permalink / raw)
To: Vadim Klishko; +Cc: linux-input, Tommy Will
In-Reply-To: <4451DE5582E243FDA7455A649E172C7F@HITLER>
Hi Vadim,
I'm a professional developer and it was suggested to me that I use a
Cirque touchpad to reduce strain based on my work habits. Since 100% of
my development is done on Linux systems, this touchpad is only useful to
me in that environment.
I'm not entirely sure what features this touchpad actually supports, but
it would be nice if I could use it to its full potential. The side
buttons, I suppose, are programmable so it would be nice for me to be
able to set them to switch desktops or something. Ideally, I would like
to script this touchpad as much as I can to reduce potential for injury.
AJ
On 14-01-20 12:40 AM, Vadim Klishko wrote:
> Hi AJ,
>
> Apparently, the Linux kernel doesn't have support for that touchpad. In fact, I am not sure it has support for any USB touchpads.
>
> At one point, Cirque tried to create a driver for Linux, but we ran into legal issues with the GPL. We then started working on a user-space driver, but there didn't seem to be enough demand or interest in it, so we have never finished it.
>
> What kind of interesting things are you looking to do with the touchpad?
>
> Vadim
>
>
> ----- Original Message -----
> From: "AJ Guillon" <aj.guillon@gmail.com>
> To: "Vadim Klishko" <vadim@cirque.com>
> Cc: <linux-input@vger.kernel.org>; "Tommy Will" <tommywill2011@gmail.com>
> Sent: Sunday, January 19, 2014 10:24 PM
> Subject: Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
>
>
> USB. Model GP415U-5321.
>
> AJ
>
> On 14-01-20 12:23 AM, Vadim Klishko wrote:
>> Is it a USB or PS/2 touchpad?
>>
>>
>> ----- Original Message -----
>> From: "AJ Guillon" <aj.guillon@gmail.com>
>> To: "Vadim Klishko" <vadim@cirque.com>
>> Cc: <linux-input@vger.kernel.org>; "Tommy Will" <tommywill2011@gmail.com>
>> Sent: Sunday, January 19, 2014 9:55 PM
>> Subject: Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
>>
>>
>> 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 5:40 UTC (permalink / raw)
To: AJ Guillon; +Cc: linux-input, Tommy Will
In-Reply-To: <52DCB323.6070200@gmail.com>
Hi AJ,
Apparently, the Linux kernel doesn't have support for that touchpad. In fact, I am not sure it has support for any USB touchpads.
At one point, Cirque tried to create a driver for Linux, but we ran into legal issues with the GPL. We then started working on a user-space driver, but there didn't seem to be enough demand or interest in it, so we have never finished it.
What kind of interesting things are you looking to do with the touchpad?
Vadim
----- Original Message -----
From: "AJ Guillon" <aj.guillon@gmail.com>
To: "Vadim Klishko" <vadim@cirque.com>
Cc: <linux-input@vger.kernel.org>; "Tommy Will" <tommywill2011@gmail.com>
Sent: Sunday, January 19, 2014 10:24 PM
Subject: Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
USB. Model GP415U-5321.
AJ
On 14-01-20 12:23 AM, Vadim Klishko wrote:
> Is it a USB or PS/2 touchpad?
>
>
> ----- Original Message -----
> From: "AJ Guillon" <aj.guillon@gmail.com>
> To: "Vadim Klishko" <vadim@cirque.com>
> Cc: <linux-input@vger.kernel.org>; "Tommy Will" <tommywill2011@gmail.com>
> Sent: Sunday, January 19, 2014 9:55 PM
> Subject: Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
>
>
> 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
>>>
>>
>
--
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: Vadim Klishko @ 2014-01-20 5:23 UTC (permalink / raw)
To: AJ Guillon; +Cc: linux-input, Tommy Will
In-Reply-To: <52DCAC4D.40206@gmail.com>
Is it a USB or PS/2 touchpad?
----- Original Message -----
From: "AJ Guillon" <aj.guillon@gmail.com>
To: "Vadim Klishko" <vadim@cirque.com>
Cc: <linux-input@vger.kernel.org>; "Tommy Will" <tommywill2011@gmail.com>
Sent: Sunday, January 19, 2014 9:55 PM
Subject: Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
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
>>
>
--
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 5:24 UTC (permalink / raw)
To: Vadim Klishko; +Cc: linux-input, Tommy Will
In-Reply-To: <B087429E37D344BD9FB56A029514CADB@HITLER>
USB. Model GP415U-5321.
AJ
On 14-01-20 12:23 AM, Vadim Klishko wrote:
> Is it a USB or PS/2 touchpad?
>
>
> ----- Original Message -----
> From: "AJ Guillon" <aj.guillon@gmail.com>
> To: "Vadim Klishko" <vadim@cirque.com>
> Cc: <linux-input@vger.kernel.org>; "Tommy Will" <tommywill2011@gmail.com>
> Sent: Sunday, January 19, 2014 9:55 PM
> Subject: Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
>
>
> 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: 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
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