in if Dmitry will accept it. It does seem to be a
quirk of some platforms that it is necessary, but it's only one line.
Thanks for spending so much time debugging this.
Signed-off-by: Nick Dyer nick.d...@itdev.co.uk
---
This patch was first sent as a part of a two part series along
with [PATCH 2/2
;
linux,gpio-keymap = 0 0 0 BTN_LEFT;
};
This maps BTN_LEFT to the 4th bit of the T19 message. I haven't looked up
what GPIO number that corresponds to on the mXT224SL that he has, it varies
with the particular maXTouch device you have.
Hope this helps.
Signed-off-by: Nick Dyer nick.d
On 27/08/14 15:22, Javier Martinez Canillas wrote:
If there was a BTN_NONE or KEY_UNUSED it would had been better but I think
that making a distinction between these two cases (reserved pin vs GPIO
available but not used) is useful.
Maybe Nick can comment here.
Yes, this is probably useful
On 09/09/14 11:21, Javier Martinez Canillas wrote:
On 09/09/2014 09:52 AM, Sjoerd Simons wrote:
For i2c devices in OF the modalias exposed to userspace is i2c:node
type, for the Maxtouch driver this is i2c:maxtouch.
Add maxtouch to the i2c id table such that userspace can correctly
load the
On 09/09/14 08:52, Sjoerd Simons wrote:
For i2c devices in OF the modalias exposed to userspace is i2c:node
type, for the Maxtouch driver this is i2c:maxtouch.
Add maxtouch to the i2c id table such that userspace can correctly
load the module for the device and drop the OF table as it's not
On 11/09/14 09:38, Javier Martinez Canillas wrote:
To expand on what Sjoerd already said and just to be sure everyone is on the
same page.
The problem is that right now the driver reports the following modalias:
# cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
i2c:maxtouch
but if you
On 11/09/14 12:41, Javier Martinez Canillas wrote:
On 09/11/2014 01:35 PM, Wolfram Sang wrote:
This is a workaround. It would make sense, however, to add it because we
want to support i2c_board_info structures.
I think it really depends if an IP block can be used on non-DT platforms
(which
makes sense, and is a nice description,
Acked-by: Stephen Warren swar...@nvidia.com
Hi Dmitry-
Something went a bit wrong in merging f5940231a - there's a bit of repeated
text that's been introduced.
Signed-off-by: Nick Dyer nick.d...@itdev.co.uk
---
Documentation/devicetree/bindings/input
so this series add support for the later.
The series is composed of the following patches:
Nick Dyer (1):
Input: atmel_mxt_ts - Implement support for T100 touch object
Hi Dmitry-
I posted an updated version of this patch on 9th December and would prefer
you apply that rather than
On 16/12/14 16:34, Javier Martinez Canillas wrote:
On 12/16/2014 05:16 PM, Nick Dyer wrote:
Nick Dyer (1):
Input: atmel_mxt_ts - Implement support for T100 touch object
I posted an updated version of this patch on 9th December and would prefer
you apply that rather than this version, since
On 16/12/14 16:49, Javier Martinez Canillas wrote:
Awesome, what do you think about the change to have a common input device
initialization function that I squashed in your original patch?
mxt_initialize_t100_input_device() and mxt_initialize_t9_input_device()
are very similar so I think that
On 16/12/14 17:46, Javier Martinez Canillas wrote:
On 12/16/2014 06:07 PM, Nick Dyer wrote:
I had been keeping them separate on the basis that we don't want changes to
support new T100 features to cause regressions in the old T9 handling. But
there is a fair amount of duplication as you say
12 matches
Mail list logo
