[PATCH] HID: input: fix input sysfs path for hid devices

[PATCH] HID: input: fix input sysfs path for hid devices

[Benjamin Tissoires]

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@redhat.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.

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

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

[David Herrmann]

Hi

On Thu, Dec 19, 2013 at 5:05 PM, Benjamin Tissoires
<benjamin.tissoires@redhat.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@redhat.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
>

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

[Jiri Kosina]

On Thu, 19 Dec 2013, David Herrmann wrote:

> <benjamin.tissoires@redhat.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@redhat.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.

Agreed, let's take it for 3.14, and if anyone complains about breakage 
caused by this (which I don't expect), we'll revert to the previous state.

-- 
Jiri Kosina
SUSE Labs

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

[David Herrmann]

Hi Jiri

On Fri, Dec 20, 2013 at 11:36 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Thu, 19 Dec 2013, David Herrmann wrote:
>
>> <benjamin.tissoires@redhat.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@redhat.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.
>
> Agreed, let's take it for 3.14, and if anyone complains about breakage
> caused by this (which I don't expect), we'll revert to the previous state.

You dropped the "Reviewed-by:" part in your commit-msg:
http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=bbe3175408cde792fbaa5bd1e41e430ea9e4fb4f

Not sure, whether you sometimes rebase your tree. If you do, you might
wanna fix it, otherwise, I don't care. Just wanted to point it out.

Cheers
David

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

[Jiri Kosina]

On Wed, 8 Jan 2014, David Herrmann wrote:

> >> > 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.
> >
> > Agreed, let's take it for 3.14, and if anyone complains about breakage
> > caused by this (which I don't expect), we'll revert to the previous state.
> 
> You dropped the "Reviewed-by:" part in your commit-msg:
> http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=bbe3175408cde792fbaa5bd1e41e430ea9e4fb4f
> 
> Not sure, whether you sometimes rebase your tree. If you do, you might
> wanna fix it, otherwise, I don't care. Just wanted to point it out.

Gah, sorry for that. No idea what in my process ate the tag.

I am really trying to make the tree non-rebasing. If you don't mind, I 
wouldn't take this as a reson to rebase.

I can put you twice to some patch later to balance this out :p

Thanks for understanding,

-- 
Jiri Kosina
SUSE Labs

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

[David Herrmann]

Hi

On Wed, Jan 8, 2014 at 5:26 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Wed, 8 Jan 2014, David Herrmann wrote:
>
>> >> > 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.
>> >
>> > Agreed, let's take it for 3.14, and if anyone complains about breakage
>> > caused by this (which I don't expect), we'll revert to the previous state.
>>
>> You dropped the "Reviewed-by:" part in your commit-msg:
>> http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=bbe3175408cde792fbaa5bd1e41e430ea9e4fb4f
>>
>> Not sure, whether you sometimes rebase your tree. If you do, you might
>> wanna fix it, otherwise, I don't care. Just wanted to point it out.
>
> Gah, sorry for that. No idea what in my process ate the tag.
>
> I am really trying to make the tree non-rebasing. If you don't mind, I
> wouldn't take this as a reson to rebase.
>
> I can put you twice to some patch later to balance this out :p
>
> Thanks for understanding,

Haha, don't worry, just saw it during post-review and wanted to let you know.

Cheers
David