From: Soeren Sonnenburg <kernel@nn7.de>
To: Jiri Kosina <jikos@jikos.cz>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
linux-usb-devel <linux-usb-devel@lists.sourceforge.net>
Subject: Re: 2.6.20-rc6 pb_fnmode regression
Date: Mon, 29 Jan 2007 12:24:34 +0100 [thread overview]
Message-ID: <1170069874.13904.29.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.0701291202230.9448@twin.jikos.cz>
On Mon, 2007-01-29 at 12:13 +0100, Jiri Kosina wrote:
> On Mon, 29 Jan 2007, Jiri Kosina wrote:
>
> > Ah, now I see. The problem is that in pre-2.6.20-rc1 the pb_fnmode was
> > setting global variable, but after the HID layer rework, this is a
> > per-hid variable, which is of course not updated when write to sysfs
> > triggers. I will try to fix this before I send 2.6.20-rc6 updates to
> > Linus, thanks for pointing this out.
>
> Actually the cleanest solution would be when I change the code in such a
> way that pb_fnmode parameter would be passed to hid instead of usbhid
> module, as this is where the input mapping is being done (you could
> potentially have a keyboard which needs the very same handling of fn mode
> as usb powerbook keyboards currently have, but on different transport
> - input mapping is logically transport independent).
>
> But I guess you will be not OK with breaking the backward compatibility in
> such way, because all the already existing tutorials, etc. right?
That sounds good for me. Breaking with what was there is not a problem
as long as this feature is still there, it can be done in a more clean
way this way, and the new /sys/foo/bar path is documented (basically
people nowadays expect slight user interface changes between kernel
versions).
> Would warning that would trigger when the module parameter is passed to
> usbhid and would instruct user to pass the parameter to hid module
> instead, be acceptable? (and then changing the parameter of hid module
> through sysfs would work as expected again).
I guess this warning is not too useful, except if it is triggered on
echo >/sys/*/pb_fnmode too (which I suspect is what most people do).
Soeren
--
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.
next prev parent reply other threads:[~2007-01-29 11:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-27 13:29 2.6.20-rc6 pb_fnmode regression Soeren Sonnenburg
2007-01-29 9:55 ` Jiri Kosina
2007-01-29 10:26 ` [linux-usb-devel] " Sergey Vlasov
2007-01-29 10:32 ` Soeren Sonnenburg
2007-01-29 10:40 ` Jiri Kosina
2007-01-29 11:13 ` Jiri Kosina
2007-01-29 11:24 ` Soeren Sonnenburg [this message]
2007-01-29 11:45 ` Jiri Kosina
2007-01-29 15:12 ` Soeren Sonnenburg
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=1170069874.13904.29.camel@localhost \
--to=kernel@nn7.de \
--cc=jikos@jikos.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
/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.