* Re: Problems with Wacom Intuos PT M (CTH680) on FreeBSD
From: Dmitry Torokhov @ 2014-11-04 8:08 UTC (permalink / raw)
To: Hans Petter Selasky
Cc: Ping Cheng, Denis Akiyakov, linux-input,
nox@jelal.kn-bremen.de >> Juergen Lock
In-Reply-To: <54548E63.6060306@selasky.org>
On Sat, Nov 01, 2014 at 08:40:19AM +0100, Hans Petter Selasky wrote:
> On 11/01/14 00:27, Ping Cheng wrote:
> >If touch_input is NULL on FreeBSD, you need to figure out the root
> >cause. Checking on touch_input itself would not fix the root cause...
>
> Right.
>
> The root cause is that FreeBSD launches two instances of the driver,
> running in two different userland processes, for the two different
> Wacom interfaces on a common USB device. In Linux the wacom
> interface drivers are running from the same kernel, and can share
> the data in question, but in FreeBSD's webcamd emulation, this
> doesn't work. Then the first wacom probe call would have to grab the
> second interface.
>
> Technically speaking this is a FreeBSD only problem and I plan to
> deliver a patch with the webcamd software to fix this, like already
> suggested to you guys. This situation can also happen on Linux in
> case of a "BadUSB" device. That's why I think that the NULL check
> should be upstreamed.
Hmm, looking at this again it seems that we just cross our fingers and
hope that both interfaces are enumerated by the time we get event data
from the device. I do not think this is quite safe. We probably should
be checking the overall state of probing (i.e. whether we are done
probing both interfaces) before processing data for the device.
Or maybe we should just forcibly try claiming secondary interface
while probing primary instead of messing with shared data item.
That won't help Hans though: the devices do use 2 interfaces in tandem,
treating them separately will result in incorrect behavior.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [RFC 1/1] Input: gpio_keys - add device tree support for interrupt only keys
From: Dmitry Torokhov @ 2014-11-04 7:50 UTC (permalink / raw)
To: Alexander Stein; +Cc: linux-input
In-Reply-To: <3831095.dNKMkPVWlN@ws-stein>
Hi ALexander,
On Tue, Oct 14, 2014 at 08:30:43AM +0200, Alexander Stein wrote:
> Ping?
>
> On Tuesday 30 September 2014 17:40:47, Alexander Stein wrote:
> > This features already exists for board config setups. Add support for
> > device tree based systems.
> >
> > Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> > ---
> > I'm aware thatthe device tree binding description is missing yet. But for now
> > I just want some feedback about that approach.
> >
> > drivers/input/keyboard/gpio_keys.c | 31 ++++++++++++++++++-------------
> > 1 file changed, 18 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
> > index 8c98e97..7b90e1b 100644
> > --- a/drivers/input/keyboard/gpio_keys.c
> > +++ b/drivers/input/keyboard/gpio_keys.c
> > @@ -29,6 +29,7 @@
> > #include <linux/of.h>
> > #include <linux/of_platform.h>
> > #include <linux/of_gpio.h>
> > +#include <linux/of_irq.h>
> > #include <linux/spinlock.h>
> >
> > struct gpio_button_data {
> > @@ -617,28 +618,32 @@ gpio_keys_get_devtree_pdata(struct device *dev)
> >
> > i = 0;
> > for_each_child_of_node(node, pp) {
> > - int gpio;
> > + int gpio = -1;
> > + int irq;
> > enum of_gpio_flags flags;
> >
> > - if (!of_find_property(pp, "gpios", NULL)) {
> > + irq = irq_of_parse_and_map(pp, 0);
> > +
Hmm, the current button setup code will ignore the irq if button's gpio
is valid. We shoudl either not try to parse/map irq or make that code
properly handle cases where both gpio and interrupt are specified (and
they might be different).
Also, board code supports having a single interrupt shared between all
buttons, it woudl be nice if OF supported the same.
And lastly, we need the device tree binding updated (please CC device
tree folks/list).
Thanks!
> > + if (of_find_property(pp, "gpios", NULL)) {
> > + gpio = of_get_gpio_flags(pp, 0, &flags);
> > + if (gpio < 0) {
> > + error = gpio;
> > + if (error != -EPROBE_DEFER)
> > + dev_err(dev,
> > + "Failed to get gpio flags, error: %d\n",
> > + error);
> > + return ERR_PTR(error);
> > + }
> > + } else if (irq == 0) {
> > pdata->nbuttons--;
> > - dev_warn(dev, "Found button without gpios\n");
> > + dev_warn(dev, "Found button without gpios or irqs\n");
> > continue;
> > }
> >
> > - gpio = of_get_gpio_flags(pp, 0, &flags);
> > - if (gpio < 0) {
> > - error = gpio;
> > - if (error != -EPROBE_DEFER)
> > - dev_err(dev,
> > - "Failed to get gpio flags, error: %d\n",
> > - error);
> > - return ERR_PTR(error);
> > - }
> > -
> > button = &pdata->buttons[i++];
> >
> > button->gpio = gpio;
> > + button->irq = irq;
> > button->active_low = flags & OF_GPIO_ACTIVE_LOW;
> >
> > if (of_property_read_u32(pp, "linux,code", &button->code)) {
> >
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/2] HID: logitech-hidpp: fix negated returns
From: Dan Carpenter @ 2014-11-04 7:30 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Nestor Lopez Casado, linux-input, linux-kernel
In-Reply-To: <1415048999-4490-1-git-send-email-benjamin.tissoires@redhat.com>
Looks good. Thanks!
regards,
dan carpenter
^ permalink raw reply
* Re: Microsoft Surface Pro 3 Type Cover keyboard
From: Alan Wu @ 2014-11-04 2:32 UTC (permalink / raw)
To: Jarrad Whitaker
Cc: Benjamin Tissoires, Andrew Duggan, Jiri Kosina, linux-input,
Andrew Duggan
In-Reply-To: <CABkLPOK2YQDddLpF2VvoAKxNVYsCOg0-W41SBiSZkDi7df9Opw@mail.gmail.com>
Hi all,
I submitted the new patch. Please review and comment.
Thanks,
Alan
On Mon, Nov 3, 2014 at 5:49 PM, Alan Wu <alan.c.wu@gmail.com> wrote:
> Hi all,
> So after using the patch with Jarrad's changes added in, I was able to
> revert the evdev config to its original and have no problems. I have
> attached the evdev.conf as follows. However, multitouch does not seem to
> work since ABS_MT_SLOT is defined, but not used. I have attached some
> sample tests with multiple fingers. I'm not sure what changed between the
> tests, however, one showed EV_ABS and the other used EV_REL.
>
> I did not realize the dim/brightness was for the type cover hardware
> backlight, and what Jarrad said makes sense that it probably does not send a
> signal.
>
> Please give me some suggestions on what I can do to investigate the
> ABS_MT_SLOT issue now, as this is my first time working with the kernel.
> However, I would second Jarrad's suggestion that we patch this for now and
> get multitouch working later, so at least I can keep ubuntu updated without
> messing with the kernel myself every time.
>
> I will submit the patch soon to the mailing list.
>
> Thanks,
> Alan
>
>
>
> On Mon, Nov 3, 2014 at 5:08 PM, Jarrad Whitaker <jarrad.whitaker@gmail.com>
> wrote:
>>
>> Wow, what a flurry of activity! I don't have much to add beyond Alan's
>> patch on its own did not work for me, I am assuming this is due to
>> manually needing to assign it to evdev which I did not do.
>> Also, on the dim/brightness keys, these control the backlight of the
>> keyboard itself and as far as I can tell do not even pass any signal
>> to the device's native Windows 8.
>> Can probably test a little more tonight or tomorrow, but I am in the
>> middle of exams I'm afraid and this could be a dangerously effective
>> form of procrastination, so I won't be able to so much for a couple of
>> weeks yet.
>>
>> Given the tiny scope of the current patch, is there a chance it could
>> get into 3.18 as is so people at least have a working keyboard, then
>> we continue to work on a proper solution for later?
>>
>> Jarrad
>>
>> P.S. sorry, my win8 mail app lies about sending in plaintext mode.
>>
>> On 4 November 2014 08:27, Benjamin Tissoires
>> <benjamin.tissoires@gmail.com> wrote:
>> > On Mon, Nov 3, 2014 at 4:15 PM, Alan Wu <alan.c.wu@gmail.com> wrote:
>> >> My initial checks after sudo cat /dev/hidraw0 shows that moving
>> >> multiple
>> >> fingers does work with my patch as earlier using hid-microsoft.
>> >> However,
>> >> the dim and brightness keys (Fn+F1, Fn+F2) does not work.
>> >>
>> >> My tests with multiple fingers include:
>> >> moving one finger,
>> >> adding and moving second finger with first finger held,
>> >> moving first finger with second finger stationary,
>> >> adding and moving third finger with first and second finger held,
>> >> moving first or second finger with third finger held.
>> >> repeating with up to eight fingers.
>> >>
>> >> It is hard to check moving two fingers at the same time with another
>> >> one (or
>> >> more) fingers held stationary because the way the output works. It
>> >> comes
>> >> out something like this, so I can't tell if they are doing what they
>> >> are
>> >> supposed to.
>> >> ^@^@^C\377^@^@
>> >>
>> >> Please let me know how to continue testing.
>> >
>> > You can check the various event node outputs by using evemu.
>> > If the touchpad presents ABS_MT_SLOT and makes use of it, you are
>> > using the raw reporting mode.
>> >
>> > You can also assess it with programs like mtview[1] of mtdiag-qt[2]
>> > (both need to be run as root to get access to the event nodes).
>> >
>> >> I'm currently adding the hid_have_special_driver
>> >> and a couple other lines from Jarrad's website to the patch and will
>> >> test it
>> >> soon before submitting.
>> >>
>> >> Also, how can I continue this thread to linux-input mailing list from
>> >> gmail?
>> >> It keeps rejecting my mail.
>> >
>> > You need to use the "Plain Text Mode" mode. There is a small arrow on
>> > the bottom right of the compose window (next to the trash) and
>> > above "Print", you have the previously mentioned mode.
>> >
>> > Cheers,
>> > Benjamin
>> >
>> > [1] https://github.com/whot/mtview (or maybe
>> > http://bitmath.org/code/mtview/, I can not remember if the bitmath one
>> > is still actively supported)
>> > [2] https://github.com/bentiss/mtdiag-qt
>> >
>> >
>> >>
>> >> On Mon, Nov 3, 2014 at 12:39 PM, Benjamin Tissoires
>> >> <benjamin.tissoires@gmail.com> wrote:
>> >>>
>> >>> On Mon, Nov 3, 2014 at 3:33 PM, Andrew Duggan
>> >>> <andrew.duggan@gmail.com>
>> >>> wrote:
>> >>> >
>> >>> >
>> >>> > On Mon, Nov 3, 2014 at 7:28 AM, Benjamin Tissoires
>> >>> > <benjamin.tissoires@gmail.com> wrote:
>> >>> >>
>> >>> >> On Mon, Nov 3, 2014 at 8:33 AM, Jiri Kosina <jkosina@suse.cz>
>> >>> >> wrote:
>> >>> >> > On Fri, 24 Oct 2014, Jarrad Whitaker wrote:
>> >>> >> >
>> >>> >> >> The keyboard on the Surface Pro 3 type cover does not function
>> >>> >> >> without
>> >>> >> >> some patching, similar to what was apparently required for the
>> >>> >> >> SP2
>> >>> >> >> type/touch covers.
>> >>> >> >>
>> >>> >> >> A working patch against 3.16 attached, it's an amalgamation of
>> >>> >> >> "some
>> >>> >> >> dude posted this on the ubuntu/arch forums and it seems to work"
>> >>> >> >> so
>> >>> >> >> I'm making no claims that it's kernel-quality! Just trying to
>> >>> >> >> give a
>> >>> >> >> better indication of what needs to be added. My C is rudimentary
>> >>> >> >> and
>> >>> >> >> my knowledge of the kernel limited to 'fakeroot debian/rules
>> >>> >> >> updateconfigs', sorry. :)
>> >>> >> >> Happy to test any improved version, but note I only have a type,
>> >>> >> >> not
>> >>> >> >> a
>> >>> >> >> touch cover.
>> >>> >> >>
>> >>> >> >> Patch source is
>> >>> >> >> http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/,
>> >>> >> >> which
>> >>> >> >> in turn sources a Russian site.
>> >>> >> >
>> >>> >> > Hi,
>> >>> >> >
>> >>> >> > thanks. Adding Alan Wu to CC, who sent me a slightly different
>> >>> >> > patch
>> >>> >> > for
>> >>> >> > this issue -- see the archives of linux-input list from a few
>> >>> >> > days
>> >>> >> > back.
>> >>> >> >
>> >>> >> > Your patch is missing at least Signed-off-by: line, and also
>> >>> >> > seems to
>> >>> >> > lack
>> >>> >> > the update to hid_have_special_driver[].
>> >>> >>
>> >>> >> Jiri, actually, the hid_have_special_driver entry is not 100%
>> >>> >> required
>> >>> >> to make it work (though it would be cleaner, I agree).
>> >>> >> Actually, the TypeCover presents a Precision TouchPad, so hid-core
>> >>> >> considers it should have the hid-multitouch driver driving it (see
>> >>> >> https://bugzilla.redhat.com/show_bug.cgi?id=1135338 )
>> >>> >>
>> >>> >> I am not sure we should use hid-multitouch or hid-microsoft. My
>> >>> >> guess
>> >>> >> is that both will work, but hid-multitouch might provide true raw
>> >>> >> reporting for the touchpad. On the other hand, maybe hid-microsoft
>> >>> >> will bind special keys that hid-multitouch will not...
>> >>> >>
>> >>> > I would think that being able to do multifinger gestures would make
>> >>> > using
>> >>> > hid-multitouch preferable. Using hid-microsoft will keep the
>> >>> > touchpad in
>> >>> > mouse mode since the host needs to send the feature report to switch
>> >>> > the
>> >>> > touchpad into PTP mode. In PTP mode, this touchpad will report
>> >>> > absolute
>> >>> > data
>> >>> > for three fingers.
>> >>> >
>> >>> > I think the main issue is how do you get the keyboard working when
>> >>> > the
>> >>> > device is using the hid-multitouch driver. After looking at the bug
>> >>> > above
>> >>> > and Benjamin's changes on Github it looks like adding an entry in
>> >>> > mt_devices
>> >>> > and setting MT_CLS_EXPORT_ALL_INPUTS would also export the keyboard.
>> >>> > Is
>> >>> > that
>> >>> > correct? I haven't been able to try it out.
>> >>>
>> >>> Correct. See
>> >>>
>> >>> https://github.com/bentiss/hid-multitouch/commit/999eb73d37bab0b72f775f2150b1c27488610414
>> >>> The reporter seems to claim that it works for him, but I need to check
>> >>> if the touchpad is correctly presented (properties, etc), if the
>> >>> touchpad data come from the raw node, and not the mouse node, and if
>> >>> there is no problems with respect to the keyboard. I'd prefer the
>> >>> owners of the device to double check all of this.
>> >>>
>> >>> >
>> >>> > If hid-microsoft has functionality which hid-multitouch doesn't
>> >>> > provide
>> >>> > is
>> >>> > there a way to combine the two without reimplementing the
>> >>> > functionality
>> >>> > of
>> >>> > one driver into the other?
>> >>>
>> >>> The problem with this device is that the keyboard and touchpad are on
>> >>> the same hid device, on different collections. So if hid-microsoft
>> >>> does fancy stuff on the keyboard level, the only option will be to
>> >>> merge hid-multitouch in hid-input (this might be needed at some
>> >>> point).
>> >>>
>> >>> Cheers,
>> >>> Benjamin
>> >>>
>> >>> >
>> >>> >>
>> >>> >> If the path is to go through hid-microsoft, then Jarrad, Alan, yes,
>> >>> >> please, add your device to hid_have_special_driver.
>> >>> >>
>> >>> >> Cheers,
>> >>> >> Benjamin
>> >>> >>
>> >>> >> >
>> >>> >> > Could you two guys please cooperate and send me a patch that
>> >>> >> > should
>> >>> >> > be
>> >>> >> > applied? I don't have the device so can't really test properly
>> >>> >> > myself.
>> >>> >> >
>> >>> >> > Thanks,
>> >>> >> >
>> >>> >> > --
>> >>> >> > Jiri Kosina
>> >>> >> > SUSE Labs
>> >>> >> > --
>> >>> >> > To unsubscribe from this list: send the line "unsubscribe
>> >>> >> > linux-input"
>> >>> >> > in
>> >>> >> > the body of a message to majordomo@vger.kernel.org
>> >>> >> > More majordomo info at
>> >>> >> > http://vger.kernel.org/majordomo-info.html
>> >>> >> --
>> >>> >> To unsubscribe from this list: send the line "unsubscribe
>> >>> >> linux-input"
>> >>> >> in
>> >>> >> the body of a message to majordomo@vger.kernel.org
>> >>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >>> >
>> >>> >
>> >>
>> >>
>
>
^ permalink raw reply
* [PATCH 1/1] x86: Surface Pro 3 Type Cover 3
From: Alan Wu @ 2014-11-04 2:26 UTC (permalink / raw)
To: alanwu, Jiri Kosina; +Cc: linux-input, linux-kernel, linux-usb
Surface Pro 3 Type Cover that works with Ubuntu (and possibly Arch) from this thread. Both trackpad and keyboard work after compiling my own kernel.
http://ubuntuforums.org/showthread.php?t=2231207&page=2&s=44910e0c56047e4f93dfd9fea58121ef
Also includes Jarrad Whitaker's message which sources
http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/
which he says is sourced from a Russian site
Signed-off-by: Alan Wu <alan.c.wu@gmail.com>
---
drivers/hid/hid-core.c | 6 ++++++
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-microsoft.c | 2 ++
drivers/hid/usbhid/hid-quirks.c | 1 +
4 files changed, 10 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 73bd9e2..e94afcc 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -702,6 +702,11 @@ static void hid_scan_collection(struct hid_parser *parser, unsigned type)
if (((parser->global.usage_page << 16) == HID_UP_SENSOR) &&
type == HID_COLLECTION_PHYSICAL)
hid->group = HID_GROUP_SENSOR_HUB;
+
+ if (hid->vendor == USB_VENDOR_ID_MICROSOFT &&
+ hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3 &&
+ hid->group == HID_GROUP_MULTITOUCH)
+ hid->group = HID_GROUP_GENERIC;
}
static int hid_scan_main(struct hid_parser *parser, struct hid_item *item)
@@ -1861,6 +1866,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index e23ab8b..15f32c2 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -648,6 +648,7 @@
#define USB_DEVICE_ID_MS_SURFACE_PRO_2 0x0799
#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
#define USB_DEVICE_ID_MS_TYPE_COVER_2 0x07a9
+#define USB_DEVICE_ID_MS_TYPE_COVER_3 0x07dc
#define USB_VENDOR_ID_MOJO 0x8282
#define USB_DEVICE_ID_RETRO_ADAPTER 0x3201
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index 8ba17a9..cacda43 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -274,6 +274,8 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_COMFORT_MOUSE_4500),
.driver_data = MS_DUPLICATE_USAGES },
+ { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3),
+ .driver_data = MS_HIDINPUT },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_PRESENTER_8K_BT),
.driver_data = MS_PRESENTER },
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 5014bb5..cebfaf2 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -77,6 +77,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER, HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3, HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL, HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750, HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE, HID_QUIRK_NO_INIT_REPORTS },
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 3/3] input: stmpe: bias keypad columns properly
From: Dmitry Torokhov @ 2014-11-04 1:57 UTC (permalink / raw)
To: Linus Walleij; +Cc: Samuel Ortiz, Lee Jones, linux-kernel, linux-input
In-Reply-To: <1413636999-3326-1-git-send-email-linus.walleij@linaro.org>
Hi Linus,
On Sat, Oct 18, 2014 at 02:56:39PM +0200, Linus Walleij wrote:
> + if (variant->set_pullup) {
> + u8 val;
> +
> + ret = stmpe_reg_read(stmpe, pureg);
> + if (ret)
> + return ret;
> +
> + /* Do not touch unused pins, may be used for GPIO */
> + val = ret & ~pu_pins;
> + val |= pu_pins;
> +
> + ret = stmpe_reg_write(stmpe, pureg, val);
Don't we need
if (ret) {
dev_err(...);
return ret;
}
here?
--
Dmitry
^ permalink raw reply
* Re: PATCH: Quirk (hid-saitek.c) for Saitek R.A.T.7 works with R.A.T.9 too
From: Harald Brinkmann @ 2014-11-04 1:01 UTC (permalink / raw)
To: Ville Aakko, jkosina; +Cc: linux-input, trivial
In-Reply-To: <CAEP-KKshiXPfDhHPE7uatU70wfiOM-xMbFS2+6VxBbFM-LMfjw@mail.gmail.com>
On 11/02/2014 03:37 PM, Ville Aakko wrote:
> p.s. I have never submitted patches, I apologize if I have done something in a
> wrong way! Should I have added / updated the description in the comments?
I think you should update linux/drivers/hid/Kconfig and add the R.A.T.9
to the list of supported devices in the HID_SAITEK section.
--
Cheers,
Harald
^ permalink raw reply
* Re: Microsoft Surface Pro 3 Type Cover keyboard
From: Jarrad Whitaker @ 2014-11-04 1:08 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Alan Wu, Andrew Duggan, Jiri Kosina, linux-input, Andrew Duggan
In-Reply-To: <CAN+gG=FnOm_vRAZ87qWKYVP9BSs=quyR2vdaAUjeWOPb2HFeVw@mail.gmail.com>
Wow, what a flurry of activity! I don't have much to add beyond Alan's
patch on its own did not work for me, I am assuming this is due to
manually needing to assign it to evdev which I did not do.
Also, on the dim/brightness keys, these control the backlight of the
keyboard itself and as far as I can tell do not even pass any signal
to the device's native Windows 8.
Can probably test a little more tonight or tomorrow, but I am in the
middle of exams I'm afraid and this could be a dangerously effective
form of procrastination, so I won't be able to so much for a couple of
weeks yet.
Given the tiny scope of the current patch, is there a chance it could
get into 3.18 as is so people at least have a working keyboard, then
we continue to work on a proper solution for later?
Jarrad
P.S. sorry, my win8 mail app lies about sending in plaintext mode.
On 4 November 2014 08:27, Benjamin Tissoires
<benjamin.tissoires@gmail.com> wrote:
> On Mon, Nov 3, 2014 at 4:15 PM, Alan Wu <alan.c.wu@gmail.com> wrote:
>> My initial checks after sudo cat /dev/hidraw0 shows that moving multiple
>> fingers does work with my patch as earlier using hid-microsoft. However,
>> the dim and brightness keys (Fn+F1, Fn+F2) does not work.
>>
>> My tests with multiple fingers include:
>> moving one finger,
>> adding and moving second finger with first finger held,
>> moving first finger with second finger stationary,
>> adding and moving third finger with first and second finger held,
>> moving first or second finger with third finger held.
>> repeating with up to eight fingers.
>>
>> It is hard to check moving two fingers at the same time with another one (or
>> more) fingers held stationary because the way the output works. It comes
>> out something like this, so I can't tell if they are doing what they are
>> supposed to.
>> ^@^@^C\377^@^@
>>
>> Please let me know how to continue testing.
>
> You can check the various event node outputs by using evemu.
> If the touchpad presents ABS_MT_SLOT and makes use of it, you are
> using the raw reporting mode.
>
> You can also assess it with programs like mtview[1] of mtdiag-qt[2]
> (both need to be run as root to get access to the event nodes).
>
>> I'm currently adding the hid_have_special_driver
>> and a couple other lines from Jarrad's website to the patch and will test it
>> soon before submitting.
>>
>> Also, how can I continue this thread to linux-input mailing list from gmail?
>> It keeps rejecting my mail.
>
> You need to use the "Plain Text Mode" mode. There is a small arrow on
> the bottom right of the compose window (next to the trash) and
> above "Print", you have the previously mentioned mode.
>
> Cheers,
> Benjamin
>
> [1] https://github.com/whot/mtview (or maybe
> http://bitmath.org/code/mtview/, I can not remember if the bitmath one
> is still actively supported)
> [2] https://github.com/bentiss/mtdiag-qt
>
>
>>
>> On Mon, Nov 3, 2014 at 12:39 PM, Benjamin Tissoires
>> <benjamin.tissoires@gmail.com> wrote:
>>>
>>> On Mon, Nov 3, 2014 at 3:33 PM, Andrew Duggan <andrew.duggan@gmail.com>
>>> wrote:
>>> >
>>> >
>>> > On Mon, Nov 3, 2014 at 7:28 AM, Benjamin Tissoires
>>> > <benjamin.tissoires@gmail.com> wrote:
>>> >>
>>> >> On Mon, Nov 3, 2014 at 8:33 AM, Jiri Kosina <jkosina@suse.cz> wrote:
>>> >> > On Fri, 24 Oct 2014, Jarrad Whitaker wrote:
>>> >> >
>>> >> >> The keyboard on the Surface Pro 3 type cover does not function
>>> >> >> without
>>> >> >> some patching, similar to what was apparently required for the SP2
>>> >> >> type/touch covers.
>>> >> >>
>>> >> >> A working patch against 3.16 attached, it's an amalgamation of "some
>>> >> >> dude posted this on the ubuntu/arch forums and it seems to work" so
>>> >> >> I'm making no claims that it's kernel-quality! Just trying to give a
>>> >> >> better indication of what needs to be added. My C is rudimentary and
>>> >> >> my knowledge of the kernel limited to 'fakeroot debian/rules
>>> >> >> updateconfigs', sorry. :)
>>> >> >> Happy to test any improved version, but note I only have a type, not
>>> >> >> a
>>> >> >> touch cover.
>>> >> >>
>>> >> >> Patch source is
>>> >> >> http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/,
>>> >> >> which
>>> >> >> in turn sources a Russian site.
>>> >> >
>>> >> > Hi,
>>> >> >
>>> >> > thanks. Adding Alan Wu to CC, who sent me a slightly different patch
>>> >> > for
>>> >> > this issue -- see the archives of linux-input list from a few days
>>> >> > back.
>>> >> >
>>> >> > Your patch is missing at least Signed-off-by: line, and also seems to
>>> >> > lack
>>> >> > the update to hid_have_special_driver[].
>>> >>
>>> >> Jiri, actually, the hid_have_special_driver entry is not 100% required
>>> >> to make it work (though it would be cleaner, I agree).
>>> >> Actually, the TypeCover presents a Precision TouchPad, so hid-core
>>> >> considers it should have the hid-multitouch driver driving it (see
>>> >> https://bugzilla.redhat.com/show_bug.cgi?id=1135338 )
>>> >>
>>> >> I am not sure we should use hid-multitouch or hid-microsoft. My guess
>>> >> is that both will work, but hid-multitouch might provide true raw
>>> >> reporting for the touchpad. On the other hand, maybe hid-microsoft
>>> >> will bind special keys that hid-multitouch will not...
>>> >>
>>> > I would think that being able to do multifinger gestures would make
>>> > using
>>> > hid-multitouch preferable. Using hid-microsoft will keep the touchpad in
>>> > mouse mode since the host needs to send the feature report to switch the
>>> > touchpad into PTP mode. In PTP mode, this touchpad will report absolute
>>> > data
>>> > for three fingers.
>>> >
>>> > I think the main issue is how do you get the keyboard working when the
>>> > device is using the hid-multitouch driver. After looking at the bug
>>> > above
>>> > and Benjamin's changes on Github it looks like adding an entry in
>>> > mt_devices
>>> > and setting MT_CLS_EXPORT_ALL_INPUTS would also export the keyboard. Is
>>> > that
>>> > correct? I haven't been able to try it out.
>>>
>>> Correct. See
>>> https://github.com/bentiss/hid-multitouch/commit/999eb73d37bab0b72f775f2150b1c27488610414
>>> The reporter seems to claim that it works for him, but I need to check
>>> if the touchpad is correctly presented (properties, etc), if the
>>> touchpad data come from the raw node, and not the mouse node, and if
>>> there is no problems with respect to the keyboard. I'd prefer the
>>> owners of the device to double check all of this.
>>>
>>> >
>>> > If hid-microsoft has functionality which hid-multitouch doesn't provide
>>> > is
>>> > there a way to combine the two without reimplementing the functionality
>>> > of
>>> > one driver into the other?
>>>
>>> The problem with this device is that the keyboard and touchpad are on
>>> the same hid device, on different collections. So if hid-microsoft
>>> does fancy stuff on the keyboard level, the only option will be to
>>> merge hid-multitouch in hid-input (this might be needed at some
>>> point).
>>>
>>> Cheers,
>>> Benjamin
>>>
>>> >
>>> >>
>>> >> If the path is to go through hid-microsoft, then Jarrad, Alan, yes,
>>> >> please, add your device to hid_have_special_driver.
>>> >>
>>> >> Cheers,
>>> >> Benjamin
>>> >>
>>> >> >
>>> >> > Could you two guys please cooperate and send me a patch that should
>>> >> > be
>>> >> > applied? I don't have the device so can't really test properly
>>> >> > myself.
>>> >> >
>>> >> > Thanks,
>>> >> >
>>> >> > --
>>> >> > Jiri Kosina
>>> >> > SUSE Labs
>>> >> > --
>>> >> > To unsubscribe from this list: send the line "unsubscribe
>>> >> > linux-input"
>>> >> > in
>>> >> > the body of a message to majordomo@vger.kernel.org
>>> >> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> >> --
>>> >> To unsubscribe from this list: send the line "unsubscribe linux-input"
>>> >> in
>>> >> the body of a message to majordomo@vger.kernel.org
>>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> >
>>> >
>>
>>
^ permalink raw reply
* Re: [PATCH] HID: core: cleanup .claimed field on disconnect
From: Jiri Kosina @ 2014-11-03 22:45 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Nestor Lopez Casado, Andrew de los Reyes, linux-input,
linux-kernel
In-Reply-To: <1415046812-3263-1-git-send-email-benjamin.tissoires@redhat.com>
On Mon, 3 Nov 2014, Benjamin Tissoires wrote:
> When a subdriver is rmmod-ed then re-insmod-ed, the hid device is not
> destroyed as it is owned by the transport layer.
> So when we re-probed the device, the hid device is assumed to be already
> claimed, and can lead to page faults if hid-core tries to forward the
> emitted data to the to-be-created claimed node.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
>
> Hi Jiri,
>
> [keeping the people involved in the logitech-hidpp driver in CC]
>
> this one was particularly nasty. I had several page faults when just
> rmmod && insmod the hid-logitech-hidpp driver. The page fault was occuring
> in hidraw :/
> I was not able to get a stacktrace which I could include here. The laptop was
> completely unresponsive and I could take only a picture to debug it.
Thanks a lot for tracking it down, Benjamin, tricky one indeed. Queuing
for 3.18 still.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: Microsoft Surface Pro 3 Type Cover keyboard
From: Benjamin Tissoires @ 2014-11-03 21:27 UTC (permalink / raw)
To: Alan Wu
Cc: Andrew Duggan, Jiri Kosina, Jarrad Whitaker, linux-input,
Andrew Duggan
In-Reply-To: <CABkLPOLiiyHSQs=nu0js_NDL61JxoQXGYo9ZwkJ_oT0samftYA@mail.gmail.com>
On Mon, Nov 3, 2014 at 4:15 PM, Alan Wu <alan.c.wu@gmail.com> wrote:
> My initial checks after sudo cat /dev/hidraw0 shows that moving multiple
> fingers does work with my patch as earlier using hid-microsoft. However,
> the dim and brightness keys (Fn+F1, Fn+F2) does not work.
>
> My tests with multiple fingers include:
> moving one finger,
> adding and moving second finger with first finger held,
> moving first finger with second finger stationary,
> adding and moving third finger with first and second finger held,
> moving first or second finger with third finger held.
> repeating with up to eight fingers.
>
> It is hard to check moving two fingers at the same time with another one (or
> more) fingers held stationary because the way the output works. It comes
> out something like this, so I can't tell if they are doing what they are
> supposed to.
> ^@^@^C\377^@^@
>
> Please let me know how to continue testing.
You can check the various event node outputs by using evemu.
If the touchpad presents ABS_MT_SLOT and makes use of it, you are
using the raw reporting mode.
You can also assess it with programs like mtview[1] of mtdiag-qt[2]
(both need to be run as root to get access to the event nodes).
> I'm currently adding the hid_have_special_driver
> and a couple other lines from Jarrad's website to the patch and will test it
> soon before submitting.
>
> Also, how can I continue this thread to linux-input mailing list from gmail?
> It keeps rejecting my mail.
You need to use the "Plain Text Mode" mode. There is a small arrow on
the bottom right of the compose window (next to the trash) and
above "Print", you have the previously mentioned mode.
Cheers,
Benjamin
[1] https://github.com/whot/mtview (or maybe
http://bitmath.org/code/mtview/, I can not remember if the bitmath one
is still actively supported)
[2] https://github.com/bentiss/mtdiag-qt
>
> On Mon, Nov 3, 2014 at 12:39 PM, Benjamin Tissoires
> <benjamin.tissoires@gmail.com> wrote:
>>
>> On Mon, Nov 3, 2014 at 3:33 PM, Andrew Duggan <andrew.duggan@gmail.com>
>> wrote:
>> >
>> >
>> > On Mon, Nov 3, 2014 at 7:28 AM, Benjamin Tissoires
>> > <benjamin.tissoires@gmail.com> wrote:
>> >>
>> >> On Mon, Nov 3, 2014 at 8:33 AM, Jiri Kosina <jkosina@suse.cz> wrote:
>> >> > On Fri, 24 Oct 2014, Jarrad Whitaker wrote:
>> >> >
>> >> >> The keyboard on the Surface Pro 3 type cover does not function
>> >> >> without
>> >> >> some patching, similar to what was apparently required for the SP2
>> >> >> type/touch covers.
>> >> >>
>> >> >> A working patch against 3.16 attached, it's an amalgamation of "some
>> >> >> dude posted this on the ubuntu/arch forums and it seems to work" so
>> >> >> I'm making no claims that it's kernel-quality! Just trying to give a
>> >> >> better indication of what needs to be added. My C is rudimentary and
>> >> >> my knowledge of the kernel limited to 'fakeroot debian/rules
>> >> >> updateconfigs', sorry. :)
>> >> >> Happy to test any improved version, but note I only have a type, not
>> >> >> a
>> >> >> touch cover.
>> >> >>
>> >> >> Patch source is
>> >> >> http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/,
>> >> >> which
>> >> >> in turn sources a Russian site.
>> >> >
>> >> > Hi,
>> >> >
>> >> > thanks. Adding Alan Wu to CC, who sent me a slightly different patch
>> >> > for
>> >> > this issue -- see the archives of linux-input list from a few days
>> >> > back.
>> >> >
>> >> > Your patch is missing at least Signed-off-by: line, and also seems to
>> >> > lack
>> >> > the update to hid_have_special_driver[].
>> >>
>> >> Jiri, actually, the hid_have_special_driver entry is not 100% required
>> >> to make it work (though it would be cleaner, I agree).
>> >> Actually, the TypeCover presents a Precision TouchPad, so hid-core
>> >> considers it should have the hid-multitouch driver driving it (see
>> >> https://bugzilla.redhat.com/show_bug.cgi?id=1135338 )
>> >>
>> >> I am not sure we should use hid-multitouch or hid-microsoft. My guess
>> >> is that both will work, but hid-multitouch might provide true raw
>> >> reporting for the touchpad. On the other hand, maybe hid-microsoft
>> >> will bind special keys that hid-multitouch will not...
>> >>
>> > I would think that being able to do multifinger gestures would make
>> > using
>> > hid-multitouch preferable. Using hid-microsoft will keep the touchpad in
>> > mouse mode since the host needs to send the feature report to switch the
>> > touchpad into PTP mode. In PTP mode, this touchpad will report absolute
>> > data
>> > for three fingers.
>> >
>> > I think the main issue is how do you get the keyboard working when the
>> > device is using the hid-multitouch driver. After looking at the bug
>> > above
>> > and Benjamin's changes on Github it looks like adding an entry in
>> > mt_devices
>> > and setting MT_CLS_EXPORT_ALL_INPUTS would also export the keyboard. Is
>> > that
>> > correct? I haven't been able to try it out.
>>
>> Correct. See
>> https://github.com/bentiss/hid-multitouch/commit/999eb73d37bab0b72f775f2150b1c27488610414
>> The reporter seems to claim that it works for him, but I need to check
>> if the touchpad is correctly presented (properties, etc), if the
>> touchpad data come from the raw node, and not the mouse node, and if
>> there is no problems with respect to the keyboard. I'd prefer the
>> owners of the device to double check all of this.
>>
>> >
>> > If hid-microsoft has functionality which hid-multitouch doesn't provide
>> > is
>> > there a way to combine the two without reimplementing the functionality
>> > of
>> > one driver into the other?
>>
>> The problem with this device is that the keyboard and touchpad are on
>> the same hid device, on different collections. So if hid-microsoft
>> does fancy stuff on the keyboard level, the only option will be to
>> merge hid-multitouch in hid-input (this might be needed at some
>> point).
>>
>> Cheers,
>> Benjamin
>>
>> >
>> >>
>> >> If the path is to go through hid-microsoft, then Jarrad, Alan, yes,
>> >> please, add your device to hid_have_special_driver.
>> >>
>> >> Cheers,
>> >> Benjamin
>> >>
>> >> >
>> >> > Could you two guys please cooperate and send me a patch that should
>> >> > be
>> >> > applied? I don't have the device so can't really test properly
>> >> > myself.
>> >> >
>> >> > Thanks,
>> >> >
>> >> > --
>> >> > Jiri Kosina
>> >> > SUSE Labs
>> >> > --
>> >> > To unsubscribe from this list: send the line "unsubscribe
>> >> > linux-input"
>> >> > in
>> >> > the body of a message to majordomo@vger.kernel.org
>> >> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe linux-input"
>> >> in
>> >> the body of a message to majordomo@vger.kernel.org
>> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >
>> >
>
>
^ permalink raw reply
* [PATCH v2 2/2] HID: logitech-hidpp: 2 fixes in hidpp_root_get_protocol_version()
From: Benjamin Tissoires @ 2014-11-03 21:09 UTC (permalink / raw)
To: Jiri Kosina, Dan Carpenter, Nestor Lopez Casado; +Cc: linux-input, linux-kernel
In-Reply-To: <1415048999-4490-1-git-send-email-benjamin.tissoires@redhat.com>
- remove the constant '1'
- when the device is not connected, the protocol error
HIDPP_ERROR_RESOURCE_ERROR is raised. We should not warn the user about
it because it is somewhat expected as an answer when we check if the
device is connected.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Changes in v2:
none
drivers/hid/hid-logitech-hidpp.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 61f9e75..1a6395d 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -361,12 +361,16 @@ static int hidpp_root_get_protocol_version(struct hidpp_device *hidpp)
CMD_ROOT_GET_PROTOCOL_VERSION,
NULL, 0, &response);
- if (ret == 1) {
+ if (ret == HIDPP_ERROR_INVALID_SUBID) {
hidpp->protocol_major = 1;
hidpp->protocol_minor = 0;
return 0;
}
+ /* the device might not be connected */
+ if (ret == HIDPP_ERROR_RESOURCE_ERROR)
+ return -EIO;
+
if (ret > 0) {
hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
__func__, ret);
--
2.1.0
^ permalink raw reply related
* [PATCH v2 1/2] HID: logitech-hidpp: fix negated returns
From: Benjamin Tissoires @ 2014-11-03 21:09 UTC (permalink / raw)
To: Jiri Kosina, Dan Carpenter, Nestor Lopez Casado; +Cc: linux-input, linux-kernel
Reported by Dan Carpenter:
drivers/hid/hid-logitech-hidpp.c:359 hidpp_root_get_protocol_version() warn: should this return really be negated?
drivers/hid/hid-logitech-hidpp.c:398 hidpp_devicenametype_get_count() warn: should this return really be negated?
drivers/hid/hid-logitech-hidpp.c:417 hidpp_devicenametype_get_device_name() warn: should this return really be negated?
drivers/hid/hid-logitech-hidpp.c:524 hidpp_touchpad_get_raw_info() warn: should this return really be negated?
The problem lies in hidpp_send_message_sync() which can return 2 types of
errors depending of their sign. Adding a comment there to clarify what is
happening.
To solve that, print an error in case of a protocol problem, and raise
-EPROTO instead.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Changes in v2:
- also return if the ret code is negative
drivers/hid/hid-logitech-hidpp.c | 36 ++++++++++++++++++++++++++++++++----
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 8d2d54b..61f9e75 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -151,6 +151,14 @@ static int __hidpp_send_report(struct hid_device *hdev,
return ret == fields_count ? 0 : -1;
}
+/**
+ * hidpp_send_message_sync() returns 0 in case of success, and something else
+ * in case of a failure.
+ * - If ' something else' is positive, that means that an error has been raised
+ * by the protocol itself.
+ * - If ' something else' is negative, that means that we had a classic error
+ * (-ENOMEM, -EPIPE, etc...)
+ */
static int hidpp_send_message_sync(struct hidpp_device *hidpp,
struct hidpp_report *message,
struct hidpp_report *response)
@@ -359,8 +367,13 @@ static int hidpp_root_get_protocol_version(struct hidpp_device *hidpp)
return 0;
}
+ if (ret > 0) {
+ hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
+ __func__, ret);
+ return -EPROTO;
+ }
if (ret)
- return -ret;
+ return ret;
hidpp->protocol_major = response.fap.params[0];
hidpp->protocol_minor = response.fap.params[1];
@@ -398,8 +411,13 @@ static int hidpp_devicenametype_get_count(struct hidpp_device *hidpp,
ret = hidpp_send_fap_command_sync(hidpp, feature_index,
CMD_GET_DEVICE_NAME_TYPE_GET_COUNT, NULL, 0, &response);
+ if (ret > 0) {
+ hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
+ __func__, ret);
+ return -EPROTO;
+ }
if (ret)
- return -ret;
+ return ret;
*nameLength = response.fap.params[0];
@@ -417,8 +435,13 @@ static int hidpp_devicenametype_get_device_name(struct hidpp_device *hidpp,
CMD_GET_DEVICE_NAME_TYPE_GET_DEVICE_NAME, &char_index, 1,
&response);
+ if (ret > 0) {
+ hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
+ __func__, ret);
+ return -EPROTO;
+ }
if (ret)
- return -ret;
+ return ret;
if (response.report_id == REPORT_ID_HIDPP_LONG)
count = HIDPP_REPORT_LONG_LENGTH - 4;
@@ -524,8 +547,13 @@ static int hidpp_touchpad_get_raw_info(struct hidpp_device *hidpp,
ret = hidpp_send_fap_command_sync(hidpp, feature_index,
CMD_TOUCHPAD_GET_RAW_INFO, NULL, 0, &response);
+ if (ret > 0) {
+ hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
+ __func__, ret);
+ return -EPROTO;
+ }
if (ret)
- return -ret;
+ return ret;
raw_info->x_size = get_unaligned_be16(¶ms[0]);
raw_info->y_size = get_unaligned_be16(¶ms[2]);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 1/2] HID: logitech-hidpp: fix negated returns
From: Benjamin Tissoires @ 2014-11-03 20:41 UTC (permalink / raw)
To: Dan Carpenter
Cc: Benjamin Tissoires, Jiri Kosina, Nestor Lopez Casado, linux-input,
linux-kernel@vger.kernel.org
In-Reply-To: <20141103203230.GV6890@mwanda>
On Mon, Nov 3, 2014 at 3:32 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> On Mon, Nov 03, 2014 at 02:50:52PM -0500, Benjamin Tissoires wrote:
>> @@ -524,8 +541,11 @@ static int hidpp_touchpad_get_raw_info(struct hidpp_device *hidpp,
>> ret = hidpp_send_fap_command_sync(hidpp, feature_index,
>> CMD_TOUCHPAD_GET_RAW_INFO, NULL, 0, &response);
>>
>> - if (ret)
>> - return -ret;
>> + if (ret > 0) {
>> + hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
>> + __func__, ret);
>> + return -EPROTO;
>> + }
>
> We should handle -ENOMEM and -EINVAL here as well. Something like:
>
> if (ret > 0) {
> hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
> __func__, ret);
> ret = -EPROTO;
> }
> if (ret)
> return ret;
Ouch. my bad...
No, I don't have any excuses for that.
Thanks for the review.
Cheers,
Benjamin
^ permalink raw reply
* Re: Supporting U2F over HID on Linux?
From: Andy Lutomirski @ 2014-11-03 20:41 UTC (permalink / raw)
To: Jiri Kosina
Cc: systemd Mailing List, Kay Sievers, open list:HID CORE LAYER,
Benjamin Tissoires
In-Reply-To: <alpine.LNX.2.00.1411032115140.19451@pobox.suse.cz>
On Mon, Nov 3, 2014 at 12:21 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Mon, 3 Nov 2014, David Herrmann wrote:
>
>> > Agreed, mostly. My only real concern is that this could be annoying
>> > for the userspace developers who will need to target Linux and HIDAPI
>> > separately. Admittedly the Linux support will be trivial.
>>
>> I see. I'll not stop you from using hidraw, I'd just not recommend it.
>> Especially for security stuff I dislike exposing the whole HID device
>> writable. But yeah, I guess you got my point.
>
> Alright, I am basically thinking loudly now, but how about we allow HID
> drivers that would override default hidraw interface?
>
> I am very well aware of the fact that this could be opening a can of
> worms, so we'll have to make it very restrictive. How about, let's say, we
> allow HID drivers to provide custom hidraw interface (completely
> overriding the one that HID core would normally create) only for cases
> such as:
>
> - the intent is to expose only certain parts of a combined device
> - the intent is to introduce some level of access control
>
> I.e. still no interference of kernel with data parsing allowed.
Hmm. Would this be like a filter on hidraw actions?
How would udev distinguish these special hidraw devices from normal
hidraw devices?
Also, for U2F, this could be a little awkward. There's some crazy
fragmentation stuff to allow a U2F request to be split across HID
requests, and I think a kernel driver would much rather get the
original unfragmented application request.
--Andy
>
>> > I can give the driver a try. It'll actually be simpler than the spec
>> > makes it out, since a real kernel driver will have no need to
>> > arbitrate with itself.
>>
>> I'll gladly review any custom HID drivers. Feel free to put me on CC
>> when sending to linux-input. There's also a lot of examples in
>> drivers/hid/ in case you need a head-start (especially if you need the
>> raw_event callback).
>
> Same here, of course.
>
> Please always CC me in parallel to sending to linux-input@ to make sure
> that the patch doesn't fall in between cracks.
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
--
Andy Lutomirski
AMA Capital Management, LLC
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
^ permalink raw reply
* Re: Microsoft Surface Pro 3 Type Cover keyboard
From: Benjamin Tissoires @ 2014-11-03 20:39 UTC (permalink / raw)
To: Andrew Duggan
Cc: Jiri Kosina, Jarrad Whitaker, linux-input, Alan Wu, Andrew Duggan
In-Reply-To: <CAE7eX3JsnY_xAookiT_ycdES5dRP6GkAa+bcRyQ5HaU9iMtGQw@mail.gmail.com>
On Mon, Nov 3, 2014 at 3:33 PM, Andrew Duggan <andrew.duggan@gmail.com> wrote:
>
>
> On Mon, Nov 3, 2014 at 7:28 AM, Benjamin Tissoires
> <benjamin.tissoires@gmail.com> wrote:
>>
>> On Mon, Nov 3, 2014 at 8:33 AM, Jiri Kosina <jkosina@suse.cz> wrote:
>> > On Fri, 24 Oct 2014, Jarrad Whitaker wrote:
>> >
>> >> The keyboard on the Surface Pro 3 type cover does not function without
>> >> some patching, similar to what was apparently required for the SP2
>> >> type/touch covers.
>> >>
>> >> A working patch against 3.16 attached, it's an amalgamation of "some
>> >> dude posted this on the ubuntu/arch forums and it seems to work" so
>> >> I'm making no claims that it's kernel-quality! Just trying to give a
>> >> better indication of what needs to be added. My C is rudimentary and
>> >> my knowledge of the kernel limited to 'fakeroot debian/rules
>> >> updateconfigs', sorry. :)
>> >> Happy to test any improved version, but note I only have a type, not a
>> >> touch cover.
>> >>
>> >> Patch source is
>> >> http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/, which
>> >> in turn sources a Russian site.
>> >
>> > Hi,
>> >
>> > thanks. Adding Alan Wu to CC, who sent me a slightly different patch for
>> > this issue -- see the archives of linux-input list from a few days back.
>> >
>> > Your patch is missing at least Signed-off-by: line, and also seems to
>> > lack
>> > the update to hid_have_special_driver[].
>>
>> Jiri, actually, the hid_have_special_driver entry is not 100% required
>> to make it work (though it would be cleaner, I agree).
>> Actually, the TypeCover presents a Precision TouchPad, so hid-core
>> considers it should have the hid-multitouch driver driving it (see
>> https://bugzilla.redhat.com/show_bug.cgi?id=1135338 )
>>
>> I am not sure we should use hid-multitouch or hid-microsoft. My guess
>> is that both will work, but hid-multitouch might provide true raw
>> reporting for the touchpad. On the other hand, maybe hid-microsoft
>> will bind special keys that hid-multitouch will not...
>>
> I would think that being able to do multifinger gestures would make using
> hid-multitouch preferable. Using hid-microsoft will keep the touchpad in
> mouse mode since the host needs to send the feature report to switch the
> touchpad into PTP mode. In PTP mode, this touchpad will report absolute data
> for three fingers.
>
> I think the main issue is how do you get the keyboard working when the
> device is using the hid-multitouch driver. After looking at the bug above
> and Benjamin's changes on Github it looks like adding an entry in mt_devices
> and setting MT_CLS_EXPORT_ALL_INPUTS would also export the keyboard. Is that
> correct? I haven't been able to try it out.
Correct. See https://github.com/bentiss/hid-multitouch/commit/999eb73d37bab0b72f775f2150b1c27488610414
The reporter seems to claim that it works for him, but I need to check
if the touchpad is correctly presented (properties, etc), if the
touchpad data come from the raw node, and not the mouse node, and if
there is no problems with respect to the keyboard. I'd prefer the
owners of the device to double check all of this.
>
> If hid-microsoft has functionality which hid-multitouch doesn't provide is
> there a way to combine the two without reimplementing the functionality of
> one driver into the other?
The problem with this device is that the keyboard and touchpad are on
the same hid device, on different collections. So if hid-microsoft
does fancy stuff on the keyboard level, the only option will be to
merge hid-multitouch in hid-input (this might be needed at some
point).
Cheers,
Benjamin
>
>>
>> If the path is to go through hid-microsoft, then Jarrad, Alan, yes,
>> please, add your device to hid_have_special_driver.
>>
>> Cheers,
>> Benjamin
>>
>> >
>> > Could you two guys please cooperate and send me a patch that should be
>> > applied? I don't have the device so can't really test properly myself.
>> >
>> > Thanks,
>> >
>> > --
>> > Jiri Kosina
>> > SUSE Labs
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-input"
>> > in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-input" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH] HID: core: cleanup .claimed field on disconnect
From: Benjamin Tissoires @ 2014-11-03 20:33 UTC (permalink / raw)
To: Jiri Kosina, Nestor Lopez Casado, Andrew de los Reyes
Cc: linux-input, linux-kernel
When a subdriver is rmmod-ed then re-insmod-ed, the hid device is not
destroyed as it is owned by the transport layer.
So when we re-probed the device, the hid device is assumed to be already
claimed, and can lead to page faults if hid-core tries to forward the
emitted data to the to-be-created claimed node.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Hi Jiri,
[keeping the people involved in the logitech-hidpp driver in CC]
this one was particularly nasty. I had several page faults when just
rmmod && insmod the hid-logitech-hidpp driver. The page fault was occuring
in hidraw :/
I was not able to get a stacktrace which I could include here. The laptop was
completely unresponsive and I could take only a picture to debug it.
Cheers,
Benjamin
drivers/hid/hid-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 1e2d512..bbb138d 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1656,6 +1656,7 @@ void hid_disconnect(struct hid_device *hdev)
hdev->hiddev_disconnect(hdev);
if (hdev->claimed & HID_CLAIMED_HIDRAW)
hidraw_disconnect(hdev);
+ hdev->claimed = 0;
}
EXPORT_SYMBOL_GPL(hid_disconnect);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 1/2] HID: logitech-hidpp: fix negated returns
From: Dan Carpenter @ 2014-11-03 20:32 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Nestor Lopez Casado, linux-input, linux-kernel
In-Reply-To: <1415044253-18734-1-git-send-email-benjamin.tissoires@redhat.com>
On Mon, Nov 03, 2014 at 02:50:52PM -0500, Benjamin Tissoires wrote:
> @@ -524,8 +541,11 @@ static int hidpp_touchpad_get_raw_info(struct hidpp_device *hidpp,
> ret = hidpp_send_fap_command_sync(hidpp, feature_index,
> CMD_TOUCHPAD_GET_RAW_INFO, NULL, 0, &response);
>
> - if (ret)
> - return -ret;
> + if (ret > 0) {
> + hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
> + __func__, ret);
> + return -EPROTO;
> + }
We should handle -ENOMEM and -EINVAL here as well. Something like:
if (ret > 0) {
hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
__func__, ret);
ret = -EPROTO;
}
if (ret)
return ret;
regards,
dan carpenter
^ permalink raw reply
* Re: Supporting U2F over HID on Linux?
From: Jiri Kosina @ 2014-11-03 20:21 UTC (permalink / raw)
To: David Herrmann
Cc: systemd Mailing List, Kay Sievers, Andy Lutomirski,
open list:HID CORE LAYER, Benjamin Tissoires
In-Reply-To: <CANq1E4Sa=D_hvSp2SqHy4cV-oxd-kchsNVivcF54cBv8DK7gOQ@mail.gmail.com>
On Mon, 3 Nov 2014, David Herrmann wrote:
> > Agreed, mostly. My only real concern is that this could be annoying
> > for the userspace developers who will need to target Linux and HIDAPI
> > separately. Admittedly the Linux support will be trivial.
>
> I see. I'll not stop you from using hidraw, I'd just not recommend it.
> Especially for security stuff I dislike exposing the whole HID device
> writable. But yeah, I guess you got my point.
Alright, I am basically thinking loudly now, but how about we allow HID
drivers that would override default hidraw interface?
I am very well aware of the fact that this could be opening a can of
worms, so we'll have to make it very restrictive. How about, let's say, we
allow HID drivers to provide custom hidraw interface (completely
overriding the one that HID core would normally create) only for cases
such as:
- the intent is to expose only certain parts of a combined device
- the intent is to introduce some level of access control
I.e. still no interference of kernel with data parsing allowed.
> > I can give the driver a try. It'll actually be simpler than the spec
> > makes it out, since a real kernel driver will have no need to
> > arbitrate with itself.
>
> I'll gladly review any custom HID drivers. Feel free to put me on CC
> when sending to linux-input. There's also a lot of examples in
> drivers/hid/ in case you need a head-start (especially if you need the
> raw_event callback).
Same here, of course.
Please always CC me in parallel to sending to linux-input@ to make sure
that the patch doesn't fall in between cracks.
Thanks,
--
Jiri Kosina
SUSE Labs
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
^ permalink raw reply
* [PATCH 1/2] HID: logitech-hidpp: fix negated returns
From: Benjamin Tissoires @ 2014-11-03 19:50 UTC (permalink / raw)
To: Jiri Kosina, Dan Carpenter, Nestor Lopez Casado; +Cc: linux-input, linux-kernel
Reported by Dan Carpenter:
drivers/hid/hid-logitech-hidpp.c:359 hidpp_root_get_protocol_version() warn: should this return really be negated?
drivers/hid/hid-logitech-hidpp.c:398 hidpp_devicenametype_get_count() warn: should this return really be negated?
drivers/hid/hid-logitech-hidpp.c:417 hidpp_devicenametype_get_device_name() warn: should this return really be negated?
drivers/hid/hid-logitech-hidpp.c:524 hidpp_touchpad_get_raw_info() warn: should this return really be negated?
The problem lies in hidpp_send_message_sync() which can return 2 types of
errors depending of their sign. Adding a comment there to clarify what is
happening.
To solve that, print an error in case of a protocol problem, and raise
-EPROTO instead.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-logitech-hidpp.c | 36 ++++++++++++++++++++++++++++--------
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 8d2d54b..4793d4b 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -151,6 +151,14 @@ static int __hidpp_send_report(struct hid_device *hdev,
return ret == fields_count ? 0 : -1;
}
+/**
+ * hidpp_send_message_sync() returns 0 in case of success, and something else
+ * in case of a failure.
+ * - If ' something else' is positive, that means that an error has been raised
+ * by the protocol itself.
+ * - If ' something else' is negative, that means that we had a classic error
+ * (-ENOMEM, -EPIPE, etc...)
+ */
static int hidpp_send_message_sync(struct hidpp_device *hidpp,
struct hidpp_report *message,
struct hidpp_report *response)
@@ -359,8 +367,11 @@ static int hidpp_root_get_protocol_version(struct hidpp_device *hidpp)
return 0;
}
- if (ret)
- return -ret;
+ if (ret > 0) {
+ hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
+ __func__, ret);
+ return -EPROTO;
+ }
hidpp->protocol_major = response.fap.params[0];
hidpp->protocol_minor = response.fap.params[1];
@@ -398,8 +409,11 @@ static int hidpp_devicenametype_get_count(struct hidpp_device *hidpp,
ret = hidpp_send_fap_command_sync(hidpp, feature_index,
CMD_GET_DEVICE_NAME_TYPE_GET_COUNT, NULL, 0, &response);
- if (ret)
- return -ret;
+ if (ret > 0) {
+ hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
+ __func__, ret);
+ return -EPROTO;
+ }
*nameLength = response.fap.params[0];
@@ -417,8 +431,11 @@ static int hidpp_devicenametype_get_device_name(struct hidpp_device *hidpp,
CMD_GET_DEVICE_NAME_TYPE_GET_DEVICE_NAME, &char_index, 1,
&response);
- if (ret)
- return -ret;
+ if (ret > 0) {
+ hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
+ __func__, ret);
+ return -EPROTO;
+ }
if (response.report_id == REPORT_ID_HIDPP_LONG)
count = HIDPP_REPORT_LONG_LENGTH - 4;
@@ -524,8 +541,11 @@ static int hidpp_touchpad_get_raw_info(struct hidpp_device *hidpp,
ret = hidpp_send_fap_command_sync(hidpp, feature_index,
CMD_TOUCHPAD_GET_RAW_INFO, NULL, 0, &response);
- if (ret)
- return -ret;
+ if (ret > 0) {
+ hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
+ __func__, ret);
+ return -EPROTO;
+ }
raw_info->x_size = get_unaligned_be16(¶ms[0]);
raw_info->y_size = get_unaligned_be16(¶ms[2]);
--
2.1.0
^ permalink raw reply related
* [PATCH 2/2] HID: logitech-hidpp: 2 fixes in hidpp_root_get_protocol_version()
From: Benjamin Tissoires @ 2014-11-03 19:50 UTC (permalink / raw)
To: Jiri Kosina, Dan Carpenter, Nestor Lopez Casado; +Cc: linux-input, linux-kernel
In-Reply-To: <1415044253-18734-1-git-send-email-benjamin.tissoires@redhat.com>
- remove the constant '1'
- when the device is not connected, the protocol error
HIDPP_ERROR_RESOURCE_ERROR is raised. We should not warn the user about
it because it is somewhat expected as an answer when we check if the
device is connected.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-logitech-hidpp.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 4793d4b..2683564 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -361,12 +361,16 @@ static int hidpp_root_get_protocol_version(struct hidpp_device *hidpp)
CMD_ROOT_GET_PROTOCOL_VERSION,
NULL, 0, &response);
- if (ret == 1) {
+ if (ret == HIDPP_ERROR_INVALID_SUBID) {
hidpp->protocol_major = 1;
hidpp->protocol_minor = 0;
return 0;
}
+ /* the device might not be connected */
+ if (ret == HIDPP_ERROR_RESOURCE_ERROR)
+ return -EIO;
+
if (ret > 0) {
hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
__func__, ret);
--
2.1.0
^ permalink raw reply related
* Re: [systemd-devel] Supporting U2F over HID on Linux?
From: David Herrmann @ 2014-11-03 19:31 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Kay Sievers, Greg KH, systemd Mailing List, Jiri Kosina,
open list:HID CORE LAYER, Benjamin Tissoires
In-Reply-To: <CALCETrVU5Kq0wYGXNQ1dsihy1LN1WUmAN4J9puyVPv=b_WNrLw@mail.gmail.com>
Hi
On Mon, Nov 3, 2014 at 8:19 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Mon, Nov 3, 2014 at 11:03 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> Hi
>>
>> On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> I want to get U2F (universal second factor, sometimes called "security
>>> key" or even "gnubby") working on Linux. U2F tokens are HID devices
>>> that speak a custom protocol. The intent is that user code will speak
>>> to then using something like HIDAPI.
>>>
>>> The trick is that, for HIDAPI to work, something needs to recognize
>>> these devices and get udev to set appropriate device permissions.
>>
>> [snip]
>>
>>> - An actual kernel driver for U2F devices using the hid group
>>> mechanism for enumeration. This seems overcomplicated.
>>
>> Imho, this is the way to go. Create a proper char-dev for U2F, create
>> an API and make it work.
>>
>> We had this discussion earlier about vendor-extensions that should be
>> writable via hidraw from user-space. This turned out to be really
>> messy.. and was discussed for several weeks straight. hidraw just
>> wasn't designed as unprivileged user-space API. For instance, what
>> happens if a device provides U2F plus something else? Both will be on
>> the same hidraw device.
>> We could split hidraw per usage, but I don't see how that is superior
>> to a proper U2F API. And once one usage can affect a device as a whole
>> (like power-off), you're screwed.
>
> Agreed, mostly. My only real concern is that this could be annoying
> for the userspace developers who will need to target Linux and HIDAPI
> separately. Admittedly the Linux support will be trivial.
I see. I'll not stop you from using hidraw, I'd just not recommend it.
Especially for security stuff I dislike exposing the whole HID device
writable. But yeah, I guess you got my point.
> I can give the driver a try. It'll actually be simpler than the spec
> makes it out, since a real kernel driver will have no need to
> arbitrate with itself.
I'll gladly review any custom HID drivers. Feel free to put me on CC
when sending to linux-input. There's also a lot of examples in
drivers/hid/ in case you need a head-start (especially if you need the
raw_event callback).
Thanks
David
^ permalink raw reply
* Re: [systemd-devel] Supporting U2F over HID on Linux?
From: Andy Lutomirski @ 2014-11-03 19:19 UTC (permalink / raw)
To: David Herrmann
Cc: Kay Sievers, Greg KH, systemd Mailing List, Jiri Kosina,
open list:HID CORE LAYER, Benjamin Tissoires
In-Reply-To: <CANq1E4QvuNHRq6Saca-KigTjmvyosqM6_JkqF-_OHqxLa=Zdow@mail.gmail.com>
On Mon, Nov 3, 2014 at 11:03 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> I want to get U2F (universal second factor, sometimes called "security
>> key" or even "gnubby") working on Linux. U2F tokens are HID devices
>> that speak a custom protocol. The intent is that user code will speak
>> to then using something like HIDAPI.
>>
>> The trick is that, for HIDAPI to work, something needs to recognize
>> these devices and get udev to set appropriate device permissions.
>
> [snip]
>
>> - An actual kernel driver for U2F devices using the hid group
>> mechanism for enumeration. This seems overcomplicated.
>
> Imho, this is the way to go. Create a proper char-dev for U2F, create
> an API and make it work.
>
> We had this discussion earlier about vendor-extensions that should be
> writable via hidraw from user-space. This turned out to be really
> messy.. and was discussed for several weeks straight. hidraw just
> wasn't designed as unprivileged user-space API. For instance, what
> happens if a device provides U2F plus something else? Both will be on
> the same hidraw device.
> We could split hidraw per usage, but I don't see how that is superior
> to a proper U2F API. And once one usage can affect a device as a whole
> (like power-off), you're screwed.
Agreed, mostly. My only real concern is that this could be annoying
for the userspace developers who will need to target Linux and HIDAPI
separately. Admittedly the Linux support will be trivial.
I can give the driver a try. It'll actually be simpler than the spec
makes it out, since a real kernel driver will have no need to
arbitrate with itself.
--Andy
>
> Just look at the libusb mess where some devices are handled in the
> kernel and some in user-space (eg., see Gnome cheese, media devices,
> ...). I don't think we should repeat that with HID.
>
> Thanks
> David
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: Supporting U2F over HID on Linux?
From: David Herrmann @ 2014-11-03 19:03 UTC (permalink / raw)
To: Andy Lutomirski
Cc: systemd Mailing List, Jiri Kosina, Kay Sievers,
open list:HID CORE LAYER, Benjamin Tissoires
In-Reply-To: <CALCETrXKcU1KaEjFUm9QkEhZRh9wFnoR=hV7O9pUJmYRqNCxpg@mail.gmail.com>
Hi
On Sun, Nov 2, 2014 at 7:57 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> I want to get U2F (universal second factor, sometimes called "security
> key" or even "gnubby") working on Linux. U2F tokens are HID devices
> that speak a custom protocol. The intent is that user code will speak
> to then using something like HIDAPI.
>
> The trick is that, for HIDAPI to work, something needs to recognize
> these devices and get udev to set appropriate device permissions.
[snip]
> - An actual kernel driver for U2F devices using the hid group
> mechanism for enumeration. This seems overcomplicated.
Imho, this is the way to go. Create a proper char-dev for U2F, create
an API and make it work.
We had this discussion earlier about vendor-extensions that should be
writable via hidraw from user-space. This turned out to be really
messy.. and was discussed for several weeks straight. hidraw just
wasn't designed as unprivileged user-space API. For instance, what
happens if a device provides U2F plus something else? Both will be on
the same hidraw device.
We could split hidraw per usage, but I don't see how that is superior
to a proper U2F API. And once one usage can affect a device as a whole
(like power-off), you're screwed.
Just look at the libusb mess where some devices are handled in the
kernel and some in user-space (eg., see Gnome cheese, media devices,
...). I don't think we should repeat that with HID.
Thanks
David
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
^ permalink raw reply
* Re: [PATCH 0/4] Touchscreen performance related fixes
From: Richard Cochran @ 2014-11-03 18:09 UTC (permalink / raw)
To: Vignesh R
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Benoit Cousson, Tony Lindgren, Russell King, Jonathan Cameron,
Dmitry Torokhov, devicetree, Lars-Peter Clausen, Samuel Ortiz,
Jan Kardell, linux-iio, Sebastian Andrzej Siewior, linux-input,
linux-kernel, Felipe Balbi, Paul Gortmaker, Peter Meerwald,
Hartmut Knaack, linux-omap, Lee Jones, linux-arm
In-Reply-To: <1414408111-2631-1-git-send-email-vigneshr@ti.com>
On Mon, Oct 27, 2014 at 04:38:27PM +0530, Vignesh R wrote:
> This series of patches fix TSC defects related to lag in touchscreen
> performance and cursor jump at touch release. The lag was result of
> udelay in TSC interrupt handler. Cursor jump due to false pen-up event.
> The patches implement Advisory 1.0.31 in silicon errata of am335x-evm
> to avoid false pen-up events and remove udelay.
That advisory has two workarounds. You have chosen the second one?
The text of the second workaround says it only works on 4 wire setups,
so I wonder how 5 wire designs will be affected.
> The advisory says to use
> steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel
> ADC).
No, it doesn't say that. (sprz360f.pdf)
> Further the X co-ordinate must be the last one to be sampled just
> before charge step. The first two patches implement the required changes.
FWIW, I implemented the first workaround and removed the udelay not
too long ago. Like Sebastian, I saw the TSC unit hang after about
50000 interrupts when running with the workaround.
Did you test you patch for very long?
Thanks,
Richard
^ permalink raw reply
* Re: Microsoft Surface Pro 3 Type Cover keyboard
From: Benjamin Tissoires @ 2014-11-03 15:28 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Jarrad Whitaker, linux-input, Alan Wu
In-Reply-To: <alpine.LNX.2.00.1411031431150.19451@pobox.suse.cz>
On Mon, Nov 3, 2014 at 8:33 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Fri, 24 Oct 2014, Jarrad Whitaker wrote:
>
>> The keyboard on the Surface Pro 3 type cover does not function without
>> some patching, similar to what was apparently required for the SP2
>> type/touch covers.
>>
>> A working patch against 3.16 attached, it's an amalgamation of "some
>> dude posted this on the ubuntu/arch forums and it seems to work" so
>> I'm making no claims that it's kernel-quality! Just trying to give a
>> better indication of what needs to be added. My C is rudimentary and
>> my knowledge of the kernel limited to 'fakeroot debian/rules
>> updateconfigs', sorry. :)
>> Happy to test any improved version, but note I only have a type, not a
>> touch cover.
>>
>> Patch source is
>> http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/, which
>> in turn sources a Russian site.
>
> Hi,
>
> thanks. Adding Alan Wu to CC, who sent me a slightly different patch for
> this issue -- see the archives of linux-input list from a few days back.
>
> Your patch is missing at least Signed-off-by: line, and also seems to lack
> the update to hid_have_special_driver[].
Jiri, actually, the hid_have_special_driver entry is not 100% required
to make it work (though it would be cleaner, I agree).
Actually, the TypeCover presents a Precision TouchPad, so hid-core
considers it should have the hid-multitouch driver driving it (see
https://bugzilla.redhat.com/show_bug.cgi?id=1135338 )
I am not sure we should use hid-multtiouch or hid-microsoft. My guess
is that both will work, but hid-multitouch might provide true raw
reporting for the touchpad. On the other hand, maybe hid-microsoft
will bind special keys that hid-multitouch will not...
If the path is to go through hid-microsoft, then Jarrad, Alan, yes,
please, add your device to hid_have_special_driver.
Cheers,
Benjamin
>
> Could you two guys please cooperate and send me a patch that should be
> applied? I don't have the device so can't really test properly myself.
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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