> ---
> drivers/hid/hid-input.c | 61
> +++--
> 1 file changed, 34 insertions(+), 27 deletions(-)
Reviewed-by: Henrik Rydberg
Thanks,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
Hi Benjamin,
> In order to provide fine control for the creation of different
> input devices in probe function of third party drivers, this patch
> split the allocations, the registrations and the free of input
> devices.
>
> Signed-off-by: Benjamin Tissoires
> ---
> drivers/hid/hid-input.c |
On Fri, Nov 23, 2012 at 04:31:26PM +0100, Benjamin Tissoires wrote:
> During the probe, third party drivers can now safely create a new
> input devices depending on the parsing of the reports descriptor.
>
> Signed-off-by: Benjamin Tissoires
> ---
> drivers/hid/hid-input.c | 14 +++---
>
On Fri, Nov 23, 2012 at 04:31:27PM +0100, Benjamin Tissoires wrote:
> Now that drivers can create new inputs, let's use this to split
> the reports coming from the pen and from the touch.
>
> Signed-off-by: Benjamin Tissoires
> ---
> drivers/hid/hid-multitouch.c | 30 +---
Hi Benjamin,
> There is no need to register an input device containing no events.
> This allows drivers using the quirk MULTI_INPUT to register one input
> per report effectively used.
>
> For backward compatibility, we need to add a quirk to request
> this behavior.
>
> Signed-off-by: Benjamin
Hi Benjamin,
> Dual sensors devices reports pen and touch on two different reports.
> Using the quirk HID_QUIRK_MULTI_INPUT allows us to create a new input
> device to forward pen events.
>
> The quirk HID_QUIRK_NO_EMPTY_INPUT avoids the creation of input devices
> for the not used mouse emulatio
Hi Benjamin,
> This is not just cosmetics, it can help to write udev and X.org
> rules.
>
> Signed-off-by: Benjamin Tissoires
> ---
> drivers/hid/hid-multitouch.c | 24 +++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/dr
Hi Jiri, Benjamin,
> > So the solution consists in relying inconditionaly to the quirk MULTI_INPUT
> > for
> > hid-multitouch. Before registering the input device in hid-input, we can
> > test if
> > it has been populated, and if not, then we simply don't register it. In
> > order to
> > preven
Hi Benson,
> On Sat, Mar 16, 2013 at 1:00 PM, Henrik Rydberg wrote:
> >> Userspace can initiate the firmware update procedure by copying cyapa.bin
> >> to /lib/firmware, and then writing anything to the device sysfs attribute:
> >> /sys/bus/i2c/devices/7-0067/upd
Hi Benjamin,
> This callback is called when the parsing of the report has been done
> by hid-core (so after the calls to .event). The hid drivers can now
> have access to the whole report by relying on the values stored in
> the different fields.
>
> Signed-off-by: Benjamin Tissoires
> ---
> dr
Hi Benjamin,
> This device is the worst device I saw. It keeps TipSwitch and InRange
> at 1 for fingers that are not touching the panel.
> The solution is to rely on the field ContactCount, which is accurate
> as the correct information are packed at the begining of the frame.
>
> Unfortunately,
Hi Benjamin,
> so, this is the v2 of the support of win7/8 devices.
Looks like it is getting there, thanks.
> changes since v1:
> - removed the "optimization" patches, as the benefit was minimum
> - introduce a new callback "report" in hid-core that drivers can use to treat
> the
> report by
Hi Benjamin,
> > I think this is more useful if called before the individual fields. In
> > fact, it seems raw_event() is already doing exactly that. No need for
> > a new callback, in other words.
>
> I'm afraid this does not work:
> - calling it before the individual fields is not possible unle
Hi Benjamin,
> > Why not an index here?
>
> Just because an index is not sufficient. You need two things: an index
> within the field, and the actual field (a pointer to a struct
> hid_field). Each .value is local to a field, and even if in most of
> the case, the contact count is alone in its fi
Hi Benjamin,
> Thanks for the review. However, before sending a new patch series, I'd
> like to have your answers to my comments as I mostly disagree on
> everything :)
With good reason, apparently. :-) I see no major problem with your
patches, although the discussed details show that there is ro
Hi Benson,
> This patch adds support for the Cypress APA Smbus Trackpad type,
> which uses a modified register map that fits within the
> limitations of the smbus protocol.
>
> Devices that use this protocol include:
> CYTRA-116001-00 - Samsung Series 5 550 Chromebook trackpad
> CYTRA-103002-00 -
Hi Daniel,
> A recent patch refactored i2c error handling in the register read/write
> path. This adds similar handling to the other i2c paths used in fw_update
> and bootloader state detection.
>
> The generic i2c layer can return values indicating a partial transaction.
> From the atmel_mxt dr
Hi Benjamin,
> This device is the worst device I saw. It keeps TipSwitch and InRange
> at 1 for fingers that are not touching the panel.
> The solution is to rely on the field ContactCount, which is accurate
> as the correct information are packed at the begining of the frame.
>
> Unfortunately,
Hi Benjamin,
> Breaking out this function allows third parties hid drivers to retrieve
> the data fields of a hid report in the raw_event callback.
>
> No functional changes, only exports the function.
>
> Signed-off-by: Benjamin Tissoires
> ---
> drivers/hid/hid-core.c | 60
> +++
Hi Benjamin,
> Relying on ALWAYS_VALID enhance a little the processing time of
> the events.
>
> Signed-off-by: Benjamin Tissoires
> ---
> drivers/hid/hid-multitouch.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Is there a measurement backing up this claim? I suspect
micro-opt
Hi Benjamin,
> By running a test on all the traces of the devices I have,
> I noticed that the class MT_CLS_ALWAYS_TRUE could handle all
> the devices I've seen so far without any other quirks.
> I guess this is the behavior Win 7 requires in its driver.
>
> We can change the default class then a
Hi Benjamin,
> finally, I managed to send a new bunch of patches. Sorry for the delay from
> the
> previous version, but meanwhile, I implemented an automatic regressions tests
> for hid device [1].
> So this series seems pretty big, but it does not break any known devices (I
> ran
> 40 successf
On Mon, Feb 25, 2013 at 01:29:40PM +0100, Jiri Kosina wrote:
> On Mon, 25 Feb 2013, Benjamin Tissoires wrote:
>
> > Hi guys,
> >
> > this is the v2 of the hid transport cleanup.
> >
> > Changes since v1:
> > - gathered reviewed/acked/etc..
> > - changed commit messages of patches 4-6
> > - add n
Hi Jiri,
> > so, here is the hid drivers cleanup. The aim is to remove as much as
> > possible
> > direct calls to usbhid for hid drivers. Thus, other transport layers can use
> > the existing hid drivers (like I2C or uhid).
> >
> > Henrik, patches 1 to 5 are yours. I just rebased and double-che
Hi Benjamin,
> Most HID drivers (rightfully) only depend on the HID bus, not the
> specific transport layer. Remove such dependencies where applicable.
>
> Signed-off-by: Benjamin Tissoires
> ---
I suppose you checked this list against newcomers as well, so:
Acked-by:
Hi Benjamin,
> This removes most of the dependencies between hid drivers and usbhid.
>
> Signed-off-by: Benjamin Tissoires
> ---
Same here, I think a more substantial commit log is in order.
Thanks,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
Hi Benjamin,
> This allows the hid drivers to be independent from the transport layer.
Since the patch is pretty large, a few lines on how it was constructed
might be in order. Something like "by replacing all occurences of
usbhid_submit_report() by its hid_hw_request() counterpart".
Also, the l
Hi Benjamin,
> Signed-off-by: Benjamin Tissoires
> ---
> drivers/hid/hid-multitouch.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Since removing the transport layer dependency has a rationale, it
might be good to mention that here.
Also, what about the explicit usb dependency, wa
d devices[3].
> + * Please run these regression tests before patching this module so that
> + * your patch won't break existing known devices.
> + *
> + * [1] https://github.com/bentiss/hid-test
> + * [2] https://github.com/bentiss/hid-replay
> + * [3] https://github.com/be
Hi Benjamin,
> so, here is the hid drivers cleanup. The aim is to remove as much as possible
> direct calls to usbhid for hid drivers. Thus, other transport layers can use
> the existing hid drivers (like I2C or uhid).
>
> Henrik, patches 1 to 5 are yours. I just rebased and double-checked them.
N-Trig Touchscreen" :
> - "N-Trig MultiTouch";
> - break;
> - }
> - }
> -
> /* This is needed for devices with more recent firmware versions */
> report = hdev->report_enum[HID_FEATURE_REPORT].repo
gt; @@ -438,16 +454,7 @@ static int __mxt_write_reg(struct i2c_client *client,
> u16 reg, u16 len,
> buf[1] = (reg >> 8) & 0xff;
> memcpy(&buf[2], val, len);
>
> - ret = i2c_master_send(client, buf, count);
> - if (ret == count) {
> - ret = 0;
> - } else {
> - if (ret >= 0)
> - ret = -EIO;
> - dev_err(&client->dev, "%s: i2c send failed (%d)\n",
> - __func__, ret);
> - }
> -
> + ret = mxt_i2c_send(client, buf, count);
> kfree(buf);
> return ret;
> }
> --
> 1.8.1
>
Reviewed-by: Henrik Rydberg
Thanks,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
eds to be. The input core can handle slot allocation these days, so
I wonder if the the two patches below work for you, as an
alternative?
Thanks,
Henrik
---
>From 47629b43c260cb9c1ccbd5c474d89da81a029d27 Mon Sep 17 00:00:00 2001
From: Henrik Rydberg
Date: Wed, 20 Feb 2013 22:36:52 +0100
Hi Benson,
> cyapa_check_is_operational and cyapa_create_input_dev are common to
> the probe and firmware update paths. Pull those out into
> cyapa_detect.
>
> Signed-off-by: Benson Leung
> ---
> drivers/input/mouse/cyapa.c | 57
> +++--
> 1 file changed
Hi Benson,
> From: Daniel Kurtz
>
> Use the kernel request_firmware API to allow a hotplug script to load new
> firmware into CYAPA device. When request_firmware is called by a driver,
> the kernel creates 'loading' and 'data' sysfs entries, and generates a
> firmware udev event containing the
> - I don't know if it is my configuration or not, but I'm receiving at
> each frame (between two EV_SYN) all ABS_MT_SLOT events, even when
> there are not used.
Your configuration is fine, I screwed up. Will fix.
> - After a little bit a playing with some surfaces, I can confuse the
> input_mt_a
> - After a little bit a playing with some surfaces, I can confuse the
> input_mt_assign_slot_by_id function: for the very same contact id, I
> got up to four different slots This accumulates the clicks and is
> not very good :-(
Reading again, the input-mt match-by-id code does not do any
For some EV_KEY types, sending a larger-than-one value causes the
input state to oscillate. This patch makes sure this cannot happen,
clearing up the autorepeat bypass logic in the process.
Signed-off-by: Henrik Rydberg
---
drivers/input/input.c | 20 +---
1 file changed, 13
Preparing to move more repeated code into the mt core, add a flags
argument to the input_mt_slots_init() function.
Signed-off-by: Henrik Rydberg
---
drivers/hid/hid-magicmouse.c | 2 +-
drivers/hid/hid-multitouch.c | 2 +-
drivers/input/input-mt.c | 4
MacBook
models seem to work fine.
This patch skips the bt_urb setup for TYPE2 devices, which arguably
should have been done in the first place.
Signed-off-by: Henrik Rydberg
---
drivers/input/mouse/bcm5974.c | 43 ++-
1 file changed, 26 insertions(+), 17
Rename touch properties to match established nomenclature, and define
the maximum number of fingers.
Signed-off-by: Henrik Rydberg
---
drivers/input/mouse/bcm5974.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/input/mouse/bcm5974.c b
The ABS_PRESSURE and ABS_WIDTH have special scales, and were initially
added solely for thumb and palm recognition in the synaptics driver.
This never really get used, however, and userspace quickly moved to
MT solutions instead. This patch drops the unused events.
Signed-off-by: Henrik Rydberg
Use of the in-kernel tracking code to convert the driver to MT-B.
With ten fingers on the pad, the in-kernel tracking adds approximately
25 us to the maximum irqsoff latency. Under normal workloads, however,
the tracking has no measurable effect.
Signed-off-by: Henrik Rydberg
---
drivers/input
A hid device may create several input devices, and a driver may need
to prepare or finalize the configuration per input device. Currently,
there is no sane way for a driver to know when a device has been
configured. This patch adds a callback providing that information.
Signed-off-by: Henrik
With the input_configured() callback in place, the setup and frame
synchronization can be simplified. The input device initialization is
moved to mt_input_configured(), to make sure the full HID report has been
seen.
Cc: Benjamin Tissoires
Signed-off-by: Henrik Rydberg
---
drivers/hid/hid
: Henrik Rydberg
---
Since this patch looks like it could be backported as-is: In 3.6,
maxcontacts may be modified after the slots have been initialized,
leaving the patch harmless but ineffective.
drivers/hid/hid-multitouch.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid
With the input_mt_sync_frame() function in place, there is no longer
any need to keep the full touch state in the driver. This patch
removes the slot state and replaces the lookup code with the input-mt
equivalent.
Cc: Benjamin Tissoires
Signed-off-by: Henrik Rydberg
---
drivers/hid/hid
Preparing to split event filtering and event passing, move the
autorepeat function to the point where the event is actually passed.
Signed-off-by: Henrik Rydberg
---
drivers/input/input.c | 46 +-
1 file changed, 25 insertions(+), 21 deletions
anding bug for devices capable of
more than ten touches.
Several bugs removed, thanks to everyone involved in finding
those. The set has been more thoroughly tested, but still needs
further scrutiny from Benjamin.
Thanks,
Henrik
Henrik Rydberg (20):
Input: Break out MT data
Input: Improve the
buffer size chosen here covers those cases, and
matches the default buffer size in evdev. Since the input estimate is
now preferred, remove the special input-mt estimate.
Reviewed-by: Ping Cheng
Signed-off-by: Henrik Rydberg
---
drivers/input/input-mt.c | 1 -
drivers/input/input.c| 10
Move all MT-related things to a separate place. This saves some
bytes for non-mt input devices, and prepares for new MT features.
Signed-off-by: Henrik Rydberg
---
drivers/input/evdev.c| 10 ++
drivers/input/input-mt.c | 47 +++
drivers
Going through the motions of printing the debug message information
takes a long time; using the keyboard can lead to a 160 us irqsoff
latency. This patch skips hid_dump_input() when there are no open
handles, which brings latency down to 100 us.
Signed-off-by: Henrik Rydberg
---
drivers/hid
ce data by removing the logical
scale altogether. While at it, the fake pressure range is replaced by the
orientation range, which will be used in a subsequent patch.
Signed-off-by: Henrik Rydberg
---
drivers/input/mouse/bcm5974.c | 193 --
1 file changed, 75
Some devices use an internal key for tracking which cannot be directly
mapped to slots. This patch provides a key-to-slot mapping, which can
be used by drivers of such devices.
Signed-off-by: Henrik Rydberg
---
drivers/input/input-mt.c | 32
include/linux/input
commonly occuring cases.
Signed-off-by: Henrik Rydberg
---
drivers/input/input-mt.c | 144 ++-
include/linux/input/mt.h | 21 +++
2 files changed, 163 insertions(+), 2 deletions(-)
diff --git a/drivers/input/input-mt.c b/drivers/input/input-mt.c
patch adds the events() handler callback and uses it if it
exists. The latency is improved by 50 us even without the callback.
Signed-off-by: Henrik Rydberg
---
drivers/input/input.c | 176 +++---
include/linux/input.h | 24 ++-
2 files changed
By sending a full frame of events at the same time, the irqsoff
latency at heavy load is brought down from 200 us to 100 us.
Signed-off-by: Henrik Rydberg
---
drivers/input/evdev.c | 68 +++
1 file changed, 47 insertions(+), 21 deletions(-)
diff
pointer emulation.
With init flags and frame synchronization in place, most MT drivers
can be simplified. First out are the bcm5974 and hid-multitouch
drivers, following this patch.
Cc: Benjamin Tissoires
Signed-off-by: Henrik Rydberg
---
drivers/input/input-mt.c | 70
Hi Jiri,
> I have applied this one right away, so you can drop it from your series.
> The remaining ones I am still about to review (currently travelling).
Great, thanks. The notification callback can also be applied if you want.
> There is no inter-dependency between the Input and HID ones, an
With the input_configured() callback in place, the setup and frame
synchronization can be simplified. The input device initialization is
moved to mt_input_configured(), to make sure the full HID report has been
seen.
Cc: Benjamin Tissoires
Signed-off-by: Henrik Rydberg
---
drivers/hid/hid
Hi Benjamin,
> Unfortunately, this is not working. We have bad devices that present either:
> - a null logical_maximum (some Stantum do) -> the value 1 is assigned
> to maxcontacts, and the device is turned into a mono touch
> - an obviously wrong value (with respect to the current state of th
> Indeed, we are getting close. I tested the whole patch set again.
> So:
> - patches 1 to 19 are not introducing any bugs (at least from what I've seen).
> - patch 20 is not good (see the reply in the patch).
>
> So far, devices tested are:
> - Elan
> - 3M
> - Lumio
> - Cypress
> - Topseed
> - St
Hi Ferruh,
> Before finalizing the work, we want to learn if introducing new files
> for new driver is acceptable and our effort is inline with your request,
> can you please comment on it?
New files are certainly alright when they are warranted, but of course
it depends on the details. We will k
> Henrik,
>
> It looks like your changes are causing the panic.
Indeed, I have pushed the fix below to next already. Thanks for Sedat,
and sorry for not catching this earlier. :-(
Henrik
--
>From ccc6557bfd02efdca4d9dfda6cfdfe5a08d0193b Mon Sep 17 00:00:00 2001
From: Henrik Ry
On Thu, Sep 13, 2012 at 08:57:38AM -0700, Dmitry Torokhov wrote:
> On Thu, Sep 13, 2012 at 05:05:44PM +0200, Jiri Slaby wrote:
> > Hi,
> >
> > -next commit "Input: Send events one packet at a time" seems like broke
> > the input layer:
>
> Right, Henrik has a patch for this.
Yep, it just missed
On Wed, Sep 12, 2012 at 10:15:28PM -0700, Dmitry Torokhov wrote:
> On Sat, Sep 01, 2012 at 09:46:56PM +0200, Henrik Rydberg wrote:
> > Move all MT-related things to a separate place. This saves some
> > bytes for non-mt input devices, and prepares for new MT features.
> &g
> Filter handlers do not typically have ->event() methods, that's the
> reason for reported panic.
If we decide to rewind the tree, I will amend the fix here.
Thanks,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
On Wed, Sep 12, 2012 at 11:57:24PM -0700, Dmitry Torokhov wrote:
> On Sat, Sep 01, 2012 at 09:47:08PM +0200, Henrik Rydberg wrote:
> > The ABS_PRESSURE and ABS_WIDTH have special scales, and were initially
> > added solely for thumb and palm recognition in the synaptics driver.
Hi Ferruh,
> This driver is for Cypress TrueTouch(tm) Standard Product controllers,
> Generation4 devices.
>
> This is second version of driver, code re-structured to match with
> existing Generation3 driver code.
To integrate with the existing gen3 driver is clearly not the same as
creating a p
> > > I went ahead and pushed the (updated) branch to my for-next, to get
> > > some integration coverage. It is that time. Jiri, I added your
> > > Acked-by on the hid patches for now, hope that is alright.
> >
> > Yes, it is, thanks Henrik.
> >
> > Dmitry, I can pull the whole lot into my tree
Hi Alexandra,
> Hi Henrik/Dmitry,
>
> We are working on a product specific driver for Synaptics DS4 I2C touchscreen
> devices. It was submitted on Sept. 16, 2012, but has not been reviewed.
> (http://lkml.org/lkml/2012/9/16/24).
> We found several warnings after running script/checkpatch.pl, the
Hi Alexandra,
> From: Alexandra Chin
> Date: Wed, 31 Oct 2012 16:21:12 +0800
> Subject: [PATCH] staging: ste_rmi4: Convert to Type-B support
>
> This patch:
> - Convert to MT-B because Synaptics touch devices are capable of
> tracking identifiable fingers
> - Modify maximum supported fingers u
> >> + usage_index) {
> >> + hid_map_usage(hi, usage, bit, max,
> >> + EV_ABS, ABS_MT_TOOL_X);
> >> + set_abs(hi->input, ABS_MT_TOOL_X, field,
> >> +
Hi Benjamin,
> On Mon, Oct 29, 2012 at 11:19 PM, Henrik Rydberg wrote:
> > On Fri, Oct 26, 2012 at 10:44:24AM +0200, Benjamin Tissoires wrote:
> >> Win 8 specification is much more precise than the Win 7 one.
> >> Moreover devices that need to take certificatio
Hi Benjamin,
> > This is a nice feature, useful in many other contexts. As such, I
> > think it should be defined in the context of the input subsystem, with
> > a more specific definition added to the documentation. For instance,
> > is 100us suitable? When should it start at zero, at BTN_TOUCH?
review below :)
>
> > From 5d9a791e0a9e41bcea0fcb286e2849b403675f37 Mon Sep 17 00:00:00 2001
> > From: Henrik Rydberg
> > Date: Mon, 2 Jul 2012 20:38:21 +0200
> > Subject: [PATCH 3/7] hid: extend interface with report requests
> >
> > ---
> > drivers/hid/usbhi
Hi Alexandra,
> From 783c14e5978600cc78e11ea078cc413d77a9debd Mon Sep 17 00:00:00 2001
> From: Alexandra Chin
> Date: Thu, 1 Nov 2012 17:02:14 +0800
> Subject: [PATCH v2] staging: ste_rmi4: Convert to Type-B support
>
> This patch:
> - convert to MT-B because Synaptics touch devices are capable
Hi Benjamin,
> The goal of this patch is to implement in a reliable way Win 8
> multitouch protocol (to avoid quirking many devices). Thanks to the
> precision they made in the specification, I think it is feasible:
> they add the dynamic part that were missing in Win 7 spec:
> """
> When sending
Hi Alexandra,
Thanks for making changes.
> This patch converts to MT-B because Synaptics touch devices are
> capable of tracking identifiable fingers
>
> This patch was tested on pandaboard, except input_mt_sync_frame(),
> which is a quite new function.
I am not sure how to interpret this. Is t
Hi Benjamin,
> >> This patch factorizes the hid set_feature command by using
> >> hid_device->hid_output_raw_report instead of direclty relying on
> >> usbhid. This makes the driver usb independant.
> >>
> >> However I still can't remove the 2 usb related headers because the
> >> function mt_resum
Signed-off-by: Henrik Rydberg
---
Hi Guenter,
It turns out the mid-2012 Macbooks need additional changes in order to
work reliably. Since the needed change is a great improvement also on
other problematic machines, it would make a lot of sense if this patch
could be squeezed into the merge window.
As
> > As I mentioned in a previous mail, backporting e70acc100 by itself is
> > not a good idea, but together with this patch it should be ok.
> >
> I think the patches should mature a bit in mainline. We can decide in a month
> or so if we want to backport them to previous releases.
Yes, sorry, th
Hi Yufeng,
> We are already releasing all pressed keys on device reset and
> disconnect. This patch adds the finger release for multi-touch
> device.
>
> Different than the key release logic that only the pressed keys
> are released, here all the possible fingers are released even
> it is not rec
Hi Dmitry Torokhov wrote:
> There is a demand from driver's writers to use managed devices framework
> for their drivers. Unfortunately up to this moment input devices did not
> provide support for managed devices and that lead to mixing two styles
> of resource management which usually introduced
Hi Benjamin,
> Exporting this function allows us to calculate the resolution in third
> party drivers like hid-multitouch.
> This patch also complete the function with additional valid axes.
>
> Signed-off-by: Benjamin Tissoires
> ---
Nice, but please see comment below.
> drivers/hid/hid-inpu
Hi Benjamin,
> HID spec details special values for the HID field unit exponent.
> Basically, the range [0x8..0xf] correspond to [-8..-1].
>
> Signed-off-by: Benjamin Tissoires
> ---
Standard two's complement, in other words?
> drivers/hid/hid-core.c | 10 +-
> drivers/hid/hid-input.c
Hi Benjamin,
> Currently, there is no way to know the index of the current field
> in the .input_mapping and .event callbacks when this field is inside
> an array of HID fields.
> This patch forwards this index to the input_mapping and event
> callbacks.
I agree with the idea, but the function a
> > > @@ -1766,8 +1830,14 @@ EXPORT_SYMBOL(input_allocate_device);
> > > */
> > > void input_free_device(struct input_dev *dev)
> > > {
> > > - if (dev)
> > > + if (dev) {
> > > + if (dev->devres_managed)
> > > + WARN_ON(devres_destroy(dev->dev.parent,
> > > +
> > Either way, the code looks functional to me.
>
> So is that "reviewed-by"?
I was thinking about this hunk:
> @@ -1972,7 +2084,20 @@ int input_register_device(struct input_dev *dev)
>
> mutex_unlock(&input_mutex);
>
> + if (dev->devres_managed) {
> + dev_info(dev
Hi Benjamin,
> Win8 certification introduced the ability to transmit two X and two Y per
> touch. The specification precises that it must be in an array, with a
> report count == 2.
The number two never really enters the patch, so maybe it should be
dropped to avoid confusion. It probably makes m
>maxcontacts = field->value[0];
> + if (!td->maxcontacts &&
> + field->logical_maximum <= MT_MAX_MAXCONTACT)
> + td->maxcontacts = field->logical_maximum;
> if (td->mtclass.maxcontacts)
>
Hi Benjamin,
> Win8 input specification clarifies the X and Y sent by devices.
> It distincts the position where the user wants to Touch (T) from
> the center of the ellipsoide (C). This patch enable supports for this
> distinction in hid-multitouch.
>
> We recognize Win8 certified devices from t
Hi Benjamin,
> Win 8 device specification changed the requirements for the hid usages
> of the multitouch devices. Now InRange is optional and must be only
> used when the device supports hovering.
>
> This ensures that the quirk ALWAYS_VALID is taken into account and
> also ensures its precedenc
On Fri, Oct 26, 2012 at 10:44:24AM +0200, Benjamin Tissoires wrote:
> Win 8 specification is much more precise than the Win 7 one.
> Moreover devices that need to take certification must be submitted
> to Microsoft.
>
> The result is a better protocol support and we can rely on that to
> skip all
Hi Benjamin,
> Win8 devices supporting hovering must provides InRange HID field.
> The information that the finger is here but is not touching the surface
> is sent to the user space through ABS_MT_DISTANCE as required by the
> multitouch protocol.
>
> Signed-off-by: Benjamin Tissoires
> ---
>
Hi Benjamin,
> Win 8 digitizer devices provides the actual scan time computed by the
> hardware itself. The value is global to the frame and is not specific
> to the multitouch protocol (though only touch, not pen, should use it
> according to the specification).
>
> Signed-off-by: Benjamin Tisso
r) {
> - max = td->mtclass.maxcontacts;
> - fieldmax = r->field[0]->logical_maximum;
> - max = min(fieldmax, max);
> - if (r->field[0]->value[0] != max) {
> - r->field[0]->value[0] = max;
> -
On Sat, Aug 24, 2013 at 04:26:30PM -0700, Dmitry Torokhov wrote:
> Hi Ian,
>
> On Sun, Aug 25, 2013 at 12:17:52AM +1000, Ian Munsie wrote:
> > This patch adds a device ID found for mid-2013 Macbook Air 6,1 from
> > lsusb:
> >
> > Bus 001 Device 003: ID 05ac:0290 Apple, Inc.
> >
> > Since IDs alr
Hi Ian,
> This patch adds a device ID found for mid-2013 Macbook Air 6,1 from
> lsusb:
>
> Bus 001 Device 003: ID 05ac:0290 Apple, Inc.
>
> Since IDs already exist for this generation Macbook air as WELLSPRING8,
> name this one WELLSPRING8A. This only adds an ANSI version since it's
> device ID
machines seem fine, I have never
encountered the problem myself. Here is a patch to test that
theory. It has been tested to be pretty harmless on two different
generations.
I really really do not want to add an 'if (value is insane)' check ;-)
Thanks,
Henrik
>From d48a9e4e6e45dcd9c7e7
1 - 100 of 363 matches
Mail list logo
