From: "Pali Rohár" <pali.rohar@gmail.com>
To: Darren Hart <dvhart@infradead.org>
Cc: Alex Hung <alex.hung@canonical.com>,
Matthew Garrett <mjg59@srcf.ucam.org>,
platform-driver-x86@vger.kernel.org,
Gabriele Mazzotta <gabriele.mzt@gmail.com>
Subject: Re: New dell-wireless driver
Date: Sun, 23 Nov 2014 01:52:46 +0100 [thread overview]
Message-ID: <201411230152.46619@pali> (raw)
In-Reply-To: <20141122020906.GB24951@vmdeb7>
[-- Attachment #1: Type: Text/Plain, Size: 3711 bytes --]
On Saturday 22 November 2014 03:09:06 Darren Hart wrote:
> On Sat, Nov 22, 2014 at 11:45:08PM +0100, Pali Rohár wrote:
> > Hello,
> >
> > I saw dell-wireless driver on platform-driver-x86
> > mailinglist [1] which using DELLABCE acpi device and I do
> > not like some parts in this driver.
>
> Hi Pali,
>
> Thanks for reviewing and speaking up :)
>
> > First is that this driver export rfkill event as keypress
> > which is also reported to userspace by keyboard controller.
> > So then userspace receive two rfkill keypresses.
>
> Alex, can you comment? Does the keyboard controller also see
> this event?
>
Yes on my laptop E6440. But it looks like it does not have to be
truth for all laptops...
> > Second is that DELLABCE acpi device can also control "soft"
> > rfkill status and this driver does not enable it because it
> > use input class instead rfkill.
> >
> > Anyway I have unfinished my version of DELLABCE acpi driver
> > which will use rfkill interface and plus allow to use hw
> > switch events in dell-laptop.ko driver.
>
> Is this something that could be applied incrementally fo
> Alex's driver, or is it something we'd be best starting over
> with?
>
Alex's driver is different. It registers input device. My
approach register rfkill device plus add exported functions for
registering atomic notifier (so other drivers like dell-laptop
can use events too).
First we need to know if input driver is really needed. And if
yes determinate in which conditions and for which laptops. Really
duplicate key press are not good.
In case when input driver is really needed I can just copy
relevant input code and add it into my driver (in case when my
driver will be used instead Alex's). This could be no problem,
because my and Alex code doing different things and so could
coexist in one driver (but cannot be split into more because only
one acpi driver can handle one acpi device).
> We have some precedent for input drivers (there is one nearly
> identical to the dell driver for hp, also by Alex). Using
> rfkill does seem like the better approach without digging
> into it.
>
It is different from HP. Dell ACPI device on some machines can
also control wifi switches (it can enable/disable it!).
So it make sense to use rfkill. But on some machines that ACPI
device can only receive events that HW switch was switched, but
it is possible to ask for state (if is enabled or not). HP driver
just report switch was changed, but does not report if is enabled
or disabled.
So I think HP is not identical to this Dell one.
> > Currently dell-laptop.ko driver is using i8042 hook function
> > for detecting hw switch key press event. It is needed to
> > detect if rfkill state was changed or not.
> >
> > My prepared patches for dell-laptop.ko allows to use acpi
> > event from DELLABCE driver, so i8042 hook function can be
> > dropped. Really it is not good idea to pass every PS/2 data
> > from both keyboard, touchpad and trackpoint to dell-laptop
> > driver and if there is alternative (DELLABCE) it is better
> > to use it.
> >
> > But now I would like to hear what do you think about it.
> >
> > Because only one kernel driver can attach to DELLABCE acpi
> > device, I cannot use new dell-wireless driver. And I think
> > only one driver can hit mainline kernel.
>
> I would like to see your patch, it sounds like it might be a
> better option.
Ok, I will sent patches. There are some problems which I'm trying
to fix together with Gabriele. Do you need to see patches now, or
can you wait some time until we fix it?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2014-11-23 0:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-22 22:45 New dell-wireless driver Pali Rohár
2014-11-22 2:09 ` Darren Hart
2014-11-23 0:52 ` Pali Rohár [this message]
2014-11-22 3:44 ` Darren Hart
2014-11-23 15:11 ` Pali Rohár
2014-11-27 4:41 ` Alex Hung
2014-12-02 11:06 ` Gabriele Mazzotta
2014-12-02 12:01 ` Pali Rohár
2014-12-02 15:08 ` Gabriele Mazzotta
2014-12-03 8:50 ` Darren Hart
2014-12-04 6:52 ` Alex Hung
2014-12-04 9:57 ` Pali Rohár
2014-11-27 4:27 ` Alex Hung
2014-11-27 11:43 ` Pali Rohár
2014-11-28 5:33 ` Alex Hung
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=201411230152.46619@pali \
--to=pali.rohar@gmail.com \
--cc=alex.hung@canonical.com \
--cc=dvhart@infradead.org \
--cc=gabriele.mzt@gmail.com \
--cc=mjg59@srcf.ucam.org \
--cc=platform-driver-x86@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.