| Summary: | Keyboard shortcuts calling VBIOS instead of Xorg driver | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Bruno <bonbons> |
| Component: | Driver/intel | Assignee: | zhang rui <rui.zhang> |
| Status: | RESOLVED NOTOURBUG | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | eric, jbarnes, keithp, rui.zhang |
| Version: | unspecified | Keywords: | NEEDINFO |
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | 12440 | ||
| Bug Blocks: | |||
| Attachments: | |||
(In reply to comment #0) > > Would it be possible for X to capture these shortcuts and handle them (instead > of letting the VBIOS do things and eventually confuse X) > hi, This bug actually include two bugs: make X aware of hotkey and screen scales. Let's focus on the hotkey in this bug. We first need to make sure wether these "hotkey" can OS-aware. Would you please do a small experiment: 1) cat /proc/interrupts, put down the number of acpi interrupts. 2) press the "hotkey" 3) cat /proc/interrupts to see if the number increase. please let us know the result. (In reply to comment #1) > We first need to make sure wether these "hotkey" can OS-aware. Would you > please do a small experiment: > 1) cat /proc/interrupts, put down the number of acpi interrupts. > 2) press the "hotkey" > 3) cat /proc/interrupts to see if the number increase. Each such press on the Fujitsu laptop produces exactly 1 ACPI interrupt. After boot the ACPI interrupt count is 0: 9: 0 IO-APIC-fastoi acpi Press Fn + F5 and release 9: 1 IO-APIC-fastoi acpi (same goes for Fn+F10 - output selection, Fn+F[67] - brightness) On the Acer laptop the ACPI interrupts are hard to count on graphical desktop as they increase quite a lot without special activity. It looks though that there key hotkey presses trigger ACPI interrupts and 2-4 per hotkey press. (will check later when booting/shutting down and report more precise values) 9: 11314 XT-PIC-XT acpi FYI, we've got an RFE open for panel scaling improvements, #13505. On the Acer TM660 it's 4 interrupts on key-down, non on key-up (the action being executed on key-down) (In reply to comment #3) > FYI, we've got an RFE open for panel scaling improvements, #13505. Thanks for the pointer Bruno, with latest xkb-config, we should be able to get the key event of these hotkeys to X. The things you need to do now is to bind the key to a specific action, e.g. launch grandr. The screen scaling issue would be tracked in bug# 13505. Frankly, I don't know when we can provide that. it's kind of low priority in our list. Hong, would you please point the place to get the latest xkb-config? thanks. http://freedesktop.org/wiki/Software/XKeyboardConfig This is where I found the latest release 1.1 of xkeyboard-config. (In reply to comment #5) > Bruno, with latest xkb-config, we should be able to get the key event of > these hotkeys to X. The things you need to do now is to bind the key to a > specific action, e.g. launch grandr. > The xkeyboard-config package is installed on my Gentoo box (latest version) Hm, not sure how to make X even see those events... I never see any event for the hotkeys in xev... (the hotkeys still trigger their VBIOS action) Of possible interest, here are the input devices that the kernel lists (Acer TM660): /sys/devices/virtual/input/input0/event0 /sys/devices/virtual/input/input1/event1 /sys/devices/virtual/input/input2/event2 /sys/devices/platform/i8042/serio0/input/input3/event3 /sys/devices/platform/i8042/serio1/input/input4/event4 /sys/devices/LNXSYSTM:00/device:00/PNP0A03:00/LNXVIDEO:00/input/input5/event5 /sys/devices/platform/pcspkr/input/input6/event6 /sys/devices/virtual/input/input0 /sys/devices/virtual/input/input1 /sys/devices/virtual/input/input2 /sys/devices/platform/i8042/serio0/input/input3 /sys/devices/platform/i8042/serio1/input/input4 /sys/devices/LNXSYSTM:00/device:00/PNP0A03:00/LNXVIDEO:00/input/input5 /sys/devices/platform/pcspkr/input/input6 /sys/devices/virtual/input/mice /sys/devices/platform/i8042/serio1/input/input4/mouse0 On the Fujitsu-Siemens S7020 I have: /sys/devices/virtual/input/input0/event0 /sys/devices/virtual/input/input1/event1 /sys/devices/virtual/input/input2/event2 /sys/devices/LNXSYSTM:00/device:00/PNP0A03:00/LNXVIDEO:00/input/input3/event3 /sys/devices/platform/i8042/serio0/input/input4/event4 /sys/devices/platform/i8042/serio4/input/input5/event5 /sys/devices/platform/i8042/serio4/serio5/input/input6/event6 /sys/devices/virtual/input/input0 /sys/devices/virtual/input/input1 /sys/devices/virtual/input/input2 /sys/devices/LNXSYSTM:00/device:00/PNP0A03:00/LNXVIDEO:00/input/input3 /sys/devices/platform/i8042/serio0/input/input4 /sys/devices/platform/i8042/serio4/input/input5 /sys/devices/platform/i8042/serio4/serio5/input/input6 /sys/devices/virtual/input/mice /sys/devices/platform/i8042/serio4/input/input5/mouse0 /sys/devices/platform/i8042/serio4/serio5/input/input6/mouse1 For both according to dmesg event0-event2 are power/sleep/lid buttons. I did try to get Xorg to see the hotkeys, first with original config, later adding the following section: Section "InputDevice" Identifier "ACPIVideo" Driver "evdev" Option "Device" "/dev/input/event3" EndSection To map the event device that appears with ACPI Video kernel module. (Vanilla Kernel 2.6.24-rc8) What am I missing here? Huh, Xorg log shows the following (which would match the expected events): expected keysym, got XF86KbdLightOnOff: line 70 of pc expected keysym, got XF86KbdBrightnessDown: line 71 of pc expected keysym, got XF86KbdBrightnessUp: line 72 of pc expected keysym, got XF86MonBrightnessDown: line 136 of inet expected keysym, got XF86MonBrightnessUp: line 137 of inet expected keysym, got XF86KbdLightOnOff: line 140 of inet expected keysym, got XF86KbdBrightnessDown: line 141 of inet expected keysym, got XF86KbdBrightnessUp: line 142 of inet expected keysym, got XF86KbdLightOnOff: line 70 of pc expected keysym, got XF86KbdBrightnessDown: line 71 of pc expected keysym, got XF86KbdBrightnessUp: line 72 of pc Though this looks like Xorg does not like the way it gets the events and does not forward them... if cat /dev/input/event(whatever) isn't producing anything, then it's a kernel issue, as it's not sending X any input events whatsoever. the errors from comment #8 show that you need to recompile xkbcomp against a newer x11proto, but that alone won't fix your problem. (In reply to comment #9) > if cat /dev/input/event(whatever) isn't producing anything, then it's a > kernel issue, as it's not sending X any input events whatsoever. On both laptops I only get content from /dev/input/event$X (the one for LNXVIDEO) when pressing the key that allows switching output devices. Keys for backlight on/off, center/stretch, brightness do not produce any events. > the errors from > comment #8 show that you need to recompile xkbcomp against a newer x11proto, > but that alone won't fix your problem. Recompiling xkbcomp does not fix anything here... maybe a new release is still pending or has not reached Gentoo yet (In reply to comment #7) > > I did try to get Xorg to see the hotkeys, first with original config, later > adding the following section: > Section "InputDevice" > Identifier "ACPIVideo" > Driver "evdev" > Option "Device" "/dev/input/event3" > EndSection > To map the event device that appears with ACPI Video kernel module. (Vanilla > Kernel 2.6.24-rc8) > > What am I missing here? > hong, how should the user write the xorg.conf file? thanks. (In reply to comment #10) > (In reply to comment #9) > > if cat /dev/input/event(whatever) isn't producing anything, then it's a > > kernel issue, as it's not sending X any input events whatsoever. > On both laptops I only get content from /dev/input/event$X (the one for > LNXVIDEO) when pressing the key that allows switching output devices. Keys for > backlight on/off, center/stretch, brightness do not produce any events. no ACPI events for brightness switch? can you kill acpid and cat /proc/acpi/event and attach the result after pressing brightness up/down hotkeys? Please attach the acpidump output as well. you can download the latest pmtools here: http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ > no ACPI events for brightness switch? > can you kill acpid and cat /proc/acpi/event > and attach the result after pressing brightness up/down hotkeys? On the Acer TM660: There is no output from /proc/acpi/event for brightness hotkeys or backlight on/off hotkey. The Sleep and Output switch hotkeys do trigger output. On the Fujitsu-Siements S7020: There is no output from /proc/acpi/event for brightness hotkeys or mode-center/stretch hotkey. The Output switch hotkey does trigger output. > Please attach the acpidump output as well. > you can download the latest pmtools here: > http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ > acpi-dumps will follow soon, one for each laptop. (generated with pmtools-20071116's acpidump, "acpidump -b") Created attachment 13882 [details]
"acpidump -b" output for Acer TM660
Created attachment 13883 [details]
"acpidump -b" output for Fujitsu-Siemens S7020
(In reply to comment #13) > acpi-dumps will follow soon, one for each laptop. (generated with > pmtools-20071116's acpidump, "acpidump -b") could you re-generate the acpidump output without any parameter please? (In reply to comment #13) > > no ACPI events for brightness switch? > > can you kill acpid and cat /proc/acpi/event > > and attach the result after pressing brightness up/down hotkeys? > On the Fujitsu-Siements S7020: > There is no output from /proc/acpi/event for brightness hotkeys or > mode-center/stretch hotkey. > The Output switch hotkey does trigger output. (In reply to comment #2) > (In reply to comment #1) > > We first need to make sure wether these "hotkey" can OS-aware. Would you > > please do a small experiment: > > 1) cat /proc/interrupts, put down the number of acpi interrupts. > > 2) press the "hotkey" > > 3) cat /proc/interrupts to see if the number increase. > Each such press on the Fujitsu laptop produces exactly 1 ACPI interrupt. > After boot the ACPI interrupt count is 0: > 9: 0 IO-APIC-fastoi acpi > Press Fn + F5 and release > 9: 1 IO-APIC-fastoi acpi > (same goes for Fn+F10 - output selection, Fn+F[67] - brightness) So there are ACPI interrupts but no output from /proc/acpi/event for brightness hotkeys or mode-center/stretch hotkeys, right? Is this also true for acer laptop? Are there any ACPI interrupts increases if pressing brightness hotkeys or backlight on/off hotkey? In order to make this clear, bruno, will you please set CONFIG_ACPI_DEBUG and do the following test? 1.dmesg -c; 2.echo 0x04 > /sys/module/acpi/parameters/debug_layer; 3.echo 0x8800001f > /sys/module/acpi/parameters/debug_level; 4.press the hotkeys you want to check; 5.attach the dmesg output. Created attachment 13906 [details]
acpidump output for Fujitsu-Siemens S7020
This time calling acpidump without any parameter
Created attachment 13908 [details] dmesg output for Fujitsu-Siemens S7020 (with hotkey info) For Fujitsu-Siemens S7020 (In reply to comment #17) > So there are ACPI interrupts but no output from /proc/acpi/event for > brightness hotkeys or mode-center/stretch hotkeys, right? > Are there any ACPI interrupts increases if pressing brightness hotkeys > or backlight on/off hotkey? Exact, all hotkeys do produce exactly one ACPI interrupt per press. The only hotkey to produce output on /proc/acpi/event or sending keycodes (also visible with showkey from console: keycode 227 press keycode 227 release Those key events show up with some delay though) > In order to make this clear, bruno, will you please set CONFIG_ACPI_DEBUG > and do the following test? > 1.dmesg -c; > 2.echo 0x04 > /sys/module/acpi/parameters/debug_layer; > 3.echo 0x8800001f > /sys/module/acpi/parameters/debug_level; > 4.press the hotkeys you want to check; > 5.attach the dmesg output. Attached is the dmesg output, split in 3 blocks prefixed with list of keys pressed (hotkey + description) Running kernel linux-2.6.24-rc8-git7 for the test with enabled CONFIG_ACPI_DEBUG Created attachment 13909 [details]
acpidump output for Acer TM660
This time calling acpidump without any parameter
Created attachment 13913 [details] dmesg output for Acer TM660 (with hotkey info) For Acer TM660 (In reply to comment #17) > So there are ACPI interrupts but no output from /proc/acpi/event for > brightness hotkeys or mode-center/stretch hotkeys, right? > Are there any ACPI interrupts increases if pressing brightness hotkeys > or backlight on/off hotkey? All hotkeys EXCEPT backlight on/off produce 2 ACPI interrupts per press. The only hotkey to produce output on /proc/acpi/event or sending keycodes (also visible with showkey from console: keycode 227 press keycode 227 release Those key events show up with some no delay) Backlight on/off hotkey does not produce any acpi interrupt. > In order to make this clear, bruno, will you please set CONFIG_ACPI_DEBUG > and do the following test? > 1.dmesg -c; > 2.echo 0x04 > /sys/module/acpi/parameters/debug_layer; > 3.echo 0x8800001f > /sys/module/acpi/parameters/debug_level; > 4.press the hotkeys you want to check; > 5.attach the dmesg output. Attached is the dmesg output, split in 3 blocks prefixed with list of keys pressed (hotkey + description) Running kernel linux-2.6.24-rc8-git7 for the test with enabled CONFIG_ACPI_DEBUG As you will see, no single line of output for backlight on/off hotkey. Note that there may be more ACPI debug messages than just those triggered by the hotkeys, at some interval ACPI interrupts get triggered automagically (don't know what they do/come from... maybe THEMAL monitoring or FAN control?) What's also surprising is that those extra acpi interrupts seem to happen less often with 2.6.24-rc8-git7 than when doing the last test and hotkeys only produce 2 interrupts instead of 4 previously (not sure what kernel it was back then, maybe 2.6.24-rc6) By reading the acpidump, the fujitsu laptop doesn't support the ACPI video extension. output switch events can go via ACPI video device, while this is not true for the brightness switch and mode-center/stretch hotkeys. The notifications are sent to some Fujitsu specifice devices. So for the two problems described in comment #0: 1. in order to send the hotkey to user space, we need a platform specific driver to handle these devices and events. Maybe something like the patch here: http://marc.info/?l=linux-acpi&m=118837125321242&w=2 (This one doesn't work for you in this case) 2. stop the VBIOS from doing things and eventually confusing X. Well, this is done in the AML code, which Linux/ACPI is not aware of. Maybe there are some ACPI methods for enable/disable the VBIOS action upon hotkey events. But as they don't follow the ACPI video extension. I don't know what to do with this. :( For the acer laptop, the similar problem. ACPI video extension is not supported. And the AML code invokes VBIOS to change the brightness level. IMO, there is no way to prevent the VBIOS action upon brightness switch hotkey events unless upgrading the BIOS. The brightness being controlled by the BIOS/ACPI in background is not so much of a problem (the laptop extras driver for Fujitsu Siemens in 2.6.24 allows interacting with the Fujitsu extension to set/querry brightness) No idea if there is an equivalent for the Acer laptop... The Center/Stretch hotkey is more of a problem as Xorg's programming of video modes is not compatible with what ACPI expects. (X does not seem to suffer directly from it, but results on display are broken) So it seems that it would be the "special module"'s responsibility to throw the key stroke out as to input layer. Neither X nor ACPI can help detecting the key event here. I'll mark this bug as NOTOURBUG. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Since 2.x.x series the Xorg driver attempts to program more of the graphics by itself without using the VBIOS. On most laptops there are shortcut key (Fn+Fx) that trigger some VBIOS action (output selection, backlight on/off, backlight brightness control, scaling/centering when running at non-native modes) On the two laptops I have access to (Acer TM660 and Fujitsu-Siemens S7020) the VBIOS centers the mode it programs on display when using non-native mode (can be configured at least under Windows), on the Fujitsu-Siemens there is also a keyboard shortcut that switches between centered and scaled. When running vesa Xorg driver this key produces the expected results - running with Xorg with 2.x.x intel driver I get the following: - running at mode that was set via VESA (framebuffer) behavior is correct (1280x1024 in my case as VESA does not seem to see native 1400x1050) - running at larger mode: (native 1400x1050) mode gets broken (1280x1024 is scaled/centered, cursor moving below bottom-right corner of monitor) - running at smaller mode: mode gets "enlarged" to 1280x1024 and this enlarged mode gets scaled/centered (the X mode starting at top-left corner of 1280x1024 area) e.g. centered result (when scaled M+R area fills whole display) BBBBBBBBBBBBBBBBBB BBBMMMMMMMRRRRRBBB BBBMMMMMMMRRRRRBBB BBBMMMMMMMRRRRRBBB BBBRRRRRRRRRRRRBBB BBBBBBBBBBBBBBBBBB B = black M = Xorg dotted background (area where cursor can mode) R = either black or Xorg dotted background Regarding centered/scaled display: X should properly calculate the DPI for both cases when display size is known. (adding dependency on bug #12440 for this). This applies to any LCD/TFT monitor (CRTs are never centered as far as I know) Would it be possible for X to capture these shortcuts and handle them (instead of letting the VBIOS do things and eventually confuse X)