linux-kernel - Re: [PATCH] HID: input: fix input sysfs path for hid devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANq1E4QrPAJ7zNdN51PGQD5tkD_gTYfRoHOg7=zwVvnu-xOR0g@mail.gmail.com>
Date:	Thu, 19 Dec 2013 17:33:40 +0100
From:	David Herrmann <dh.herrmann@...il.com>
To:	Benjamin Tissoires <benjamin.tissoires@...hat.com>
Cc:	Benjamin Tissoires <benjamin.tissoires@...il.com>,
	Jiri Kosina <jkosina@...e.cz>,
	"open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] HID: input: fix input sysfs path for hid devices

Hi

On Thu, Dec 19, 2013 at 5:05 PM, Benjamin Tissoires
<benjamin.tissoires@...hat.com> wrote:
> we used to set the parent of the input device as the parent of
> the hid bus. This was introduced when we created hid as a real bus, and
> to keep backward compatibility. Now, it's time to proper set the parent
> so that sysfs has an idea of which input device is attached to
> which hid device.
>
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@...hat.com>
> ---
>
> Hi Jiri,
>
> well, the regression test did not showed anything bad, and a look at the hid
> drivers also showed that no drivers should be armed by that.
>
> I think this is valuable because it will give a better understanding of the
> actual mapping hardware/inputs. Like a touchscreen with pen + touch will have
> the same hid parent, and I expect X/Wayland to be able to detect this at some
> point to keep the mapping correctly between the two input devices and the screen.
>
> I also need that for hid-replay, so that I can be sure which input is attached
> to which uhid device, and give up the heuristics I currently use.

I was just wondering where we have multiple HID devices on a single
parent, but yeah, uhid is a good example. I actually have no
objections to this patch and it looks fine. But I cannot tell whether
anyone relies on this.

I'd say we should give it a try.
David

> Cheers,
> Benjamin
>
>  drivers/hid/hid-input.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index d97f232..d50e731 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1279,7 +1279,7 @@ static struct hid_input *hidinput_allocate(struct hid_device *hid)
>         input_dev->id.vendor  = hid->vendor;
>         input_dev->id.product = hid->product;
>         input_dev->id.version = hid->version;
> -       input_dev->dev.parent = hid->dev.parent;
> +       input_dev->dev.parent = &hid->dev;
>         hidinput->input = input_dev;
>         list_add_tail(&hidinput->list, &hid->inputs);
>
> --
> 1.8.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/