Hi Mattia, hi all,
(please keep me in Cc)
when switching from 2.6.36 to 2.6.37-rc1(+git) I realize that I cannot
adjust the backlight anymore. Before this was possible with the
Fn-F5 and Fn-F6 keys, but now nothing happens.
acpi_listen does not issue anything when these keys are pressed.
Is there any obvious oversight from my side?
config is attached.
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
CONG (n.)
Strange-shaped metal utensil found at the back of the saucepan
cupboard. Many authorities believe that congs provide conclusive proof
of the existence of a now extinct form of yellow vegetable which the
Victorians used to boil mercilessly.
--- Douglas Adams, The Meaning of Liff
On Thu, Nov 04, 2010 at 11:29:15PM +0900, Norbert Preining wrote:
> Hi Mattia, hi all,
>
> (please keep me in Cc)
>
> when switching from 2.6.36 to 2.6.37-rc1(+git) I realize that I cannot
> adjust the backlight anymore. Before this was possible with the
> Fn-F5 and Fn-F6 keys, but now nothing happens.
It's ages sony_laptop doesn't change, it may be some other change in the
acpi layer that causes this.
> acpi_listen does not issue anything when these keys are pressed.
How about the input layer? /proc/acpi/event is deprecated and you should
not rely on that.
But anyway, it's a Fn key issue, not backlight control itself, right?
Can you change brightness echoing to the sysfs files directly?
> Is there any obvious oversight from my side?
don't know, can you bisect it?
> config is attached.
can you attach dmesg output after loading sony_laptop with debug=1 and
pressing the brightness keys?
--
mattia
:wq!
On Mi, 10 Nov 2010, Mattia Dongili wrote:
> It's ages sony_laptop doesn't change, it may be some other change in the
> acpi layer that causes this.
Seems so that the sys files have changed to new locations:
/sys/devices/virtual/backlight/acpi_video0/brightness
(mind the additional "virtual")
as well as thermal zone etc etc.
Could that explain the problem?
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
CAARNDUNCAN (n.)
The high-pitched and insistent cry of the young female human urging
one of its peer group to do something dangerous on a cliff-edge or
piece of toxic waste ground.
--- Douglas Adams, The Meaning of Liff
On Fri, Nov 12, 2010 at 08:50:00AM +0900, Norbert Preining wrote:
> On Mi, 10 Nov 2010, Mattia Dongili wrote:
> > It's ages sony_laptop doesn't change, it may be some other change in the
> > acpi layer that causes this.
>
> Seems so that the sys files have changed to new locations:
> /sys/devices/virtual/backlight/acpi_video0/brightness
>
> (mind the additional "virtual")
> as well as thermal zone etc etc.
>
> Could that explain the problem?
Only if you have some wonderfully badly written software. What are you
using to control the backlight? Also, I'd note that in this case your
backlight is controlled via ACPI, not sony-laptop.
--
Matthew Garrett | [email protected]
On Fr, 12 Nov 2010, Matthew Garrett wrote:
> > Seems so that the sys files have changed to new locations:
> > /sys/devices/virtual/backlight/acpi_video0/brightness
> >
> > (mind the additional "virtual")
> > as well as thermal zone etc etc.
> >
> > Could that explain the problem?
>
> Only if you have some wonderfully badly written software. What are you
> using to control the backlight? Also, I'd note that in this case your
> backlight is controlled via ACPI, not sony-laptop.
Ah right, yes, so probabyl sony-laptopt has nothing to do with it.
THen the problem is simply that the acpi events are not coming through
when pressing the respective keys.
But *that* might be part of the sony-laptop kernel module?
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
TREWOFFE (n.)
A very thick and heavy drift of snow balanced precariously on the
edge of a door porch waiting for what it judges to be the correct
moment to fall. From the ancient Greek legend 'The Treewofe of
Damocles'.
--- Douglas Adams, The Meaning of Liff
On Fri, Nov 12, 2010 at 12:50:27PM +0900, Norbert Preining wrote:
> THen the problem is simply that the acpi events are not coming through
> when pressing the respective keys.
Then yes, that's probably related to sony-laptop. If you run evtest
against the /dev/input/event device that corresponds to sony-laptop,
what events do you get when you hit the brightness keys?
--
Matthew Garrett | [email protected]
On Fr, 12 Nov 2010, Matthew Garrett wrote:
> Then yes, that's probably related to sony-laptop. If you run evtest
> against the /dev/input/event device that corresponds to sony-laptop,
> what events do you get when you hit the brightness keys?
(after playing around to find the right /dev/input/event?)
Event: time 1289535264.900005, type 1 (Key), code 470 (?), value 1
Event: time 1289535264.900013, type 4 (Misc), code 4 (ScanCode), value 10
Event: time 1289535264.900016, -------------- Report Sync ------------
Event: time 1289535264.914232, type 1 (Key), code 470 (?), value 0
Event: time 1289535264.914239, -------------- Report Sync ------------
Event: time 1289535265.415803, type 1 (Key), code 471 (?), value 1
Event: time 1289535265.415827, type 4 (Misc), code 4 (ScanCode), value 11
Event: time 1289535265.415835, -------------- Report Sync ------------
Event: time 1289535265.430214, type 1 (Key), code 471 (?), value 0
Event: time 1289535265.430217, -------------- Report Sync ------------
(pressing brightness down and up, each once)
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
`Time is an illusion. Lunchtime doubly so.'
you should send that in to the
"Reader's Digest". They've got a page for people like you.'
--- Ford convincing Arthur to drink three pints in ten
--- minutes at lunchtime.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
On Fri, Nov 12, 2010 at 03:57:32AM +0000, Matthew Garrett wrote:
> On Fri, Nov 12, 2010 at 12:50:27PM +0900, Norbert Preining wrote:
> > THen the problem is simply that the acpi events are not coming through
> > when pressing the respective keys.
>
> Then yes, that's probably related to sony-laptop. If you run evtest
> against the /dev/input/event device that corresponds to sony-laptop,
> what events do you get when you hit the brightness keys?
backlight (actually Fn+F[56]) is one of those keys the needs remapping
these days, i.e. if xev doesn't get any event in X then you may need
something like:
$ diff -u <(sudo input-kbd 5) vaio-kbd
/dev/input/event5
bustype : BUS_ISA
vendor : 0x104d
product : 0x0
version : 0
name : "Sony Vaio Keys"
bits ev : EV_SYN EV_KEY EV_MSC
map: 44 keys, size: 59/64
--- /proc/self/fd/11 2010-11-12 13:10:39.811178332 +0900
+++ vaio-kbd 2010-10-31 19:24:49.000000000 +0900
@@ -4,8 +4,8 @@
0x0006 = 467 # KEY_FN_F2
0x0007 = 468 # KEY_FN_F3
0x0008 = 469 # KEY_FN_F4
-0x0009 = 470 # KEY_FN_F5
-0x000a = 471 # KEY_FN_F6
+0x0009 = 224 # KEY_BRIGHTNESSDOWN
+0x000a = 225 # KEY_BRIGHTNESSUP
0x000b = 472 # KEY_FN_F7
0x000c = 473 # KEY_FN_F8
0x000d = 474 # KEY_FN_F9
See the manpage for input-kbd and /usr/include/linux/input.h for valid
key values.
In short `input-kbd <devNo>` gives you the current map. Redirect the
output to a file, edit it to change the keys you need remapped and run
`input-kbd -f <file> <devNo>`.
For a reference look at this bug report:
http://bugs.freedesktop.org/show_bug.cgi?id=11227
If the above is not the case then there might be another problem in
sony-laptop as Matthew suggests.
--
mattia
:wq!
On Fr, 12 Nov 2010, Mattia Dongili wrote:
> backlight (actually Fn+F[56]) is one of those keys the needs remapping
> these days, i.e. if xev doesn't get any event in X then you may need
It doesn't.
> $ diff -u <(sudo input-kbd 5) vaio-kbd
> /dev/input/event5
> bustype : BUS_ISA
> vendor : 0x104d
> product : 0x0
> version : 0
> name : "Sony Vaio Keys"
> bits ev : EV_SYN EV_KEY EV_MSC
Ahhhhh
root$ input-kbd 8
/dev/input/event8
protocol version mismatch (expected 65536, got 65537)
and the same for all event devices??
I have input-kbd from xserver-xorg-input-kbd in Debian/sid, which is
at 1:1.4.0-2 version.
Does that mean that 2.6.37rc is too new for the user space?
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
MATCHING GREEN (adj.)
(Of neckties.) Any colour which Nigel Rees rejects as unsuitable for
his trousers or jacket.
--- Douglas Adams, The Meaning of Liff
On Fri, 2010-11-12 at 11:50 +0800, Norbert Preining wrote:
> On Fr, 12 Nov 2010, Matthew Garrett wrote:
> > > Seems so that the sys files have changed to new locations:
> > > /sys/devices/virtual/backlight/acpi_video0/brightness
> > >
> > > (mind the additional "virtual")
> > > as well as thermal zone etc etc.
> > >
I think the /sys/class/thermal/ and /sys/class/backlight/acpi_video0
still exists, right?
we make ACPI video procfs I/F depend on CONFIG_ACPI_PROCFS, which is
cleared by default, in 2.6.36, and removed this I/F in 2.6.37-rc1.
perhaps the backlight control depends on the procfs I/F?
thanks,
rui
> > > Could that explain the problem?
> >
> > Only if you have some wonderfully badly written software. What are you
> > using to control the backlight? Also, I'd note that in this case your
> > backlight is controlled via ACPI, not sony-laptop.
>
> Ah right, yes, so probabyl sony-laptopt has nothing to do with it.
>
> THen the problem is simply that the acpi events are not coming through
> when pressing the respective keys.
>
> But *that* might be part of the sony-laptop kernel module?
>
> Best wishes
>
> Norbert
> ------------------------------------------------------------------------
> Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
> JAIST, Japan TeX Live & Debian Developer
> DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
> ------------------------------------------------------------------------
> TREWOFFE (n.)
> A very thick and heavy drift of snow balanced precariously on the
> edge of a door porch waiting for what it judges to be the correct
> moment to fall. From the ancient Greek legend 'The Treewofe of
> Damocles'.
> --- Douglas Adams, The Meaning of Liff
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Zhang,
On Fr, 12 Nov 2010, Zhang Rui wrote:
> I think the /sys/class/thermal/ and /sys/class/backlight/acpi_video0
> still exists, right?
Yes, right.
> we make ACPI video procfs I/F depend on CONFIG_ACPI_PROCFS, which is
> cleared by default, in 2.6.36, and removed this I/F in 2.6.37-rc1.
> perhaps the backlight control depends on the procfs I/F?
Hmm, I would have expected that the backlight adjustment reacts to the
key sent, as I can use xbacklight by hand, and that is old.
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
ADRIGOLE (n.)
The centrepiece of a merry-go-round on which the man with the tickets
stands unnervingly still.
--- Douglas Adams, The Meaning of Liff
On Fri, Nov 12, 2010 at 01:39:22PM +0900, Norbert Preining wrote:
> On Fr, 12 Nov 2010, Mattia Dongili wrote:
> > backlight (actually Fn+F[56]) is one of those keys the needs remapping
> > these days, i.e. if xev doesn't get any event in X then you may need
>
> It doesn't.
You will need an updated input-kbd to set the scancode map.
> > $ diff -u <(sudo input-kbd 5) vaio-kbd
> > /dev/input/event5
> > bustype : BUS_ISA
> > vendor : 0x104d
> > product : 0x0
> > version : 0
> > name : "Sony Vaio Keys"
> > bits ev : EV_SYN EV_KEY EV_MSC
>
> Ahhhhh
> root$ input-kbd 8
> /dev/input/event8
> protocol version mismatch (expected 65536, got 65537)
> and the same for all event devices??
>
> I have input-kbd from xserver-xorg-input-kbd in Debian/sid, which is
> at 1:1.4.0-2 version.
>
> Does that mean that 2.6.37rc is too new for the user space?
Maybe. Anyway if evtest reacts positively to key presses then it's a
userspace issue and not the driver's.
--
mattia
:wq!
On Fr, 12 Nov 2010, Mattia Dongili wrote:
> You will need an updated input-kbd to set the scancode map.
Ouch.
> > Does that mean that 2.6.37rc is too new for the user space?
>
> Maybe. Anyway if evtest reacts positively to key presses then it's a
> userspace issue and not the driver's.
What is strange that there *WAS* a change in the kernel that triggered
that. Old kernels still work fine. I just tried 2.6.36 and it was working.
I always thought that kernel changes should not break user space
(well, without good reason).
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
Does it worry you that you don't talk any kind of sense?
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
On Tue, Nov 16, 2010 at 02:16:42PM +0900, Norbert Preining wrote:
> On Fr, 12 Nov 2010, Mattia Dongili wrote:
> > You will need an updated input-kbd to set the scancode map.
>
> Ouch.
>
> > > Does that mean that 2.6.37rc is too new for the user space?
> >
> > Maybe. Anyway if evtest reacts positively to key presses then it's a
> > userspace issue and not the driver's.
>
> What is strange that there *WAS* a change in the kernel that triggered
> that. Old kernels still work fine. I just tried 2.6.36 and it was working.
>
> I always thought that kernel changes should not break user space
> (well, without good reason).
it's the same as this:
https://bugzilla.kernel.org/show_bug.cgi?id=23022
--
mattia
:wq!
On Tue, Nov 16, 2010 at 11:18:50PM +0900, Mattia Dongili wrote:
> On Tue, Nov 16, 2010 at 02:16:42PM +0900, Norbert Preining wrote:
> > On Fr, 12 Nov 2010, Mattia Dongili wrote:
> > > You will need an updated input-kbd to set the scancode map.
> >
> > Ouch.
> >
> > > > Does that mean that 2.6.37rc is too new for the user space?
> > >
> > > Maybe. Anyway if evtest reacts positively to key presses then it's a
> > > userspace issue and not the driver's.
> >
> > What is strange that there *WAS* a change in the kernel that triggered
> > that. Old kernels still work fine. I just tried 2.6.36 and it was working.
> >
> > I always thought that kernel changes should not break user space
> > (well, without good reason).
>
> it's the same as this:
> https://bugzilla.kernel.org/show_bug.cgi?id=23022
>
Right, we up-revved evdev protocol version to reflect the fact that it
supports large scancodes but the procotocl is backwards-compatible and
older userspace should have no problems talking with evdev and do
remaps. For example, udev's keymap utility workds just fine here.
Unfortunately input-kbd insists on working with only one version of the
protocol instead if checking if the protocol "at least N". This shoudl
be fixed in input-kbd.
Thanks.
--
Dmitry
Hi Mattia, hi Dmitry,
On Fr, 12 Nov 2010, Mattia Dongili wrote:
> backlight (actually Fn+F[56]) is one of those keys the needs remapping
> these days, i.e. if xev doesn't get any event in X then you may need
> something like:
Ok, I have now done the fllowing:
- recompiled a input-kbd binary with a relaxed version check
- if (EV_VERSION != version) {
+ if (EV_VERSION > version) {
in input.c, line 104 of input-utils.
- created a vaio-kbd from the output of input-kbd and changed the
keys that hat keycode 470 and 471 (those shown in evtest 8)
to key_brightness:
$ diff -u <(./input-kbd 8) vaio-kbd
--- /dev/fd/63 2010-11-17 15:24:32.023696588 +0900
+++ vaio-kbd 2010-11-17 15:24:02.000000000 +0900
@@ -13,8 +13,8 @@
0x0006 = 467 # KEY_FN_F2
0x0007 = 468 # KEY_FN_F3
0x0008 = 469 # KEY_FN_F4
-0x0009 = 470 # KEY_FN_F5
-0x000a = 471 # KEY_FN_F6
+0x0009 = 224 # KEY_BRIGHTNESSDOWN
+0x000a = 225 # KEY_BRIGHTNESSUP
0x000b = 472 # KEY_FN_F7
0x000c = 473 # KEY_FN_F8
0x000d = 474 # KEY_FN_F9
$
remember:
evtest /dev/input/event8 reports code 470 and code 471 for the respective
Fn-F5 and Fn-F6 combinations.
> output to a file, edit it to change the keys you need remapped and run
> `input-kbd -f <file> <devNo>`.
Then I run
$ ./input-kbd -f vaio-kbd 8
/dev/input/event8
map: 44 keys, size: 59/64
parse error: /dev/input/event8
$
with the effect that still brigthness is not working.
If someone can explain what is wrong here and how to get this fixed
that would be nice, because up to now on the sony-vaio mailing list
I heard many complains about disappearing brightness, I hope we can
fix that.
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
SNITTERBY (n.)
Someone who pins snitters (q.v.) on to snitterfields (q.v.) and is
also suspected of being responsible for the extinction of virginstows
(q.v.)
--- Douglas Adams, The Meaning of Liff
> - recompiled a input-kbd binary with a relaxed version check
> - if (EV_VERSION != version) {
> + if (EV_VERSION > version) {
> in input.c, line 104 of input-utils.
Furthermore, although both of you referred to the fact that udev keymap
is working, I checked that Debian/sid uses udev kbd rules, but it
stopped working ...
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
There are of course many problems connected with life, of
which some of the most popular are `Why are people born?'
Why do they spend so much of the
intervening time wearing digital watches?'
--- The Book.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
On Wed, Nov 17, 2010 at 03:33:38PM +0900, Norbert Preining wrote:
> > - recompiled a input-kbd binary with a relaxed version check
> > - if (EV_VERSION != version) {
> > + if (EV_VERSION > version) {
> > in input.c, line 104 of input-utils.
>
> Furthermore, although both of you referred to the fact that udev keymap
> is working, I checked that Debian/sid uses udev kbd rules, but it
> stopped working ...
>
Seems to be working here (I also verified that the keycodces are
actually emitted with evtest):
[root@dtor-d630 ~]# /lib/udev/keymap /dev/input/event3 0x87 wlan
setting scancode 0x87 to key code 238
[root@dtor-d630 ~]# /lib/udev/keymap /dev/input/event3 0x87 battery
setting scancode 0x87 to key code 236
[root@dtor-d630 ~]# uname -r
2.6.37-rc1+
[root@dtor-d630 ~]#
--
Dmitry
On Wed, Nov 17, 2010 at 03:30:06PM +0900, Norbert Preining wrote:
> Hi Mattia, hi Dmitry,
>
> On Fr, 12 Nov 2010, Mattia Dongili wrote:
> > backlight (actually Fn+F[56]) is one of those keys the needs remapping
> > these days, i.e. if xev doesn't get any event in X then you may need
> > something like:
>
> Ok, I have now done the fllowing:
> - recompiled a input-kbd binary with a relaxed version check
> - if (EV_VERSION != version) {
> + if (EV_VERSION > version) {
> in input.c, line 104 of input-utils.
>
> - created a vaio-kbd from the output of input-kbd and changed the
> keys that hat keycode 470 and 471 (those shown in evtest 8)
> to key_brightness:
>
> $ diff -u <(./input-kbd 8) vaio-kbd
> --- /dev/fd/63 2010-11-17 15:24:32.023696588 +0900
> +++ vaio-kbd 2010-11-17 15:24:02.000000000 +0900
> @@ -13,8 +13,8 @@
> 0x0006 = 467 # KEY_FN_F2
> 0x0007 = 468 # KEY_FN_F3
> 0x0008 = 469 # KEY_FN_F4
> -0x0009 = 470 # KEY_FN_F5
> -0x000a = 471 # KEY_FN_F6
> +0x0009 = 224 # KEY_BRIGHTNESSDOWN
> +0x000a = 225 # KEY_BRIGHTNESSUP
> 0x000b = 472 # KEY_FN_F7
> 0x000c = 473 # KEY_FN_F8
> 0x000d = 474 # KEY_FN_F9
> $
>
> remember:
> evtest /dev/input/event8 reports code 470 and code 471 for the respective
> Fn-F5 and Fn-F6 combinations.
>
> > output to a file, edit it to change the keys you need remapped and run
> > `input-kbd -f <file> <devNo>`.
>
> Then I run
> $ ./input-kbd -f vaio-kbd 8
> /dev/input/event8
> map: 44 keys, size: 59/64
> parse error: /dev/input/event8
"Parse error" suggests issue with teh keymap file.
> $
> with the effect that still brigthness is not working.
>
> If someone can explain what is wrong here and how to get this fixed
> that would be nice, because up to now on the sony-vaio mailing list
> I heard many complains about disappearing brightness, I hope we can
> fix that.
>
I did compile input-utils from sid and after fixing up the version issue
I can change mappings on my AT keyboard. Could you try doing the same -
maybe the issue is with the sony-laptop driver (rather its irectaion
with the large scancode support) as well as with input-kbd utility.
Thanks.
--
Dmitry
On Tue, Nov 16, 2010 at 10:52:52PM -0800, Dmitry Torokhov wrote:
> On Wed, Nov 17, 2010 at 03:33:38PM +0900, Norbert Preining wrote:
> > > - recompiled a input-kbd binary with a relaxed version check
> > > - if (EV_VERSION != version) {
> > > + if (EV_VERSION > version) {
> > > in input.c, line 104 of input-utils.
> >
> > Furthermore, although both of you referred to the fact that udev keymap
> > is working, I checked that Debian/sid uses udev kbd rules, but it
> > stopped working ...
> >
>
> Seems to be working here (I also verified that the keycodces are
> actually emitted with evtest):
>
> [root@dtor-d630 ~]# /lib/udev/keymap /dev/input/event3 0x87 wlan
> setting scancode 0x87 to key code 238
> [root@dtor-d630 ~]# /lib/udev/keymap /dev/input/event3 0x87 battery
> setting scancode 0x87 to key code 236
> [root@dtor-d630 ~]# uname -r
> 2.6.37-rc1+
> [root@dtor-d630 ~]#
ok I got the error. I'll see why the EVIOCSKEYCODE syscall is returning
-EINVAL.
--
mattia
:wq!
On Thu, Nov 18, 2010 at 08:04:45PM +0900, Mattia Dongili wrote:
> On Tue, Nov 16, 2010 at 10:52:52PM -0800, Dmitry Torokhov wrote:
> > On Wed, Nov 17, 2010 at 03:33:38PM +0900, Norbert Preining wrote:
> > > > - recompiled a input-kbd binary with a relaxed version check
> > > > - if (EV_VERSION != version) {
> > > > + if (EV_VERSION > version) {
> > > > in input.c, line 104 of input-utils.
> > >
> > > Furthermore, although both of you referred to the fact that udev keymap
> > > is working, I checked that Debian/sid uses udev kbd rules, but it
> > > stopped working ...
> > >
> >
> > Seems to be working here (I also verified that the keycodces are
> > actually emitted with evtest):
> >
> > [root@dtor-d630 ~]# /lib/udev/keymap /dev/input/event3 0x87 wlan
> > setting scancode 0x87 to key code 238
> > [root@dtor-d630 ~]# /lib/udev/keymap /dev/input/event3 0x87 battery
> > setting scancode 0x87 to key code 236
> > [root@dtor-d630 ~]# uname -r
> > 2.6.37-rc1+
> > [root@dtor-d630 ~]#
>
> ok I got the error. I'll see why the EVIOCSKEYCODE syscall is returning
> -EINVAL.
there is a typo in the large scancode support patch. This patch makes
/lib/udev/keymap work again here on 2.6.37-rc2.
commit a33950b5baa848ff7851b9efd4c5e2eaafd370f2
Author: Mattia Dongili <[email protected]>
Date: Thu Nov 18 22:20:36 2010 +0900
Input: fix typo in keycode validation supporting large scancodes
Check the input_keymap_entry keycode size (u32) instead of the device's
(void*).
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=22722
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: Dmitry Torokhov <[email protected]>
Signed-off-by: Mattia Dongili <[email protected]>
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 7f26ca6..5edc41a 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -753,7 +753,7 @@ static int input_default_setkeycode(struct input_dev *dev,
if (index >= dev->keycodemax)
return -EINVAL;
- if (dev->keycodesize < sizeof(dev->keycode) &&
+ if (dev->keycodesize < sizeof(ke->keycode) &&
(ke->keycode >> (dev->keycodesize * 8)))
return -EINVAL;
--
mattia
:wq!
On Thu, Nov 18, 2010 at 10:34:20PM +0900, Mattia Dongili wrote:
> On Thu, Nov 18, 2010 at 08:04:45PM +0900, Mattia Dongili wrote:
> > On Tue, Nov 16, 2010 at 10:52:52PM -0800, Dmitry Torokhov wrote:
> > > On Wed, Nov 17, 2010 at 03:33:38PM +0900, Norbert Preining wrote:
> > > > > - recompiled a input-kbd binary with a relaxed version check
> > > > > - if (EV_VERSION != version) {
> > > > > + if (EV_VERSION > version) {
> > > > > in input.c, line 104 of input-utils.
> > > >
> > > > Furthermore, although both of you referred to the fact that udev keymap
> > > > is working, I checked that Debian/sid uses udev kbd rules, but it
> > > > stopped working ...
> > > >
> > >
> > > Seems to be working here (I also verified that the keycodces are
> > > actually emitted with evtest):
> > >
> > > [root@dtor-d630 ~]# /lib/udev/keymap /dev/input/event3 0x87 wlan
> > > setting scancode 0x87 to key code 238
> > > [root@dtor-d630 ~]# /lib/udev/keymap /dev/input/event3 0x87 battery
> > > setting scancode 0x87 to key code 236
> > > [root@dtor-d630 ~]# uname -r
> > > 2.6.37-rc1+
> > > [root@dtor-d630 ~]#
> >
> > ok I got the error. I'll see why the EVIOCSKEYCODE syscall is returning
> > -EINVAL.
>
> there is a typo in the large scancode support patch. This patch makes
> /lib/udev/keymap work again here on 2.6.37-rc2.
>
Applied, thanks Mattia.
> commit a33950b5baa848ff7851b9efd4c5e2eaafd370f2
> Author: Mattia Dongili <[email protected]>
> Date: Thu Nov 18 22:20:36 2010 +0900
>
> Input: fix typo in keycode validation supporting large scancodes
>
> Check the input_keymap_entry keycode size (u32) instead of the device's
> (void*).
> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=22722
>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Cc: Dmitry Torokhov <[email protected]>
> Signed-off-by: Mattia Dongili <[email protected]>
>
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index 7f26ca6..5edc41a 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -753,7 +753,7 @@ static int input_default_setkeycode(struct input_dev *dev,
> if (index >= dev->keycodemax)
> return -EINVAL;
>
> - if (dev->keycodesize < sizeof(dev->keycode) &&
> + if (dev->keycodesize < sizeof(ke->keycode) &&
> (ke->keycode >> (dev->keycodesize * 8)))
> return -EINVAL;
>
> --
> mattia
> :wq!
--
Dmitry