From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: Ping Cheng <pinglinux@gmail.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Jason Gerecke <killertofu@gmail.com>,
linux-input <linux-input@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Input - wacom: put a flag when the led are initialized
Date: Mon, 16 Jun 2014 12:33:04 -0400 [thread overview]
Message-ID: <20140616163304.GB11091@mail.corp.redhat.com> (raw)
In-Reply-To: <CAF8JNhKBodDC0=M0evsN4xSn7+qPvQZ52XF+mfusgT_1L3Ks8w@mail.gmail.com>
Hi Ping,
On Jun 13 2014 or thereabouts, Ping Cheng wrote:
> Hi Benjamin,
>
> On Fri, Jun 13, 2014 at 1:29 PM, Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
> > This solves a bug with the wireless receiver:
>
> Your patch does get rid of the crash. But, it does not fix it at the
> root cause.
True, it fixes the crash, does not get rid of the root cause, but it is
still required. See later.
>
> > - at plug, the wireless receiver does not know which Wacom device it is
> > connected to, so it does not actually creates all the LEDs
>
> This is the root cause - LEDs are not created for wireless devices.
> Neither here, nor later when a real device is connected.
Yep
>
> > - when the tablet connects, wacom->wacom_wac.features.type is set to the
> > proper device so that wacom_wac can understand the packets
>
> LEDs are not created for any wireless devices since we don't call
> wacom_initialize_leds() when real tablets are connected.
Yep
>
> > - when the receiver is unplugged, it detects that a LED should have been
> > created (based on wacom->wacom_wac.features.type) and tries to remove
> > it: crash when removing the sysfs group.
>
> When receiver is unplugged, it remembers the last tablet that
> connected to it. If that tablet supports LEDs, wacom_destroy_leds() is
> called. But, no LEDs were initialized. That's why it crashes.
Yep
>
> > Side effect, we can now safely call several times wacom_destroy_leds().
>
> led_initialized will never be true if we keep wacom_initialize_leds()
> inside probe().
If you are talking about wireless devices only, yes, this value will
never be true. That's the purpose of this patch actually :)
>
> To make initialize_leds() and desctroy_leds() work for wireless
> devices, we need to move them to wacom_wireless_work() where we know
> what type of tablet is connected/disconnected.
Unfortunately, this does not work:
- we *can* create the LEDs sysfs in the wireless work
- this will prevent the crash
- the user will think it can control the LEDs
- actually these LEDs control will do nothing because LEDs handling for
wireless devices goes through the WL interface, and not the PEN
interface of the WL receiver.
- we need to implement a specific led_handling for the wireless receiver
(which will need to know which type of tablet is connected to it)
- we still need a way to say that the pen intf which is declared as the
connected device does not has a LED sysfs.
We could add a quirk to the wacom_wac->features saying that the
connection is wireless, so there is no LED attached to the interface.
Still, there will be some work to do to properly handle the LED
configuration from the WL receiver. This work has to be done in the
kernel, but also in the user space (g-s-d) because now, the led control
will not be on the pen device, but on a plain usb device without input.
If you prefer, I can add such a quirk. But my only concern is here to
fix the kernel oops, not to add features which would require more
testing across different hardware and development on the user space
side.
>
> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> Thank you for your support. But, sorry
>
> NAKed-by: Ping Cheng <pingc@wacom.com>
Please reconsider it or validate the quirk approach I mentioned.
Cheers,
Benjamin
next prev parent reply other threads:[~2014-06-16 16:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-13 20:29 [PATCH] Input - wacom: put a flag when the led are initialized Benjamin Tissoires
2014-06-14 0:28 ` Ping Cheng
2014-06-16 16:33 ` Benjamin Tissoires [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-06-17 21:14 Ping Cheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140616163304.GB11091@mail.corp.redhat.com \
--to=benjamin.tissoires@redhat.com \
--cc=dmitry.torokhov@gmail.com \
--cc=killertofu@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pinglinux@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).