AFAICS, nobody is working on writing a driver for the MacBook8,1
keyboard (which uses SPI as opposed to USB). Oddly, the vendor ID and
product ID are the same as the USB counterpart. Would it be possible
to port the logic of the hid-apple driver to SPI, or are the two
serial protocols too different
On Tue, 2015-09-22 at 11:22 -0400, Alan Stern wrote:
> On Tue, 22 Sep 2015, Oliver Neukum wrote:
>
> > Cancel, yes, going to low power is a consequence which needn't bother
> > the power subsystem.
>
> Going to low power needn't involve the power subsystem? That sounds
> weird.
Think of it li
Signed-of-by: Duson Lin
---
drivers/input/mouse/elan_i2c_core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index 16ac595..357670e 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++
On Mon, Sep 21, 2015 at 03:55:33PM -0700, Dmitry Torokhov wrote:
> On Sat, Sep 12, 2015 at 10:45:46AM -0700, Dmitry Torokhov wrote:
> > From: Franklin S Cooper Jr
> >
> > The current/old gpio framework used doesn't properly listen to
> > ACTIVE_LOW and ACTIVE_HIGH flags. The newer gpio framework
On Tue, 22 Sep 2015, Oliver Neukum wrote:
> > I'm not sure I understand what you're saying. Are you suggesting that
> > this "inhibit" mechanism should involve a new callback different from
>
> Yes, there is no necessary relation to power management. If you put
> your phone into your pocket, you
On Tue, 2015-09-22 at 10:15 -0400, Alan Stern wrote:
> On Tue, 22 Sep 2015, Oliver Neukum wrote:
>
> > Indeed. We can handle output to suspended devices by waking them.
> > I don't see why this case is different. We are talking about input
> > only.
> >
> > > The runtime-PM "usage" value for thes
On Tue, 22 Sep 2015, Oliver Neukum wrote:
> Indeed. We can handle output to suspended devices by waking them.
> I don't see why this case is different. We are talking about input
> only.
>
> > The runtime-PM "usage" value for these devices is a little tricky to
> > calculate. It should be nonze
My static checker complains that "value" comes from the user in
evdev_do_ioctl() and we check that it's not too large here but we don't
check that it's negative. It's harmless because the ->set_gain() and
->set_autocenter() functions truncate it to a valid u16 value, but we
may as well fix it just
Add a symlink to uapi/linux/linux-event-codes.h, and include that instead
of (re)defining all the evdev type and code values in
dt-bindings/input/input.h. This way we do not need to keep all the
event codes synced manually.
Signed-off-by: Hans de Goede
Acked-by: Rob Herring
---
Changes in v3:
-R
Add an input-event-codes header file and move all type and axis defines
there.
The purpose of this new header file is to have a single canonical source
for event-codes which can be used outside of C-code too. One example of
such usage is the use of event-codes in devicetree source files.
Signed-o
Hi Dmitry,
This patch-series really is 2 related series:
Patch 1 + 2:
Support for abs/rel axis in gpio_keys_polled, the dt-bindings patch is
updated, the actual implementation is the same as the v2 version.
Patch 3 + 4:
Add a single header with key / btn / axis defines to be shared by input.h
Add support for EV_ABS / EV_REL events to the gpio-keys-polled driver.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Fix commit message to actually describe what the patch does
(fix patch squashing fail)
---
drivers/input/keyboard/gpio_keys_polled.c | 88 +++
1 fi
The devicetree binding for gpio-keys-polled already allows specifying
what type of events (key / rel / abs) a button generates when pressed.
But for rel / abs axis we also need to specify which value this specific
gpio represents.
One usecase is digital joysticks / direction-pads which are hooked
Hi,
On 20-09-15 22:16, Hans de Goede wrote:
Hi,
Dmitry Torokhov wrote:
> > +for_each_set_bit(i, input->relbit, REL_CNT) {
> > +if (!test_bit(i, bdev->rel_axis_seen))
> > +input_event(input, EV_REL, i, 0);
> > +}
>
> I wonder if this should be written as
>
On Mon, 2015-09-21 at 16:02 -0400, Alan Stern wrote:
> On Mon, 21 Sep 2015, Dmitry Torokhov wrote:
>
> > > What happens if the "inhibit" control is turned on and the driver puts
> > > the device into runtime suspend, but then an I/O request arrives?
> > >
> > > If the I/O request originated fr
Hi
On Fri, Sep 18, 2015 at 1:00 AM, wrote:
> From: Stephen Chandler Paul
>
> Debugging input devices, specifically laptop touchpads, can be tricky
> without having the physical device handy. Here we try to remedy that
> with userio. This module allows an application to connect to a character
>
On 09/22/2015 11:13 AM, Andrzej Hajda wrote:
On 09/21/2015 03:42 PM, David Howells wrote:
Andrzej Hajda wrote:
Semantic patch finds comparisons of types:
unsigned < 0
unsigned >= 0
The former is always false, the latter is always true.
Such comparisons are useless, so theoretically
On 09/21/2015 03:42 PM, David Howells wrote:
> Andrzej Hajda wrote:
>
>> Semantic patch finds comparisons of types:
>> unsigned < 0
>> unsigned >= 0
>> The former is always false, the latter is always true.
>> Such comparisons are useless, so theoretically they could be
>> safely removed,
18 matches
Mail list logo
