headers
Jerone Young | 3 Jan 2010 08:39
Favicon

[PATCH] Add support for special function keys for Lenovo Thinkpad USB Keyboard with Tracepoint

Add support for special function keys on Lenovo Thinkpad USB Keyboard
Tracepoint.

    - VoIP hotkey "FN+F6" is mapped to camera, and may need to change
      if there is a standard VoIP hotkey defined.
    - Mute Microphone key has not been defined, as there is no
      standard key defined for it yet.

    Signed-off-by: Jerone Young <jerone.young <at> canonical.com>

diff --git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index d123c10..33633f6 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
 <at>  <at>  -21,6 +21,7  <at>  <at>  LABEL="keyboard_usbcheck"

 ENV{ID_VENDOR}=="Logitech*", ATTRS{name}=="Logitech USB Multimedia Keyboard", RUN+="keymap $name logitech-wave"
 ENV{ID_VENDOR}=="Logitech*", ATTRS{name}=="Logitech USB Receiver", RUN+="keymap $name logitech-wave-cordless"
+ENV{ID_VENDOR}=="Lite-On_Technology_Corp*", ATTRS{name}=="Lite-On Technology Corp. ThinkPad
USB Keyboard with TrackPoint", RUN+="keymap $name lenovo-thinkpad-usb-keyboard-trackpoint"

 GOTO="keyboard_end"

diff --git a/extras/keymap/keymaps/lenovo-thinkpad-usb-keyboard-trackpoint b/extras/keymap/keymaps/lenovo-thinkpad-usb-keyboard-trackpoint
new file mode 100644
index 0000000..e332596
--- /dev/null
+++ b/extras/keymap/keymaps/lenovo-thinkpad-usb-keyboard-trackpoint
 <at>  <at>  -0,0 +1,13  <at>  <at> 
+0x90012 screenlock # Fn+F2
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Pitt | 3 Jan 2010 11:43
Favicon
Gravatar

Re: [PATCH] Add support for special function keys for Lenovo Thinkpad USB Keyboard with Tracepoint

Hello Jerone,

Jerone Young [2010-01-03  1:39 -0600]:
> Add support for special function keys on Lenovo Thinkpad USB Keyboard
> Tracepoint.

Thanks! Applied to master (with adding the new file to Makefile.am)

Martin
--

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
X O R | 4 Jan 2010 14:30
Picon
Favicon

udev rules and noflushd

Hello,

