* Re: [PATCH] hid: uhid: improve uhid example client
From: Jiri Kosina @ 2013-09-04 9:37 UTC (permalink / raw)
To: David Herrmann; +Cc: Benjamin Tissoires, linux-input, Anderson Lizardo
In-Reply-To: <CANq1E4QwPRgCkROyLWNU7KtVDU6DAoLG+pD2_6brD90gSiJ9pg@mail.gmail.com>
On Mon, 2 Sep 2013, David Herrmann wrote:
> But thanks for the usb-spec hint, haven't looked there, yet.
There is also HID report descriptor tool available at
http://www.usb.org/developers/hidpage/
The tool itself isn't that earth-shaking (and you have to run it in wine
:) ), but it contains a load of pre-defined example descriptors for
various devices.
> No intention to modify it. Looks all good to me now.
Now applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] input: i8042 - add PNP modaliases
From: Tom Gundersen @ 2013-09-04 9:27 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Tom Gundersen, Matthew Garrett, Dmitry Torokhov
In-Reply-To: <20130903193547.GA8150@srcf.ucam.org>
This allows the module to be autoloaded in the common case.
In order to work on non-PnP systems the module should be compiled in or loaded
unconditionally at boot (c.f. modules-load.d(5)), as before.
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Tom Gundersen <teg@jklm.no>
---
This appears to work for me (though I don't have the real hardware to test), I get the following aliases:
alias: acpi*:CPQA0D7:*
alias: pnp:dCPQA0D7*
alias: acpi*:PNP0345:*
alias: pnp:dPNP0345*
alias: acpi*:PNP0344:*
alias: pnp:dPNP0344*
alias: acpi*:PNP0343:*
alias: pnp:dPNP0343*
alias: acpi*:PNP0320:*
alias: pnp:dPNP0320*
alias: acpi*:PNP030B:*
alias: pnp:dPNP030b*
alias: acpi*:PNP030A:*
alias: pnp:dPNP030a*
alias: acpi*:PNP0309:*
alias: pnp:dPNP0309*
alias: acpi*:PNP0306:*
alias: pnp:dPNP0306*
alias: acpi*:PNP0305:*
alias: pnp:dPNP0305*
alias: acpi*:PNP0304:*
alias: pnp:dPNP0304*
alias: acpi*:PNP0303:*
alias: pnp:dPNP0303*
alias: acpi*:PNP0302:*
alias: pnp:dPNP0302*
alias: acpi*:PNP0301:*
alias: pnp:dPNP0301*
alias: acpi*:PNP0300:*
alias: pnp:dPNP0300*
drivers/input/serio/i8042-x86ia64io.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
index 5f306f7..0ec9abb 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -765,6 +765,7 @@ static struct pnp_device_id pnp_kbd_devids[] = {
{ .id = "CPQA0D7", .driver_data = 0 },
{ .id = "", },
};
+MODULE_DEVICE_TABLE(pnp, pnp_kbd_devids);
static struct pnp_driver i8042_pnp_kbd_driver = {
.name = "i8042 kbd",
@@ -786,6 +787,7 @@ static struct pnp_device_id pnp_aux_devids[] = {
{ .id = "SYN0801", .driver_data = 0 },
{ .id = "", },
};
+MODULE_DEVICE_TABLE(pnp, pnp_aux_devids);
static struct pnp_driver i8042_pnp_aux_driver = {
.name = "i8042 aux",
--
1.8.4
^ permalink raw reply related
* Re: [PATCH] HID: Correct the USB IDs for the new Macbook Air 6
From: Jiri Kosina @ 2013-09-04 8:51 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Henrik Rydberg, linux-input, linux-kernel
In-Reply-To: <20130903180416.GB25985@core.coreip.homeip.net>
On Tue, 3 Sep 2013, Dmitry Torokhov wrote:
> > > A recent patch (9d9a04ee) added support for the new machine, but got
> > > the sequence of USB ids wrong. Reports from both Ian and Linus T show
> > > that the 0x0291 id is for ISO, not ANSI, which should have the missing
> > > number 0x0290. This patchs moves the three numbers accordingly, fixing
> > > the problem.
> > >
> > > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > Reported-and-tested-by: Ian Munsie <darkstarsword@gmail.com>
> > > Tested-by: Linus G Thiel <linus@hanssonlarsson.se>
> > > Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> > > ---
> > > 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?
> >
> > Absolutely ... waiting for Dmitry's Ack.
>
> And here it is:
>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Perfect, thanks. Will push it to Linus this merge window.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/3] Input/HID: Guitar/Drums support
From: Jiri Kosina @ 2013-09-04 8:46 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-input, Nicolas Adenis-Lamarre, Dmitry Torokhov
In-Reply-To: <1377537288-19289-1-git-send-email-dh.herrmann@gmail.com>
On Mon, 26 Aug 2013, David Herrmann wrote:
> This series adds wiimote extension support for guitars and drums.
Applied, thanks!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* synaptics_usb trackpoint
From: Andrew Deason @ 2013-09-04 4:42 UTC (permalink / raw)
To: linux-input
I have an ultranav usb keyboard, which is recognized by the
synaptics_usb driver (model SK-8835, FRU 02R0400, USB device 06CB:0009).
When the kernel is built with synaptics_usb support, the device uses the
"advanced" non-HID interface and the trackpoint becomes very difficult
to use, and certainly does not "feel" like other trackpoint devices. I
believe this is due to incorrect interpretation of the data from the
relevant USB device; the module comments indeed indicate that the driver
has not been well tested with pointing sticks.
I want to make some changes to the driver wrt trackpoints, but I wanted
to ask for some feedback on this before I go off down the wrong path.
Jan Steinhoff kindly directed me here. Anyway, details:
Right now, synaptics_usb just sends the raw numbers from the USB
responses as input event relative coordinates after trimming off some
low-order bits (see synusb_report_stick). That is, we get (0x52, 0x42)
from the device, and we report relative movement of around (0x5, 0x4).
But the values we get from the USB device don't seem very much like
coordinates to me. They appear to be readings from the force sensors on
the trackpoint in the x, y, and z directions. From what I have found
when reading about trackpoint devices, these forces do not directly
correspond to relative cursor movement, but are supposed to be
interpreted through a transfer function that translates them to cursor
velocity, which is then to be translated into movements at certain
intervals.
There may be different transfer functions that are possible to use, but
one such transfer function I've found is in the trackpoint 4 engineering
spec [1]. That's where the various settings like 'sensitivity', 'speed',
etc come into play for trackpoint devices where this translation is done
in the hardware. That document doesn't give all of the necessary
constants for generating that specific function, but it gives a general
idea. I've got some code to roughly approximate that curve in an x.org
input driver, and it seems to work pretty well considering that I'm
making some guesses.
But it seems like this translation should occur in the synaptics_usb
driver. Or at least, even if it doesn't, the reported values should not
be reported as REL_X and REL_Y events, since they are not relative
cursor coordinates. The z coordinate still seems like it could just stay
as ABS_PRESSURE, and features like "Press to Select" could be
implemented in a userspace driver. But I personally don't really care
about the z axis at all, since I never use any of the PtS functionality.
Furthermore, I really think there should be a runtime option to switch
the device between "advanced" mode and HID mode. Especially for the
trackpoint, the transfer function is not trivial and its "correctness"
may be subjective. Right now a system without a synaptics_usb-like
driver is better off than Linux, since such a system would use the
generic HID mode, and would be more usable. Maybe even the HID mode
should be the default, and we only switch to 'advanced' mode on request,
if the user wants to change e.g. sensitivity settings or PtS.
So, thoughts? I haven't fiddled with adding anything like this to the
synaptics_usb driver yet, but I was planning on doing that as soon as I
sent this out and didn't hear any objections.
[1] <http://blogs.epfl.ch/icenet/documents/Ykt3Eext.pdf>. A graph of the
transfer function is on page 43, and some of the other relevant
parameters are described on page 24 and 44.
--
Andrew Deason
adeason@dson.org
^ permalink raw reply
* [PATCH 1/3 v3] Input: wacom - Support EMR and MFT sensors of Cintiq Companion Hybrid
From: Jason Gerecke @ 2013-09-03 21:52 UTC (permalink / raw)
To: linuxwacom-devel, linux-input, pinglinux, peter.hutterer; +Cc: Jason Gerecke
In-Reply-To: <1377220537-1474-1-git-send-email-killertofu@gmail.com>
Adds support for the sensors integrated in to the Cintiq Companion
Hybrid. These sensors use by-and-large the same protocol as the
Cintiq 24HD touch.
NOTE: The ExpressKeys on the Cintiq Companion Hybrid are wired to
both the EMR controller and CPU GPIO pins. It may be necessary to
disable their functionality in this driver if building a custom
Android kernel for this device (lest two events be sent to userspace
for every button press).
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
---
Changes in v3:
* Change type name from 'ASTERIX' to 'CINTIQ_HYBRID'
Changes in v2:
* Remove "#if 1" block surrounding conditional ExpressKey reporting
* Change to C-style comments
drivers/input/tablet/wacom_sys.c | 2 +-
drivers/input/tablet/wacom_wac.c | 46 +++++++++++++++++++++++++++++++++++++++-
drivers/input/tablet/wacom_wac.h | 1 +
3 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
index 1ad3e07..0750d2a 100644
--- a/drivers/input/tablet/wacom_sys.c
+++ b/drivers/input/tablet/wacom_sys.c
@@ -548,7 +548,7 @@ static int wacom_query_tablet_data(struct usb_interface *intf, struct wacom_feat
/* MT Tablet PC touch */
return wacom_set_device_mode(intf, 3, 4, 4);
}
- else if (features->type == WACOM_24HDT) {
+ else if (features->type == WACOM_24HDT || features->type == CINTIQ_HYBRID) {
return wacom_set_device_mode(intf, 18, 3, 2);
}
} else if (features->device_type == BTN_TOOL_PEN) {
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 541197b..d68bf73 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -475,7 +475,7 @@ static void wacom_intuos_general(struct wacom_wac *wacom)
/* general pen packet */
if ((data[1] & 0xb8) == 0xa0) {
t = (data[6] << 2) | ((data[7] >> 6) & 3);
- if (features->type >= INTUOS4S && features->type <= WACOM_24HD) {
+ if (features->type >= INTUOS4S && features->type <= CINTIQ_HYBRID) {
t = (t << 1) | (data[1] & 1);
}
input_report_abs(input, ABS_PRESSURE, t);
@@ -619,6 +619,22 @@ static int wacom_intuos_irq(struct wacom_wac *wacom)
} else {
input_report_abs(input, ABS_MISC, 0);
}
+ } else if (features->type == CINTIQ_HYBRID) {
+ /*
+ * Do not send hardware buttons under Android. They
+ * are already sent to the system through GPIO (and
+ * have different meaning).
+ */
+ input_report_key(input, BTN_1, (data[4] & 0x01));
+ input_report_key(input, BTN_2, (data[4] & 0x02));
+ input_report_key(input, BTN_3, (data[4] & 0x04));
+ input_report_key(input, BTN_4, (data[4] & 0x08));
+
+ input_report_key(input, BTN_5, (data[4] & 0x10)); /* Right */
+ input_report_key(input, BTN_6, (data[4] & 0x20)); /* Up */
+ input_report_key(input, BTN_7, (data[4] & 0x40)); /* Left */
+ input_report_key(input, BTN_8, (data[4] & 0x80)); /* Down */
+ input_report_key(input, BTN_0, (data[3] & 0x01)); /* Center */
} else if (features->type >= INTUOS5S && features->type <= INTUOS5L) {
int i;
@@ -1325,6 +1341,7 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
case WACOM_22HD:
case WACOM_24HD:
case DTK:
+ case CINTIQ_HYBRID:
sync = wacom_intuos_irq(wacom_wac);
break;
@@ -1763,6 +1780,24 @@ int wacom_setup_input_capabilities(struct input_dev *input_dev,
0, 0);
}
break;
+
+ case CINTIQ_HYBRID:
+ __set_bit(BTN_1, input_dev->keybit);
+ __set_bit(BTN_2, input_dev->keybit);
+ __set_bit(BTN_3, input_dev->keybit);
+ __set_bit(BTN_4, input_dev->keybit);
+
+ __set_bit(BTN_5, input_dev->keybit);
+ __set_bit(BTN_6, input_dev->keybit);
+ __set_bit(BTN_7, input_dev->keybit);
+ __set_bit(BTN_8, input_dev->keybit);
+ __set_bit(BTN_0, input_dev->keybit);
+
+ input_set_abs_params(input_dev, ABS_Z, -900, 899, 0, 0);
+ __set_bit(INPUT_PROP_DIRECT, input_dev->propbit);
+
+ wacom_setup_cintiq(wacom_wac);
+ break;
}
return 0;
}
@@ -2117,6 +2152,13 @@ static const struct wacom_features wacom_features_0xDF =
static const struct wacom_features wacom_features_0x6004 =
{ "ISD-V4", WACOM_PKGLEN_GRAPHIRE, 12800, 8000, 255,
0, TABLETPC, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
+static const struct wacom_features wacom_features_0x0307 =
+ { "Wacom ISDv5 307", WACOM_PKGLEN_INTUOS, 59552, 33848, 2047,
+ 63, CINTIQ_HYBRID, WACOM_INTUOS3_RES, WACOM_INTUOS3_RES,
+ .oVid = USB_VENDOR_ID_WACOM, .oPid = 0x309 };
+static const struct wacom_features wacom_features_0x0309 =
+ { "Wacom ISDv5 309", .type = WACOM_24HDT, /* Touch */
+ .oVid = USB_VENDOR_ID_WACOM, .oPid = 0x0307, .touch_max = 10 };
#define USB_DEVICE_WACOM(prod) \
USB_DEVICE(USB_VENDOR_ID_WACOM, prod), \
@@ -2247,6 +2289,8 @@ const struct usb_device_id wacom_ids[] = {
{ USB_DEVICE_WACOM(0xF8) },
{ USB_DEVICE_DETAILED(0xF6, USB_CLASS_HID, 0, 0) },
{ USB_DEVICE_WACOM(0xFA) },
+ { USB_DEVICE_WACOM(0x0307) },
+ { USB_DEVICE_DETAILED(0x0309, USB_CLASS_HID, 0, 0) },
{ USB_DEVICE_LENOVO(0x6004) },
{ }
};
diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
index dfc9e08..90ce10d 100644
--- a/drivers/input/tablet/wacom_wac.h
+++ b/drivers/input/tablet/wacom_wac.h
@@ -80,6 +80,7 @@ enum {
WACOM_22HD,
DTK,
WACOM_24HD,
+ CINTIQ_HYBRID,
CINTIQ,
WACOM_BEE,
WACOM_13HD,
--
1.8.3.4
^ permalink raw reply related
* Re: [PATCH 1/3] Input: introduce BTN/ABS bits for drums and guitars
From: David Herrmann @ 2013-09-03 21:14 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Jiri Kosina, open list:HID CORE LAYER
In-Reply-To: <20130903180528.GC25985@core.coreip.homeip.net>
Hi
On Tue, Sep 3, 2013 at 8:05 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Mon, Sep 02, 2013 at 01:41:57PM +0200, Jiri Kosina wrote:
>> On Mon, 26 Aug 2013, David Herrmann wrote:
>>
>> > There are a bunch of guitar and drums devices out there that all report
>> > similar data. To avoid reporting this as BTN_MISC or ABS_MISC, we
>> > allocate some proper namespace for them. Note that most of these devices
>> > are toys and we cannot report any sophisticated physics via this API.
>> >
>> > I did some google-images research and tried to provide definitions that
>> > work with all common devices. That's why I went with 4 toms, 4 cymbals,
>> > one bass, one hi-hat. I haven't seen other drums and I doubt that we need
>> > any additions to that. Anyway, the naming-scheme is intentionally done in
>> > an extensible way.
>> >
>> > For guitars, we support 5 frets (normally aligned vertically, compared to
>> > the real horizontal layouts), a single strum-bar with up/down directions,
>> > an optional fret-board and a whammy-bar.
>> >
>> > Most of the devices provide pressure values so I went with ABS_* bits. If
>> > we ever support devices which only provide digital input, we have to
>> > decide whether to emulate pressure data or add additional BTN_* bits.
>> >
>> > If someone is not familiar with these devices, here are two pictures which
>> > provide almost all introduced interfaces (or try the given keywords
>> > with a google-image search):
>> > Guitar: ("guitar hero world tour guitar")
>> > http://images1.wikia.nocookie.net/__cb20120911023442/applezone/es/images/f/f9/Wii_Guitar.jpg
>> > Drums: ("guitar hero drums")
>> > http://oyster.ignimgs.com/franchises/images/03/55/35526_band-hero-drum-set-hands-on-20090929040735768.jpg
>> >
>> > Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>>
>> Hi,
>>
>> I have reviewed and like the implementation of 2/3 and 3/3, but I of
>> course would like to have Ack from Dmitry for this, so that I could take
>> it through my tree together with the rest of the patchset.
>>
>> Dmitry, pretty please?
>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> We might want to see how much memory is taken now by ABS structures and
> think if we could reduce it somehow...
Thanks Dmitry! And I thought about the "absinfo"-size, too. Some rough numbers:
sizeof(struct input_absinfo) = 24 bytes
ABS_CNT * sizeof(struct input_absinfo) = 0x50 * 24 bytes = 1920 bytes
sizeof(struct input_dev) = 1824 bytes
name, phys, uniq + misc ~= 100 bytes
dev->vals ~= 10 * sizeof(struct input_value) = 10 * 8 bytes = 80 bytes
So we get 1824 + 100 + 80 = 2008 bytes for an average trivial input device.
The abs-values add 1920 bytes to that. So I don't think it's that bad.
Anyway, some trivial ideas off the top of my head:
1)
Changing "absinfo" to double-indirection:
struct input_absinfo *absinfo[ABS_CNT];
struct input_absinfo *real_absinfo;
We allocate "real_absinfo" as array for as many ABS entries as we need
and set the pointers in "absinfo" accordingly (setting everything else
to NULL).
This, however, still adds ABS_CNT * 8 = 0x50 * 8 = 640 bytes only for
the pointer array. So not really much better. And we get the
additional TLB lookup for the double-indirection. I don't know whether
it matters for the quite expensive input-handling, though.
2)
Using idr. But considering that most input-devices only have very few
(<10?) ABS bits set, it probably doesn't scale.
3)
An rbtree for all absinfo objects. Only adds 24 bytes per absinfo and
lookup is only needed once in input_handle_abs_event(). It takes the
least space of all (except for linear search) and it's still
reasonably fast for all setups.
All in all, if we assume <10 input devices on a machine, we would save
around 20kb with 3). I am not sure what impact it has on performance.
But looking at the deep call-chains in input-interrupts, I doubt it
would be noticeable. But that's only a rough guess..
4)
We let drivers manage absinfo objects and pass it together with
input_event() (for ABS only). Would probably be the nicest solution
but require huge codebase changes.
But maybe someone else has some way better ideas.. It's getting late here.
Cheers
David
^ permalink raw reply
* Re: [PATCH] input: allow SERIO=m even without EXPERT=y
From: Matthew Garrett @ 2013-09-03 19:35 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Tom Gundersen, linux-input@vger.kernel.org, LKML
In-Reply-To: <20130903192421.GA26734@core.coreip.homeip.net>
On Tue, Sep 03, 2013 at 12:24:21PM -0700, Dmitry Torokhov wrote:
> Presumably such systems would carry over their .config which would have
> these as built-in.
Yeah, but distributions should still be given guidance on their default
configs.
> i8042 is old-style platform driver, so nothing will load it if it is
> compiled as a module. This one worries me most.
We could add the PNP aliases for it.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH] input: allow SERIO=m even without EXPERT=y
From: Dmitry Torokhov @ 2013-09-03 19:24 UTC (permalink / raw)
To: Tom Gundersen; +Cc: Matthew Garrett, linux-input@vger.kernel.org, LKML
In-Reply-To: <CAG-2HqVK+nH4+AFrBUmr6wp1zfTeUdLArmXxZxC4TwuPSSkKZg@mail.gmail.com>
On Tue, Sep 03, 2013 at 06:25:28PM +0200, Tom Gundersen wrote:
> On Tue, Sep 3, 2013 at 5:02 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > On Mon, Sep 02, 2013 at 08:47:10PM +0200, Tom Gundersen wrote:
> >> There is plenty of consumer hardware (e.g., mac books) that does not use
> >> AT keyboards or PS/2 mice. It therefore makes sense for distro kernels
> >> to build the related drivers as modules to avoid loading them on hardware
> >> that does not need them. As such, these options should no longer be protected
> >> by EXPERT.
> >
> > There are systems (although, with luck, only *very* old ones) where the
> > modules won't get autoloaded. You should probably mention that in the
> > help text.
>
> Good point, if this turns out to be a problem on current hardware
> distros probably want to load the modules automatically at boot by
> default.
Presumably such systems would carry over their .config which would have
these as built-in.
>
> Does this problem only apply to the i8042 module or also atkbd and libps2?
Atkbd should be able to load automatically (as long as modutils support
SERIO bus, which any recentish - 5 years? - modutils should do).
libps2 should load automatically to resolve dependencies of
atkbd/psmouse.
i8042 is old-style platform driver, so nothing will load it if it is
compiled as a module. This one worries me most.
mousedev should load automatically if something tries to open it's
device nodes.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: input: i8042 possible bug
From: Dmitry Torokhov @ 2013-09-03 18:11 UTC (permalink / raw)
To: Andrey Moiseev; +Cc: linux-input, linux-kernel
In-Reply-To: <52261EBE.5010007@gmail.com>
On Tue, Sep 03, 2013 at 09:39:10PM +0400, Andrey Moiseev wrote:
> Here is an extract from drivers/input/serio/i8042.c:
> >
> > static int i8042_flush(void)
> > {
> > unsigned long flags;
> > unsigned char data, str;
> > int i = 0;
> >
> > spin_lock_irqsave(&i8042_lock, flags);
> >
> > while (((str = i8042_read_status()) & I8042_STR_OBF) && (i < I8042_BUFFER_SIZE)) {
> > udelay(50);
> > data = i8042_read_data();
> > i++;
> > dbg("%02x <- i8042 (flush, %s)\n",
> > data, str & I8042_STR_AUXDATA ? "aux" : "kbd");
> > }
> >
> > spin_unlock_irqrestore(&i8042_lock, flags);
> >
> > return i;
> > }
> >
> > static int i8042_controller_check(void)
> > {
> > if (i8042_flush() == I8042_BUFFER_SIZE) {
> Doesn't it panic needlessly, while the buffer was initially full?
It appears so. We probably want to change it to return -1 if we still
see OBF after fetching I8042_BUFFER_SIZE characters.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/3] Input: introduce BTN/ABS bits for drums and guitars
From: Dmitry Torokhov @ 2013-09-03 18:05 UTC (permalink / raw)
To: Jiri Kosina; +Cc: David Herrmann, linux-input, Nicolas Adenis-Lamarre
In-Reply-To: <alpine.LNX.2.00.1309021341090.3796@pobox.suse.cz>
On Mon, Sep 02, 2013 at 01:41:57PM +0200, Jiri Kosina wrote:
> On Mon, 26 Aug 2013, David Herrmann wrote:
>
> > There are a bunch of guitar and drums devices out there that all report
> > similar data. To avoid reporting this as BTN_MISC or ABS_MISC, we
> > allocate some proper namespace for them. Note that most of these devices
> > are toys and we cannot report any sophisticated physics via this API.
> >
> > I did some google-images research and tried to provide definitions that
> > work with all common devices. That's why I went with 4 toms, 4 cymbals,
> > one bass, one hi-hat. I haven't seen other drums and I doubt that we need
> > any additions to that. Anyway, the naming-scheme is intentionally done in
> > an extensible way.
> >
> > For guitars, we support 5 frets (normally aligned vertically, compared to
> > the real horizontal layouts), a single strum-bar with up/down directions,
> > an optional fret-board and a whammy-bar.
> >
> > Most of the devices provide pressure values so I went with ABS_* bits. If
> > we ever support devices which only provide digital input, we have to
> > decide whether to emulate pressure data or add additional BTN_* bits.
> >
> > If someone is not familiar with these devices, here are two pictures which
> > provide almost all introduced interfaces (or try the given keywords
> > with a google-image search):
> > Guitar: ("guitar hero world tour guitar")
> > http://images1.wikia.nocookie.net/__cb20120911023442/applezone/es/images/f/f9/Wii_Guitar.jpg
> > Drums: ("guitar hero drums")
> > http://oyster.ignimgs.com/franchises/images/03/55/35526_band-hero-drum-set-hands-on-20090929040735768.jpg
> >
> > Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>
> Hi,
>
> I have reviewed and like the implementation of 2/3 and 3/3, but I of
> course would like to have Ack from Dmitry for this, so that I could take
> it through my tree together with the rest of the patchset.
>
> Dmitry, pretty please?
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
We might want to see how much memory is taken now by ABS structures and
think if we could reduce it somehow...
Thanks.
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: Correct the USB IDs for the new Macbook Air 6
From: Dmitry Torokhov @ 2013-09-03 18:04 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Henrik Rydberg, linux-input, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1309021329510.3796@pobox.suse.cz>
On Mon, Sep 02, 2013 at 01:30:07PM +0200, Jiri Kosina wrote:
> On Sun, 1 Sep 2013, Henrik Rydberg wrote:
>
> > A recent patch (9d9a04ee) added support for the new machine, but got
> > the sequence of USB ids wrong. Reports from both Ian and Linus T show
> > that the 0x0291 id is for ISO, not ANSI, which should have the missing
> > number 0x0290. This patchs moves the three numbers accordingly, fixing
> > the problem.
> >
> > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Reported-and-tested-by: Ian Munsie <darkstarsword@gmail.com>
> > Tested-by: Linus G Thiel <linus@hanssonlarsson.se>
> > Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
> > ---
> > 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?
>
> Absolutely ... waiting for Dmitry's Ack.
And here it is:
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: Behaviour of input-polldev?
From: Dmitry Torokhov @ 2013-09-03 18:03 UTC (permalink / raw)
To: David Herrmann; +Cc: Florian Echtler, linux-input
In-Reply-To: <CANq1E4Tr4gigvtTA7mqDgqjGfjGaLM477D2uW4qdFGkySaGPWA@mail.gmail.com>
On Tue, Sep 03, 2013 at 01:54:45PM +0200, David Herrmann wrote:
> Hi Florian
>
> On Tue, Sep 3, 2013 at 1:39 PM, Florian Echtler <floe@butterbrot.org> wrote:
> > Hello everyone,
> >
> > I'm in the process of writing an input driver for the Microsoft
> > Pixelsense (formerly Surface 2.0). The device only has bulk endpoints
> > and consequently needs to be polled regularly. My beta driver uses
> > input-polldev for this, and it appears to work nicely, however, I
> > couldn't find out how input-polldev behaves if one polling cycle takes
> > longer than expected and a new poll would already be triggered while the
> > first one is still running?
With input-polldev new poll can not get scheduled until driver's poll()
method returns:
static void input_polled_device_work(struct work_struct *work)
{
struct input_polled_dev *dev =
container_of(work, struct input_polled_dev, work.work);
dev->poll(dev);
input_polldev_queue_work(dev);
}
The expectation here is that poll function is quick and does not
introduce much skew into scheduling of polls (although of course error
is accumulating).
--
Dmitry
^ permalink raw reply
* input: i8042 possible bug
From: Andrey Moiseev @ 2013-09-03 17:39 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, linux-kernel
Here is an extract from drivers/input/serio/i8042.c:
>
> static int i8042_flush(void)
> {
> unsigned long flags;
> unsigned char data, str;
> int i = 0;
>
> spin_lock_irqsave(&i8042_lock, flags);
>
> while (((str = i8042_read_status()) & I8042_STR_OBF) && (i < I8042_BUFFER_SIZE)) {
> udelay(50);
> data = i8042_read_data();
> i++;
> dbg("%02x <- i8042 (flush, %s)\n",
> data, str & I8042_STR_AUXDATA ? "aux" : "kbd");
> }
>
> spin_unlock_irqrestore(&i8042_lock, flags);
>
> return i;
> }
>
> static int i8042_controller_check(void)
> {
> if (i8042_flush() == I8042_BUFFER_SIZE) {
Doesn't it panic needlessly, while the buffer was initially full?
> pr_err("No controller found\n");
> return -ENODEV;
> }
>
> return 0;
> }
^ permalink raw reply
* Re: [PATCH] input: allow SERIO=m even without EXPERT=y
From: Tom Gundersen @ 2013-09-03 16:25 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-input@vger.kernel.org, LKML, Dmitry Torokhov
In-Reply-To: <20130903150226.GA2392@srcf.ucam.org>
On Tue, Sep 3, 2013 at 5:02 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Mon, Sep 02, 2013 at 08:47:10PM +0200, Tom Gundersen wrote:
>> There is plenty of consumer hardware (e.g., mac books) that does not use
>> AT keyboards or PS/2 mice. It therefore makes sense for distro kernels
>> to build the related drivers as modules to avoid loading them on hardware
>> that does not need them. As such, these options should no longer be protected
>> by EXPERT.
>
> There are systems (although, with luck, only *very* old ones) where the
> modules won't get autoloaded. You should probably mention that in the
> help text.
Good point, if this turns out to be a problem on current hardware
distros probably want to load the modules automatically at boot by
default.
Does this problem only apply to the i8042 module or also atkbd and libps2?
Cheers,
Tom
^ permalink raw reply
* Re: [PATCH v2] hid-wiimote: print small buffers via %*phC
From: David Herrmann @ 2013-09-03 15:08 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: David Herrmann, Jiri Kosina, open list:HID CORE LAYER
In-Reply-To: <1378219706-20252-1-git-send-email-andriy.shevchenko@linux.intel.com>
Hi
On Tue, Sep 3, 2013 at 4:48 PM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> Instead of passing each byte through stack let's use %*phC specifier to dump
> buffer as a hex string.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Acked-by: David Herrmann <dh.herrmann@gmail.com>
Thanks a lot. Looks much nicer now. Now also:
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Thanks
David
> ---
> drivers/hid/hid-wiimote-core.c | 17 ++++++-----------
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/hid/hid-wiimote-core.c b/drivers/hid/hid-wiimote-core.c
> index 6602098..abb20db 100644
> --- a/drivers/hid/hid-wiimote-core.c
> +++ b/drivers/hid/hid-wiimote-core.c
> @@ -441,8 +441,7 @@ static __u8 wiimote_cmd_read_ext(struct wiimote_data *wdata, __u8 *rmem)
> if (ret != 6)
> return WIIMOTE_EXT_NONE;
>
> - hid_dbg(wdata->hdev, "extension ID: %02x:%02x %02x:%02x %02x:%02x\n",
> - rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
> + hid_dbg(wdata->hdev, "extension ID: %6phC\n", rmem);
>
> if (rmem[0] == 0xff && rmem[1] == 0xff && rmem[2] == 0xff &&
> rmem[3] == 0xff && rmem[4] == 0xff && rmem[5] == 0xff)
> @@ -512,14 +511,12 @@ static bool wiimote_cmd_read_mp(struct wiimote_data *wdata, __u8 *rmem)
> if (ret != 6)
> return false;
>
> - hid_dbg(wdata->hdev, "motion plus ID: %02x:%02x %02x:%02x %02x:%02x\n",
> - rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
> + hid_dbg(wdata->hdev, "motion plus ID: %6phC\n", rmem);
>
> if (rmem[5] == 0x05)
> return true;
>
> - hid_info(wdata->hdev, "unknown motion plus ID: %02x:%02x %02x:%02x %02x:%02x\n",
> - rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
> + hid_info(wdata->hdev, "unknown motion plus ID: %6phC\n", rmem);
>
> return false;
> }
> @@ -535,8 +532,7 @@ static __u8 wiimote_cmd_read_mp_mapped(struct wiimote_data *wdata)
> if (ret != 6)
> return WIIMOTE_MP_NONE;
>
> - hid_dbg(wdata->hdev, "mapped motion plus ID: %02x:%02x %02x:%02x %02x:%02x\n",
> - rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
> + hid_dbg(wdata->hdev, "mapped motion plus ID: %6phC\n", rmem);
>
> if (rmem[0] == 0xff && rmem[1] == 0xff && rmem[2] == 0xff &&
> rmem[3] == 0xff && rmem[4] == 0xff && rmem[5] == 0xff)
> @@ -1128,9 +1124,8 @@ static void wiimote_init_hotplug(struct wiimote_data *wdata)
> wiimote_ext_unload(wdata);
>
> if (exttype == WIIMOTE_EXT_UNKNOWN) {
> - hid_info(wdata->hdev, "cannot detect extension; %02x:%02x %02x:%02x %02x:%02x\n",
> - extdata[0], extdata[1], extdata[2],
> - extdata[3], extdata[4], extdata[5]);
> + hid_info(wdata->hdev, "cannot detect extension; %6phC\n",
> + extdata);
> } else if (exttype == WIIMOTE_EXT_NONE) {
> spin_lock_irq(&wdata->state.lock);
> wdata->state.exttype = WIIMOTE_EXT_NONE;
> --
> 1.8.4.rc3
>
^ permalink raw reply
* Re: [PATCH] input: allow SERIO=m even without EXPERT=y
From: Matthew Garrett @ 2013-09-03 15:02 UTC (permalink / raw)
To: Tom Gundersen; +Cc: linux-input, linux-kernel, Dmitry Torokhov
In-Reply-To: <1378147630-12471-1-git-send-email-teg@jklm.no>
On Mon, Sep 02, 2013 at 08:47:10PM +0200, Tom Gundersen wrote:
> There is plenty of consumer hardware (e.g., mac books) that does not use
> AT keyboards or PS/2 mice. It therefore makes sense for distro kernels
> to build the related drivers as modules to avoid loading them on hardware
> that does not need them. As such, these options should no longer be protected
> by EXPERT.
There are systems (although, with luck, only *very* old ones) where the
modules won't get autoloaded. You should probably mention that in the
help text.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* [PATCH v2] hid-wiimote: print small buffers via %*phC
From: Andy Shevchenko @ 2013-09-03 14:48 UTC (permalink / raw)
To: David Herrmann, Jiri Kosina, linux-input; +Cc: Andy Shevchenko
Instead of passing each byte through stack let's use %*phC specifier to dump
buffer as a hex string.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: David Herrmann <dh.herrmann@gmail.com>
---
drivers/hid/hid-wiimote-core.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/hid-wiimote-core.c b/drivers/hid/hid-wiimote-core.c
index 6602098..abb20db 100644
--- a/drivers/hid/hid-wiimote-core.c
+++ b/drivers/hid/hid-wiimote-core.c
@@ -441,8 +441,7 @@ static __u8 wiimote_cmd_read_ext(struct wiimote_data *wdata, __u8 *rmem)
if (ret != 6)
return WIIMOTE_EXT_NONE;
- hid_dbg(wdata->hdev, "extension ID: %02x:%02x %02x:%02x %02x:%02x\n",
- rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
+ hid_dbg(wdata->hdev, "extension ID: %6phC\n", rmem);
if (rmem[0] == 0xff && rmem[1] == 0xff && rmem[2] == 0xff &&
rmem[3] == 0xff && rmem[4] == 0xff && rmem[5] == 0xff)
@@ -512,14 +511,12 @@ static bool wiimote_cmd_read_mp(struct wiimote_data *wdata, __u8 *rmem)
if (ret != 6)
return false;
- hid_dbg(wdata->hdev, "motion plus ID: %02x:%02x %02x:%02x %02x:%02x\n",
- rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
+ hid_dbg(wdata->hdev, "motion plus ID: %6phC\n", rmem);
if (rmem[5] == 0x05)
return true;
- hid_info(wdata->hdev, "unknown motion plus ID: %02x:%02x %02x:%02x %02x:%02x\n",
- rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
+ hid_info(wdata->hdev, "unknown motion plus ID: %6phC\n", rmem);
return false;
}
@@ -535,8 +532,7 @@ static __u8 wiimote_cmd_read_mp_mapped(struct wiimote_data *wdata)
if (ret != 6)
return WIIMOTE_MP_NONE;
- hid_dbg(wdata->hdev, "mapped motion plus ID: %02x:%02x %02x:%02x %02x:%02x\n",
- rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
+ hid_dbg(wdata->hdev, "mapped motion plus ID: %6phC\n", rmem);
if (rmem[0] == 0xff && rmem[1] == 0xff && rmem[2] == 0xff &&
rmem[3] == 0xff && rmem[4] == 0xff && rmem[5] == 0xff)
@@ -1128,9 +1124,8 @@ static void wiimote_init_hotplug(struct wiimote_data *wdata)
wiimote_ext_unload(wdata);
if (exttype == WIIMOTE_EXT_UNKNOWN) {
- hid_info(wdata->hdev, "cannot detect extension; %02x:%02x %02x:%02x %02x:%02x\n",
- extdata[0], extdata[1], extdata[2],
- extdata[3], extdata[4], extdata[5]);
+ hid_info(wdata->hdev, "cannot detect extension; %6phC\n",
+ extdata);
} else if (exttype == WIIMOTE_EXT_NONE) {
spin_lock_irq(&wdata->state.lock);
wdata->state.exttype = WIIMOTE_EXT_NONE;
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH 1/2] input: allow SERIO=m even without EXPERT=y
From: Tom Gundersen @ 2013-09-03 13:41 UTC (permalink / raw)
To: linux-input@vger.kernel.org; +Cc: LKML, Tom Gundersen, Dmitry Torokhov
In-Reply-To: <1378215656-11827-1-git-send-email-teg@jklm.no>
Sorry, this resend was accidental, please ignore. I only intended to
send patch 2/2.
On Tue, Sep 3, 2013 at 3:40 PM, Tom Gundersen <teg@jklm.no> wrote:
> There is plenty of consumer hardware (e.g., mac books) that does not use
> AT keyboards or PS/2 mice. It therefore makes sense for distro kernels
> to build the related drivers as modules to avoid loading them on hardware
> that does not need them. As such, these options should no longer be protected
> by EXPERT.
>
> Moreover, building these drivers as modules gets rid of the following ugly
> error during boot:
>
> [ 2.337745] i8042: PNP: No PS/2 controller found. Probing ports directly.
> [ 3.439537] i8042: No controller found
>
> Signed-off-by: Tom Gundersen <teg@jklm.no>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> drivers/input/keyboard/Kconfig | 4 ++--
> drivers/input/serio/Kconfig | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 269d4c3..2d31cec 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -2,7 +2,7 @@
> # Input core configuration
> #
> menuconfig INPUT_KEYBOARD
> - bool "Keyboards" if EXPERT || !X86
> + bool "Keyboards"
> default y
> help
> Say Y here, and a list of supported keyboards will be displayed.
> @@ -67,7 +67,7 @@ config KEYBOARD_ATARI
> module will be called atakbd.
>
> config KEYBOARD_ATKBD
> - tristate "AT keyboard" if EXPERT || !X86
> + tristate "AT keyboard"
> default y
> select SERIO
> select SERIO_LIBPS2
> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
> index 1e691a3..39c869d 100644
> --- a/drivers/input/serio/Kconfig
> +++ b/drivers/input/serio/Kconfig
> @@ -2,7 +2,7 @@
> # Input core configuration
> #
> config SERIO
> - tristate "Serial I/O support" if EXPERT || !X86
> + tristate "Serial I/O support"
> default y
> help
> Say Yes here if you have any input device that uses serial I/O to
> @@ -19,7 +19,7 @@ config SERIO
> if SERIO
>
> config SERIO_I8042
> - tristate "i8042 PC Keyboard controller" if EXPERT || !X86
> + tristate "i8042 PC Keyboard controller"
> default y
> depends on !PARISC && (!ARM || ARCH_SHARK || FOOTBRIDGE_HOST) && \
> (!SUPERH || SH_CAYMAN) && !M68K && !BLACKFIN && !S390 && \
> @@ -170,7 +170,7 @@ config SERIO_MACEPS2
> module will be called maceps2.
>
> config SERIO_LIBPS2
> - tristate "PS/2 driver library" if EXPERT
> + tristate "PS/2 driver library"
> depends on SERIO_I8042 || SERIO_I8042=n
> help
> Say Y here if you are using a driver for device connected
> --
> 1.8.4
>
^ permalink raw reply
* [PATCH 2/2] input: allow MOUSEDEV=m even without EXPERT=y
From: Tom Gundersen @ 2013-09-03 13:40 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Tom Gundersen, Dmitry Torokhov
In-Reply-To: <1378215656-11827-1-git-send-email-teg@jklm.no>
Moust (if not all) modern software, including X, uses /dev/eventX rather than
the legacy /dev/mouseX devices. It therefore makes sense for general-purpose
(distro) kernels to use MOUSEDV=m (or even n), so let's drop the EXPERT=y
requirement.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig
index 38b523a..a11ff74 100644
--- a/drivers/input/Kconfig
+++ b/drivers/input/Kconfig
@@ -80,7 +80,7 @@ config INPUT_MATRIXKMAP
comment "Userland interfaces"
config INPUT_MOUSEDEV
- tristate "Mouse interface" if EXPERT
+ tristate "Mouse interface"
default y
help
Say Y here if you want your mouse to be accessible as char devices
--
1.8.4
^ permalink raw reply related
* [PATCH 1/2] input: allow SERIO=m even without EXPERT=y
From: Tom Gundersen @ 2013-09-03 13:40 UTC (permalink / raw)
To: linux-input; +Cc: linux-kernel, Tom Gundersen, Dmitry Torokhov
There is plenty of consumer hardware (e.g., mac books) that does not use
AT keyboards or PS/2 mice. It therefore makes sense for distro kernels
to build the related drivers as modules to avoid loading them on hardware
that does not need them. As such, these options should no longer be protected
by EXPERT.
Moreover, building these drivers as modules gets rid of the following ugly
error during boot:
[ 2.337745] i8042: PNP: No PS/2 controller found. Probing ports directly.
[ 3.439537] i8042: No controller found
Signed-off-by: Tom Gundersen <teg@jklm.no>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/keyboard/Kconfig | 4 ++--
drivers/input/serio/Kconfig | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 269d4c3..2d31cec 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -2,7 +2,7 @@
# Input core configuration
#
menuconfig INPUT_KEYBOARD
- bool "Keyboards" if EXPERT || !X86
+ bool "Keyboards"
default y
help
Say Y here, and a list of supported keyboards will be displayed.
@@ -67,7 +67,7 @@ config KEYBOARD_ATARI
module will be called atakbd.
config KEYBOARD_ATKBD
- tristate "AT keyboard" if EXPERT || !X86
+ tristate "AT keyboard"
default y
select SERIO
select SERIO_LIBPS2
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 1e691a3..39c869d 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -2,7 +2,7 @@
# Input core configuration
#
config SERIO
- tristate "Serial I/O support" if EXPERT || !X86
+ tristate "Serial I/O support"
default y
help
Say Yes here if you have any input device that uses serial I/O to
@@ -19,7 +19,7 @@ config SERIO
if SERIO
config SERIO_I8042
- tristate "i8042 PC Keyboard controller" if EXPERT || !X86
+ tristate "i8042 PC Keyboard controller"
default y
depends on !PARISC && (!ARM || ARCH_SHARK || FOOTBRIDGE_HOST) && \
(!SUPERH || SH_CAYMAN) && !M68K && !BLACKFIN && !S390 && \
@@ -170,7 +170,7 @@ config SERIO_MACEPS2
module will be called maceps2.
config SERIO_LIBPS2
- tristate "PS/2 driver library" if EXPERT
+ tristate "PS/2 driver library"
depends on SERIO_I8042 || SERIO_I8042=n
help
Say Y here if you are using a driver for device connected
--
1.8.4
^ permalink raw reply related
* Re: [PATCH] hid-wiimote: print small buffers via %*ph
From: David Herrmann @ 2013-09-03 13:21 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: David Herrmann, Jiri Kosina, open list:HID CORE LAYER
In-Reply-To: <1378211544-16594-1-git-send-email-andriy.shevchenko@linux.intel.com>
Hi
On Tue, Sep 3, 2013 at 2:32 PM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> Instead of passing each byte through stack let's use %*ph specifier to dump
> buffer as a hex string.
I'd actually prefer %*phC to make grep'ing for these things easier.
Apart from that:
Acked-by: David Herrmann <dh.herrmann@gmail.com>
Thanks
David
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/hid/hid-wiimote-core.c | 17 ++++++-----------
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/hid/hid-wiimote-core.c b/drivers/hid/hid-wiimote-core.c
> index 6602098..ad3ac57 100644
> --- a/drivers/hid/hid-wiimote-core.c
> +++ b/drivers/hid/hid-wiimote-core.c
> @@ -441,8 +441,7 @@ static __u8 wiimote_cmd_read_ext(struct wiimote_data *wdata, __u8 *rmem)
> if (ret != 6)
> return WIIMOTE_EXT_NONE;
>
> - hid_dbg(wdata->hdev, "extension ID: %02x:%02x %02x:%02x %02x:%02x\n",
> - rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
> + hid_dbg(wdata->hdev, "extension ID: %6ph\n", rmem);
>
> if (rmem[0] == 0xff && rmem[1] == 0xff && rmem[2] == 0xff &&
> rmem[3] == 0xff && rmem[4] == 0xff && rmem[5] == 0xff)
> @@ -512,14 +511,12 @@ static bool wiimote_cmd_read_mp(struct wiimote_data *wdata, __u8 *rmem)
> if (ret != 6)
> return false;
>
> - hid_dbg(wdata->hdev, "motion plus ID: %02x:%02x %02x:%02x %02x:%02x\n",
> - rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
> + hid_dbg(wdata->hdev, "motion plus ID: %6ph\n", rmem);
>
> if (rmem[5] == 0x05)
> return true;
>
> - hid_info(wdata->hdev, "unknown motion plus ID: %02x:%02x %02x:%02x %02x:%02x\n",
> - rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
> + hid_info(wdata->hdev, "unknown motion plus ID: %6ph\n", rmem);
>
> return false;
> }
> @@ -535,8 +532,7 @@ static __u8 wiimote_cmd_read_mp_mapped(struct wiimote_data *wdata)
> if (ret != 6)
> return WIIMOTE_MP_NONE;
>
> - hid_dbg(wdata->hdev, "mapped motion plus ID: %02x:%02x %02x:%02x %02x:%02x\n",
> - rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
> + hid_dbg(wdata->hdev, "mapped motion plus ID: %6ph\n", rmem);
>
> if (rmem[0] == 0xff && rmem[1] == 0xff && rmem[2] == 0xff &&
> rmem[3] == 0xff && rmem[4] == 0xff && rmem[5] == 0xff)
> @@ -1128,9 +1124,8 @@ static void wiimote_init_hotplug(struct wiimote_data *wdata)
> wiimote_ext_unload(wdata);
>
> if (exttype == WIIMOTE_EXT_UNKNOWN) {
> - hid_info(wdata->hdev, "cannot detect extension; %02x:%02x %02x:%02x %02x:%02x\n",
> - extdata[0], extdata[1], extdata[2],
> - extdata[3], extdata[4], extdata[5]);
> + hid_info(wdata->hdev, "cannot detect extension; %6ph\n",
> + extdata);
> } else if (exttype == WIIMOTE_EXT_NONE) {
> spin_lock_irq(&wdata->state.lock);
> wdata->state.exttype = WIIMOTE_EXT_NONE;
> --
> 1.8.4.rc3
>
^ permalink raw reply
* [PATCH] hid-wiimote: print small buffers via %*ph
From: Andy Shevchenko @ 2013-09-03 12:32 UTC (permalink / raw)
To: David Herrmann, Jiri Kosina, linux-input; +Cc: Andy Shevchenko
Instead of passing each byte through stack let's use %*ph specifier to dump
buffer as a hex string.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/hid/hid-wiimote-core.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/hid-wiimote-core.c b/drivers/hid/hid-wiimote-core.c
index 6602098..ad3ac57 100644
--- a/drivers/hid/hid-wiimote-core.c
+++ b/drivers/hid/hid-wiimote-core.c
@@ -441,8 +441,7 @@ static __u8 wiimote_cmd_read_ext(struct wiimote_data *wdata, __u8 *rmem)
if (ret != 6)
return WIIMOTE_EXT_NONE;
- hid_dbg(wdata->hdev, "extension ID: %02x:%02x %02x:%02x %02x:%02x\n",
- rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
+ hid_dbg(wdata->hdev, "extension ID: %6ph\n", rmem);
if (rmem[0] == 0xff && rmem[1] == 0xff && rmem[2] == 0xff &&
rmem[3] == 0xff && rmem[4] == 0xff && rmem[5] == 0xff)
@@ -512,14 +511,12 @@ static bool wiimote_cmd_read_mp(struct wiimote_data *wdata, __u8 *rmem)
if (ret != 6)
return false;
- hid_dbg(wdata->hdev, "motion plus ID: %02x:%02x %02x:%02x %02x:%02x\n",
- rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
+ hid_dbg(wdata->hdev, "motion plus ID: %6ph\n", rmem);
if (rmem[5] == 0x05)
return true;
- hid_info(wdata->hdev, "unknown motion plus ID: %02x:%02x %02x:%02x %02x:%02x\n",
- rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
+ hid_info(wdata->hdev, "unknown motion plus ID: %6ph\n", rmem);
return false;
}
@@ -535,8 +532,7 @@ static __u8 wiimote_cmd_read_mp_mapped(struct wiimote_data *wdata)
if (ret != 6)
return WIIMOTE_MP_NONE;
- hid_dbg(wdata->hdev, "mapped motion plus ID: %02x:%02x %02x:%02x %02x:%02x\n",
- rmem[0], rmem[1], rmem[2], rmem[3], rmem[4], rmem[5]);
+ hid_dbg(wdata->hdev, "mapped motion plus ID: %6ph\n", rmem);
if (rmem[0] == 0xff && rmem[1] == 0xff && rmem[2] == 0xff &&
rmem[3] == 0xff && rmem[4] == 0xff && rmem[5] == 0xff)
@@ -1128,9 +1124,8 @@ static void wiimote_init_hotplug(struct wiimote_data *wdata)
wiimote_ext_unload(wdata);
if (exttype == WIIMOTE_EXT_UNKNOWN) {
- hid_info(wdata->hdev, "cannot detect extension; %02x:%02x %02x:%02x %02x:%02x\n",
- extdata[0], extdata[1], extdata[2],
- extdata[3], extdata[4], extdata[5]);
+ hid_info(wdata->hdev, "cannot detect extension; %6ph\n",
+ extdata);
} else if (exttype == WIIMOTE_EXT_NONE) {
spin_lock_irq(&wdata->state.lock);
wdata->state.exttype = WIIMOTE_EXT_NONE;
--
1.8.4.rc3
^ permalink raw reply related
* Re: Behaviour of input-polldev?
From: David Herrmann @ 2013-09-03 11:54 UTC (permalink / raw)
To: Florian Echtler; +Cc: linux-input, Dmitry Torokhov
In-Reply-To: <5225CA65.7030104@butterbrot.org>
Hi Florian
On Tue, Sep 3, 2013 at 1:39 PM, Florian Echtler <floe@butterbrot.org> wrote:
> Hello everyone,
>
> I'm in the process of writing an input driver for the Microsoft
> Pixelsense (formerly Surface 2.0). The device only has bulk endpoints
> and consequently needs to be polled regularly. My beta driver uses
> input-polldev for this, and it appears to work nicely, however, I
> couldn't find out how input-polldev behaves if one polling cycle takes
> longer than expected and a new poll would already be triggered while the
> first one is still running?
(CC'ing polldev author Dmitry in case I'm missing something)
input-polldev uses the system-freezable-wq. The related code is
./drivers/input/input-polldev.c:33:
queue_delayed_work(system_freezable_wq, &dev->work, delay);
Since the wq-rewrite all default workqueues are non-reentrant. That
is, the new work is still scheduled but only executed after the
previous worker returned (in this case, once your ->poll() callback
returns).
Regards
David
^ permalink raw reply
* Behaviour of input-polldev?
From: Florian Echtler @ 2013-09-03 11:39 UTC (permalink / raw)
To: linux-input
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
Hello everyone,
I'm in the process of writing an input driver for the Microsoft
Pixelsense (formerly Surface 2.0). The device only has bulk endpoints
and consequently needs to be polled regularly. My beta driver uses
input-polldev for this, and it appears to work nicely, however, I
couldn't find out how input-polldev behaves if one polling cycle takes
longer than expected and a new poll would already be triggered while the
first one is still running?
Thanks & BR, Florian
--
SENT FROM MY DEC VT50 TERMINAL
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ 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