overlong udelay()")
Reported-by: Andreas Kemnade
Tested-by: Andreas Kemnade # MacBookAir6,2
Acked-by: Arnd Bergmann
Signed-off-by: Brad Campbell
Signed-off-by: Henrik Rydberg
---
Changelog :
v1 : Initial attempt
v2 : Address logic and coding style
v3 : Removed some debug hangover. Added tested-b
Hi Brad,
Out of morbid curiosity I grabbed an older MacOS AppleSMC.kext (10.7) and ran
it through the disassembler.
Every read/write to the SMC starts the same way with a check to make sure the
SMC is in a sane state. If it's not, a read command is sent to try and kick it
back into line :
Wa
On 2020-11-08 12:57, Brad Campbell wrote:
On 8/11/20 9:14 pm, Henrik Rydberg wrote:
On Sun, Nov 08, 2020 at 09:35:28AM +0100, Henrik Rydberg wrote:
Hi Brad,
On 2020-11-08 02:00, Brad Campbell wrote:
G'day Henrik,
I noticed you'd also loosened up the requirement for SMC_STAT
On Sun, Nov 08, 2020 at 09:35:28AM +0100, Henrik Rydberg wrote:
> Hi Brad,
>
> On 2020-11-08 02:00, Brad Campbell wrote:
> > G'day Henrik,
> >
> > I noticed you'd also loosened up the requirement for SMC_STATUS_BUSY in
> > read_smc(). I assume
> >
restore function with the changes previously committed.
Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2
Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
Reported-by: Andreas Kemnade
Tested-by: Andreas Kemnade # MacBookAir6,2
Acked-by: Arnd Bergmann
Signed-off-by: B
Hi Brad,
G'day Henrik,
Which kernel was this based on? It won't apply to my 5.9 tree.
I was being lazy and applied the diff to linus/master on top of my
current stable branch. More importantly, I sent the mail out from an
email client that may not format the patch properly; I'll fix that.
On 2020-11-06 21:02, Henrik Rydberg wrote:
So as it stands, it does not work at all. I will continue to check
another machine, and see if I can get something working.
On the MacBookAir3,1 the situation is somewhat better.
The first three tree positions result in zero failures and 10 reads per
So as it stands, it does not work at all. I will continue to check
another machine, and see if I can get something working.
On the MacBookAir3,1 the situation is somewhat better.
The first three tree positions result in zero failures and 10 reads per
second. The fourth yields zero failues and
I can't guarantee it won't break older machines which is why I've
asked for help testing it. I only have a MacbookPro 11,1 and an iMac
12,2. It fixes both of those.
Help testing would be much appreciated.
I see, this makes much more sense. I may be able to run some tests
tonight. Meanwhile,
On 2020-11-05 09:30, Brad Campbell wrote:
On 5/11/20 6:56 pm, Henrik Rydberg wrote:
Hi Brad,
Great to see this effort, it is certainly an area which could be improved.
After having seen several generations of Macbooks while modifying much of that
code, it became clear that the SMC
Hi Brad,
Great to see this effort, it is certainly an area which could be
improved. After having seen several generations of Macbooks while
modifying much of that code, it became clear that the SMC communication
got refreshed a few times over the years. Every tiny change had to be
tested on a
;
- else
- return snprintf(sysfsbuf, PAGE_SIZE, "%d\n", count);
+
+ count = ((u32)buffer[0]<<24) + ((u32)buffer[1]<<16) +
+ ((u32)buffer[2]<<8) + buffer[3];
+ return snprintf(sysfsbuf, PAGE_SIZE, "%d\n", count);
}
static ssize_t applesmc_key_at_index_read_show(struct device *dev,
Looks good, thank you.
Reviewed-by: Henrik Rydberg
Henrik
Hi Jiada,
input_mt_report_slot_state() ignores the tool when the slot is closed.
which has caused a bit of confusion.
This patch introduces input_mt_report_slot_inactive() to report slot
inactive state.
replaces all input_mt_report_slot_state() with
input_mt_report_slot_inactive() in case of clo
Hi Ronald,
This changeset adds a driver for the SPI keyboard and trackpad on recent
MacBook's and MacBook Pro's. The driver has seen a fair amount of use
over the last 2 years (basically anybody running linux on these
machines), with only relatively small changes in the last year or so.
For thos
anged, 134 insertions(+), 16 deletions(-)
This version looks good.
Reviewed-by: Henrik Rydberg
Thank you!
Henrik
Hi Sean,
Thanks for the driver. Looking good, but I do have some comments below.
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 79bdf0c7e351..d6d0b20cc015 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -88,9 +88,11 @@
> #define USB_DEVICE_ID_ANTON_T
void input_mt_report_finger_count(struct input_dev *dev, int count);
Reviewed-by: Henrik Rydberg
Thanks, Dmitry.
Henrik
Hi Dmitry,
Logically, the confidence state is a property of a contact, not a new type
of contact. Trying to use it in any other way is bound to lead to confusion.
Problem is that MT_TOOL_PALM has been introduced in the kernel since
v4.0 (late 2015 by a736775db683 "Input: add MT_TOOL_PALM").
It'
However, I interpret a firmware that send (confidence 1, tip switch 1)
and then (confidence 0, tip switch 0) a simple release, and the
confidence bit should not be relayed.
This unfortunately leads to false clicks: you start with finger, so
confidence is 1, then you transition the same touch t
Hi Stephan,
I would like to have Touchpad 2 properly supported.
You will find proper prior support for Magic Trackpads in
drivers/hid/hid-magicmouse.c.
Henrik
| 52 +---
include/linux/hid.h | 1 +
3 files changed, 54 insertions(+), 8 deletions(-)
Reviewed-by: Henrik Rydberg
Thank you, Wei-Ning, and sorry for the delay. Dmitry, did you plan to
add this to your pull request already?
Henrik
> rather have [-90,90], with 0 being "north".
> >
> > ... I'd like the documentation fix to go in together in one go with this
> > patch if possible.
> >
>
> Sounds like a plan.
How about this patch?
Henrik
---
>From b14f92066dfab3f8a255ec7b5a30cb1a864dc62
value -= field->logical_maximum;
> + td->curdata.a = -value;
> + td->curdata.has_azimuth = true;
> + break;
> case HID_DG_TOUCH:
> /* do nothing */
>
Hi Dmitry,
The meaning of confidence is literally "contact is too large to be a
finger", so it is not touch state, but really tool identity. We do
allow tool identity to change over time.
What I am arguing is rather that since "palm" is a property, just like
contact size, there should be no nee
Hi Dmitry,
On 08/11/2017 02:44 AM, Dmitry Torokhov wrote:
According to Microsoft specification [1] for Precision Touchpads (and
Touchscreens) the devices use "confidence" reports to signal accidental
touches, or contacts that are "too large to be a finger". Instead of
simply marking contact ina
Hi Aniroop,
>> I am not sure what the urgency is. It is more of a theoretical problem
>> ans so far the proposed solutions were actually introducing more
>> problems than they were solving.
>>
>> I am sorry, bit this particular topic is not a priority for me.
>>
>
> There is no hurry at all. :-)
Hi Dmitry,
>> diff --git a/drivers/input/input.c b/drivers/input/input.c
>> index 8806059..262ef77 100644
>> --- a/drivers/input/input.c
>> +++ b/drivers/input/input.c
>> @@ -401,8 +401,7 @@ static void input_handle_event(struct input_dev *dev,
>> if (dev->num_vals >= 2)
>>
: Janez Urevc
Signed-off-by: Henrik Rydberg
---
drivers/hid/hid-apple.c | 6 ++
drivers/hid/hid-core.c | 6 ++
drivers/hid/hid-ids.h | 3 +++
3 files changed, 15 insertions(+)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index f822fd2..884d82f 100644
--- a/drivers/hid
Radmacher
Tested-by: Yang Hongyang
Tested-by: Yen-Chin, Lee
Tested-by: George Hilios
Tested-by: Janez Urevc
Signed-off-by: Henrik Rydberg
---
drivers/input/mouse/bcm5974.c | 132 ++
1 file changed, 81 insertions(+), 51 deletions(-)
diff --git a/drivers/input
Signed-off-by: Henrik Rydberg
---
drivers/input/mouse/bcm5974.c | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index a596b9b..30e3442 100644
--- a/drivers/input/mouse/bcm5974.c
Benjamin,
For old kernels this is not a problem because max_slots was 2 and libinput/
xorg-synaptics knew how to deal with that. Now that max_slot is 3, the
clients ignore BTN_TOOL_TRIPLETAP and count the actual used slots (so 2).
It then gets confused when receiving the BTN_TO
Peter,
It may be a long time ago now, but we had very vocal discussions regarding the
MT protocol back then, and I am quite sure all the subtleties are well
understood. In order to fully appreciate the simplicity of the protocol, one
only needs to stop misintepreting it. In order to do that, pleas
> My guess is that none of these drivers are
> able to handle a silent closing of a slot and the easiest solution might
> be to simply change the documentation if in fact nobody uses the
> compressed notation (which removes just one ABS_SLOT event within the
> frame, so not sure we can call it comp
> "Creation, replacement and destruction of contacts is achieved by
> modifying the ABS_MT_TRACKING_ID of the associated slot. A
> non-negative tracking id is interpreted as a contact, and the value -1
> denotes an unused slot. A tracking id not previously present is
> considered new, and a track
On 03/31/2015 05:07 PM, Benjamin Tissoires wrote:
> Hi,
>
> so this is the v2 with Hans' ack and Henrik's respin of the first patch.
The whole series looks good, thank you Benjamin.
Acked-by: Henrik Rydberg
Henrik
--
To unsubscribe from this list: send the line "unsu
er with a different commit message. I did not have any
opportunity to check this in hardware. I you like it and find it
working, then please take over the authorship and just add a
signed-off from me.
Thanks,
Henrik
---
>From e00d63f6cadf20d871bed763b3531428b34d785c Mon Sep 17 00:00:00 2001
Hi Benjamin,
> Slot 0 is released correclty, but when we look for Contact ID 2, the slot
> 0 is then picked up again because it is marked as inactive (trackingID < 0).
>
> This is wrong, and we should not reuse a slot in the same frame.
> The test should also check for input_mt_is_used().
Good c
tested-by.
Done, and tested against Linus' master. I take it you have a patch on
this coming up as well?
Thanks,
Henrik
>From 2a4986420e634df2f0ba09198cb1e55714f61577 Mon Sep 17 00:00:00 2001
From: Henrik Rydberg
Date: Sun, 1 Feb 2015 09:16:10 +0100
Subject: [PATCH v2] Input: MT - Add support
Hi Dmitry,
On 01/22/2015 09:02 PM, Dmitry Torokhov wrote:
> On Thu, Jan 22, 2015 at 08:52:25PM +0100, Henrik Rydberg wrote:
>> int input_mt_assign_slots(struct input_dev *dev, int *slots,
>> - const struct input_mt_pos *pos, int num_pos)
>> +
problem formulation for dmax > 0 cannot benefit from the
speedup for positive definite matrices, but since the convergence is
faster, the result is about the same. For a handful of contacts, the
latency difference is truly negligible.
Suggested-by: Benjamin Tissoires
Not-yet-signed-off-by: Hen
Hi Peter,
> from the testing I've done, you cannot trigger this except by lifting a
> finger and raising a finger. There is no per-use-case requirement, it's a
> hardware deficiency that the hardware simply cannot detect this specific
> case of finger change.
This is a good selling point, but...
Hi Benjamin,
> - there is a fragmentation problem: we would have to fix the bug in
> xorg-synaptics (which is slowly waiting for its death), libinput,
> ChromeOS, Qt Embedded, Kivy (I think), etc...
Indeed, this is the problem I wanted to highlight. As the fragmentation problem
grows (graphics, i
Hi Peter,
> it wasn't the first reaction. it was the third, after we hacked up
> synaptics [1], then libinput [2], both rather unsatisfactory. Not sure what
> chromeos does but they'll probably would need similar code. And any other
> users of the evdev API of course.
So if this approach did not
Hi Benjamin,
> Henrik, I just used the get_maintainer to add you on CC to an input-mt
> patch series, and it ended up using the @euromail.se instead of your
> still valid one. I can resend to you the patch series if you want.
Thanks, that won't be necessary.
I looked through the the patchset, an
My ISP finally gave up on the old mail address, so I am moving things
over to bitmath.org instead. Also change the status fields to better
reflect reality.
Signed-off-by: Henrik Rydberg
---
MAINTAINERS | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS
is enforced.
Here is a tested patch that does just that, thanks for the suggestion.
Henrik
>From 43c16bbc7adbcb17aac73d09f046bf2779771c4c Mon Sep 17 00:00:00 2001
From: Henrik Rydberg
Date: Fri, 14 Nov 2014 20:01:21 +0100
Subject: [PATCH v2] x86, ia64: Do not lose track of the EFI default VGA
On 11/14/2014 03:42 PM, Bruno Prémont wrote:
> On Fri, 14 Nov 2014 13:53:30 +0100 Henrik Rydberg wrote:
>> Since commit 20cde694027e ("x86, ia64: Move EFI_FB
>> vga_default_device() initialization to pci_vga_fixup()") in the 3.17
>> merge window, the EFI framebuffer
FB_EFI is configured without VGA_ARB. Add a
select clause to remedy this.
Cc: Bruno Prémont
Signed-off-by: Henrik Rydberg
---
Hi Peter,
I stumbled upon this bug from the 3.17 merge window when updating to
Linus's 3.18 git head yesterday. The patch has been tested on two
different EFI machines; one
Hi Dmitry,
On 07/26/2014 02:27 AM, Dmitry Torokhov wrote:
> Semi-MT devices are pointers too, so let's tell that to
> input_mt_init_slots(), as well as let it set up the devices as semi-MT,
> instead of us doing it manually.
>
> Reviewed-by: Daniel Kurtz
> Reviewed-by: Benson Leung
> Signed-off
ndrew de los Reyes
> Reviewed-by: Benson Leung
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/input/input.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
Oh my, that was a bad one.
Reviewed-by: Henrik Rydberg
Thanks,
Henrik
--
To unsubscribe from this list:
ed for a better model of interrupted contacts in the core.
> + }
> break;
> + }
>
> msleep(20);
> }
> @@ -333,6 +389,13 @@ static int pixcir_i2c_ts_probe(struct i2c_client *client,
> input_set_abs_
Hi Roger,
the MT implementation seems mostly fine, just one curiosity:
> static irqreturn_t pixcir_ts_isr(int irq, void *dev_id)
> {
> struct pixcir_i2c_ts_data *tsdata = dev_id;
> const struct pixcir_ts_platform_data *pdata = tsdata->chip;
> + struct pixcir_report_data report;
Hi Dmitry,
>> What problematic scenario is this supposed to solve?
>>
>> The 'release on suspend' is only an approximation to the 'close
>> laptop' scenario, it is certainly not correct in the coffee table
>> case,
>
> Why would it not be correct for coffee table? Do we expect the touches
> to re
Hi Felipe,
> Adds a helper function to send end touch events for active tracking ids.
> And also implements it in egalax driver.
What problematic scenario is this supposed to solve?
The 'release on suspend' is only an approximation to the 'close laptop'
scenario,
it is certainly not correct in
Hi Benjamin,
> The ANTEC Touch Pad is a device which can switch from a multitouch
> touchpad to a mouse. It thus presents several generic collections which
> are currently ignored by hid-multitouch. Enable them by using the generic
> protocol. Adding also a suffix for them depending on their appli
Hi Roger,
> It seems the controller the original driver was written for does not report
> touch ID and just reports 2 touch co-ordinates. I'm not sure how this fits
> into
> Type B reporting model.
Look in drivers/input/mouse/cypress_ps2.c for an example of how to deal with
anonymous touch coord
Hi Chris,
> Well, it seems to be a another one off event. It's the same hardware as
before, and it was booting from a USB stick containing Fedora 20 final test
candidate 2 which uses kernel 3.11.8. An immediate reboot did not reproduce the
problem, nor multiple subsequent reboots. I think I previo
; [8.603053] applesmc: key count changed from 261 to 1392508929
I was under the impression that this machine was tested before, and that
commit 25f2bd7f5add608c1d1405938f39c96927b275ca
Author: Henrik Rydberg
Date: Wed Oct 2 19:15:03 2013 +0200
hwmon: (applesmc) Always read until end of data
Hi Guenter,
> > I want to make one more test tomorrow, then I'll send a proper patch.
> > Thanks!
> >
> Ok, great.
And here it is, with compiler warning fixed.
Thanks everybody,
Henrik
>From 18fa0f55b764ad0fe5fc49f81bae281e5110ed56 Mon Sep 17 00:00:00 2001
From:
Hi Guenter,
> > > So, what should we do with this patch ? Apply it ?
> >
> > So far I'm getting nothing on the original machine. As of today it's
> > applied as the last patch on 3.12.0-0.rc4.git0.1.fc20.x86_64. Unfortunately
> > at the moment I'm a bit too dense to figure out how to get a new
On Wed, Oct 02, 2013 at 09:47:18AM -0700, Guenter Roeck wrote:
> On Wed, Oct 02, 2013 at 06:34:18PM +0200, Henrik Rydberg wrote:
> > > >>One thing I have seen in all logs is the earlier "send_byte fail"
> > > >>message, so
> > > >>I thi
> >>One thing I have seen in all logs is the earlier "send_byte fail" message,
> >>so
> >>I think that is a pre-requisite.
> >
> >Not necessarily - it could be that the patch actually fixes the root
> >cause. One possible scenario is that on recent SMCs, some of the
> >commands produce more data t
> > Patch added on top of 3.12.0-0.rc3.git0.1.fc20.x86_64 and built. But after
> > ~dozen reboots, I'm not triggering the problem. The only items in dmesg
> > with smc in it:
> >
> > [ 13.799819] applesmc: key=261 fan=2 temp=14 index=14 acc=1 lux=2 kbd=1
> > [ 13.833402] input: applesmc as
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
> >Yes - I agree that the error state is far-fetched, but it is hard to
> >see any other logical explanation. There is of course always the
> >possibility that the problem is somewhere else completely.
> >
> There are also ACPI conflicts in each of the bug reports I looked at.
> Can this play a rol
> Applied. I'll run my sanity tests before I send it upstream.
> I'll also Cc: stable.
Great.
> Interesting is that this started to happen with 3.10, even though
> I did not find any relevant changes in the driver. Is it possible that
> changed boot timing (ie reduced boot time) exposes this prob
es - I agree that the error state is far-fetched, but it is hard to
see any other logical explanation. There is of course always the
possibility that the problem is somewhere else completely.
Proper patch attached.
Thanks,
Henrik
---
>From dedefba9167913c46e1896ce0624e68ffe95d532 Mon Sep 17 00:
On Wed, Sep 25, 2013 at 12:56:28PM -0700, Guenter Roeck wrote:
> On Wed, Sep 25, 2013 at 03:06:25PM -0400, Josh Boyer wrote:
> > Hi All,
> >
> > Chris has reported[1] an issue with the applesmc driver in the 3.10
> > and 3.11 kernels. This seems to be a bit transient, but the oops is
> > consiste
: Dmitry Torokhov
Reported-and-tested-by: Ian Munsie
Tested-by: Linus G Thiel
Signed-off-by: Henrik Rydberg
---
Hi Jiri, Dmitry,
it looks like this change has been sufficiently tested now, in
addition to making perfect sense. Jiri, would you mind taking it, if
Dmitry approves?
The patch should
On Mon, Aug 26, 2013 at 02:51:32PM +0200, Linus G Thiel wrote:
> I'm on an ISO layout, this is what makes sense to me and it also works fine
> on my laptop (6,2 with Swedish layout).
>
>
> On Mon, Aug 26, 2013 at 3:50 AM, Ian Munsie wrote:
>
> > > Brad, Linus, does the above patch work for you
Hi Heiko,
> This adds a driver for touchscreens using the zforce infrared
> technology from Neonode connected via i2c to the host system.
>
> It supports multitouch with up to two fingers and tracking of the
> contacts in hardware.
>
> Signed-off-by: Heiko Stuebner
Thanks for the driver. Pleas
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
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
ll not impact this. Maybe just wait for Henrik to put his "Reviewed-by"
> before
> giving one last test.
Here goes:
Reviewed-by: Henrik Rydberg
Cheers,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo
Hi Benjamin,
> Detecting Win 8 multitouch devices in core allows us to set quirks
> before the device is parsed through hid_hw_start().
> It also simplifies the detection of those devices in hid-multitouch and
> makes the handling of those devices cleaner.
>
> As Win 8 multitouch panels are in th
Hi Benjamin,
this looks pretty good to me, just a few nitpicks below.
> hid_scan_report() implements its own HID report descriptor parsing. It is
> going to be really bad with the detection of Win 8 certified touchscreen,
> as this detection relies on a special feature and on the report_size and
Hi Ben,
The new mutexes in nvc0/nv50 (fadb17190/b509656) break resume on my
MBA3,1. A dead-lock somewhere, perhaps? Reverting fixes the problem.
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 maj
> > Yes, I was really hoping (and originally planning) to release 3.9
> > final this weekend, but we had enough issues that I just didn't feel
> > comfy about it. It was borderline, and none of the issues were huge,
> > and maybe I could have called this just 3.9 and opened the merge
> > window, bu
Hi Matthew, Peter, Linus,
> Yes, I was really hoping (and originally planning) to release 3.9
> final this weekend, but we had enough issues that I just didn't feel
> comfy about it. It was borderline, and none of the issues were huge,
> and maybe I could have called this just 3.9 and opened the m
Most semi-mt drivers use the slots in a manual way, but really only
need to treat the finger count manually. With this patch, a semi-mt
driver may use the input-mt core for everything else.
Signed-off-by: Henrik Rydberg
---
Hi Dmitry,
an earlier version of this patch came about as a test to
Hi Nick,
> The following patches are a large series of updates in functionality to the
> atmel_mxt_ts touch driver. They apply cleanly to input/next.
I guess this is no longer true.
> These changes address some of the same issues that appear in the patchsets
> submitted by Daniel Kurtz and Peter
Hi Ivan,
> Tested on Dell 7720. Works fine.
>
> Signed-off-by: Valyushkov Ivan
> ---
> drivers/input/mouse/alps.c | 464
> +---
> drivers/input/mouse/alps.h |2 +
> 2 files changed, 443 insertions(+), 23 deletions(-)
This patch does not seem to app
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 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 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 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,
> 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 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
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
>
> This same driver can be used by atmel based touchscreens and touchpads
> (buttonpads). Platform data may specify a device is a touchpad
> using the is_tp flag.
>
> This will cause the driver to perform some touchpad specific
> initializations, such as:
> *
On Wed, Mar 06, 2013 at 01:49:15PM -0800, H. Peter Anvin wrote:
> On 03/06/2013 01:33 PM, Yinghai Lu wrote:
> > On Wed, Mar 6, 2013 at 12:58 PM, H. Peter Anvin
> > wrote:
> >
> >> Excellent. Yinghai, can you write up the patch with a proper
> >> description and I'll put it into x86/urgent.
> >
On Wed, Mar 06, 2013 at 08:08:34AM -0800, Linus Torvalds wrote:
> On Wed, Mar 6, 2013 at 12:06 AM, Henrik Rydberg wrote:
> >
> > Or not. ;-) This commit breaks boot on my MacBookAir3,1:
> >
> > commit 8d57470d8f859635deffe3919d7d4867b488b85a
> > Author: Yinghai Lu
d calculating, it should be PMD_SIZE align.
> Otherwise in extreme case we could have less then 2M for the first step.
> In your case is about only (1M - 32k) for first step.
>
> Please try attached patch.
Bingo. Excellent, thank you Yinghai. I verified that it also boots on
top of Linus&#
> >> Can you check bootloader like grub.efi ?
> >
> > I checked, same story. I tried without EFI_STUB, no joy. I ran with
> > and without nouveau, just in case. Without the patch, everything
> > works. With the patch, nothing works, and no output at all.
> >
> > With a bit of luck, I could maybe
Hi Yinghai,
> >> Can you get a boot log with "debug memblock=debug" from the last
> >> successful commit point? Are you booting EFI or BootCamp?
> >
> > Attached the dmesg log, booting from f763ad1 which is on top of
> > 3.7-rc6. I am booting with EFI_STUB, straight into the kernel.
> > The comma
Hi Linus, Peter,
> I don't know if it's just me, but this merge window had more "Uhhuh"
> moments than I'm used to. I stopped merging a couple of times, because
> we had bugs that looked really scary, but thankfully each time people
> were on them like paparazzi on Justin Bieber. Special thanks to
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
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
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/
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
1 - 100 of 363 matches
Mail list logo