I have Debian router. With noflushd and tmpfs I was able to spin down the hard disk completely. Now with the
recent versions of udev I am unable to do that :(

I am using echo 1 > /proc/sys/vm/block_dump to check which process is waking up the hard drive. After
several minutes of disk inactivity I can hear my disk is spinning down, then immediately it spins up again.
In logs I can see the cause of that is blkid, in particular this rule from 60-persistent-storage.rules:

KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"

First I was able to solve that by commenting the line. But if I (or some update) do update-initramfs system
becomes unbootable. I guess this rule is used (by grub2) to detect hard disks at boot. 

So I was doing this.

1. Comment the rule
2. /etc/init.d/udev restart
3. Uncomment rule

But with recent update it seems that udev is reading rules on the fly. There is no need to restart the service.
So as soon as I change the rule to "uncommented", udev "sees" that change and makes my hard drive to be unable
to spin down. 

Please help

      
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dan Nicholson | 4 Jan 2010 15:33
Picon

Re: udev rules and noflushd

On Mon, Jan 4, 2010 at 5:30 AM, X O R <imperia777 <at> yahoo.com> wrote:
> Hello,
>
> I have Debian router. With noflushd and tmpfs I was able to spin down the hard disk completely. Now with the
recent versions of udev I am unable to do that :(
>
> I am using echo 1 > /proc/sys/vm/block_dump to check which process is waking up the hard drive. After
several minutes of disk inactivity I can hear my disk is spinning down, then immediately it spins up again.
> In logs I can see the cause of that is blkid, in particular this rule from 60-persistent-storage.rules:
>
>
> KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
>
> First I was able to solve that by commenting the line. But if I (or some update) do update-initramfs system
becomes unbootable. I guess this rule is used (by grub2) to detect hard disks at boot.
>
> So I was doing this.
>
> 1. Comment the rule
> 2. /etc/init.d/udev restart
> 3. Uncomment rule
>
> But with recent update it seems that udev is reading rules on the fly. There is no need to restart the
service. So as soon as I change the rule to "uncommented", udev "sees" that change and makes my hard drive to
be unable to spin down.

I'm not sure the correct solution, but adding ACTION=="add" in that
rule may limit it to only bootup. What's happening now is that
spinning down the disk is causing a uevent to be triggered by the
kernel, but it's a change event rather than an add event. The right
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kay Sievers | 4 Jan 2010 16:28

Re: udev rules and noflushd

On Mon, Jan 4, 2010 at 14:30, X O R <imperia777 <at> yahoo.com> wrote:
> Hello,
>
> I have Debian router. With noflushd and tmpfs I was able to spin down the hard disk completely. Now with the
recent versions of udev I am unable to do that :(

noflushd probably opens the device writable, which causes udev to
re-check it after possible changes. It should probably just read the
device read-only, and prevent that behavior.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Clemens Buchacher | 4 Jan 2010 17:18
Picon

Re: Bug#561711: udev: Samsung R70/R71 keymap

Hi,

Please add me to Cc. I did not receive any notification about my bug report
and I'm responding now only because I found this in the list archives by
accident.

On Mon, Dec 21, 2009 at 09:25:40AM +0100, Martin Pitt wrote:

> > Fn+F5 (blank screen) and Fn+F8 still do not generate events after
> > this change, howver.
> 
> Seems worth exercising README.keymap.txt for those two then?

/lib/udev/keymap correctly reported the keypress events, but xev did not.
echo 166-245 > /sys/devices/platform/i8042/serio0/force_release finally
fixed the problem. Is there any way to diagnose this issue without trial and
error? Maybe we should include a hint in README.keymap.txt.

It was a real pain to debug this, especially since I didn't even know where
to look, and google returns tons of misleading bug reports concering hal.
I'm afraid README.keymap.txt is the last place that people find. I have no
idea what to do about it though.

I suppose something like the following patch should fix the problem
permanently. Unfortunately, I was unable to test this, because the debian
package would not build with the new source code (rejected patches and other
issues), and after installing udev from git the kernel hangs at boot,
without leaving any traces in syslog.

Cheers,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Martin Pitt | 5 Jan 2010 09:58
Favicon
Gravatar

Re: Bug#561711: udev: Samsung R70/R71 keymap

Hello Clemens,

Clemens Buchacher [2010-01-04 17:18 +0100]:
> /lib/udev/keymap correctly reported the keypress events, but xev did not.
> echo 166-245 > /sys/devices/platform/i8042/serio0/force_release finally
> fixed the problem. Is there any way to diagnose this issue without trial and
> error? 

I'm not aware of one. However, on the Samsung NC10 where I tried this
once it helped to switch back and forth to a VT to unbreak X.org and
the stuck key.

> Maybe we should include a hint in README.keymap.txt.

Indeed, I added a note about force-release there now.

> It was a real pain to debug this, especially since I didn't even know where
> to look, and google returns tons of misleading bug reports concering hal.
> I'm afraid README.keymap.txt is the last place that people find. I have no
> idea what to do about it though.

In Ubuntu bug reports we point people to exercise
https://wiki.ubuntu.com/Hotkeys/Troubleshooting, which also points to
that README (if the problem is a missing keymap or force-release
quirk). I guess other distros need to do/are doing something similar.

> I suppose something like the following patch should fix the problem
> permanently.

> -ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*", ATTR{[dmi/id]product_name}=="*N130*",
(Continue reading)

Permalink | Reply | 2 comments |
headers
Clemens Buchacher | 5 Jan 2010 16:51
Picon

Re: Bug#561711: udev: Samsung R70/R71 keymap

Hi Martin,

On Tue, Jan 05, 2010 at 09:58:27AM +0100, Martin Pitt wrote:

> This would be equivalent to doing
> 
>   echo 130,131,132,134,136,137,179,247,249 > /sys/devices/platform/i8042/serio0/force_release
> 
> (which is different to what you wrote originally). Does that work for
> you for all keys?

Good point. Yes, that fixes all keys.

Cheers,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Martin Pitt | 5 Jan 2010 16:57
Favicon
Gravatar

Re: Bug#561711: udev: Samsung R70/R71 keymap

Hello Clemens,

Clemens Buchacher [2010-01-05 16:51 +0100]:
> Good point. Yes, that fixes all keys.

Perfect, thanks for testing. I pushed your patch to udev.

Martin
--

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
Permalink | Reply | 0 comments |
headers
Martin Pitt | 5 Jan 2010 22:36
Favicon
Gravatar

Question about your reversion of the udev Huawei modem rule

Hey Dan,

in [1] you reverted a previous commit [2] to fix the Huawei E1550 GSM
modem in udev (using modem-modeswitch) with the rationale that "other
manufacturers have completely different methods for killing their fake
driver CD". However, the rule was tested on that actual hardware, and
it worked fine.

I'm interested in why this rule was bad, and what should be done
instead?

Thanks,

Martin

[1] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=8a993fab2f218234f06743bcc127dda61a45711b
[2] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=53842b53820a0f0b2b0ff5b28caf01e3f7e26f22
--

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |

Gmane