Bug description: when my screen want to turn off (dpms) - It can't because as soon as screen turn off, someone generate a keycode 232, and X server wakeup i try to put screen off by $ xset dpms force off and still have the same situation! but if make a # vbetool dpms off it turn off and being black until # vbetool dpms on it begins with 2.6.29 kernel System environment: -- chipset: 945GMS -- system architecture: 32-bit -- xf86-video-intel: git a92bbcc9490468e7709b3ddaad82bc04607af26 -- xserver: 1.6.3.901 -- mesa: git ae2daacbac7242938cffe0e2409071e030e00863 -- libdrm: git ac71f0849928f4b2fbb69c01304ac6f9df8916a1 -- kernel: 2.6.31.1 -- Linux distribution: ArchLinux -- Machine or mobo model: MSI Wind U100 -- Display connector: LVDS
Sounds like it's not directly related to the DRM driver. Can you bisect the kernel to find out exactly when this starts happening?
ok, could you specify me a way to find right commit? or what source file need to look for changes?
If you can build your own kernels, you could use 'git bisect' to find the bad commit. 'git help bisect' describes the steps you need to take.
Thanks for "git bisect"! I'm still testing kernel commits (it needs 6 or more tests yet) But now I have a interesting situation: I have a normal screenslep at X and interrupts in console (w/o X). When I set $ setterm -blank 1 $ cat (so system wait for my input) and wait for 1 min. Screen do a on-off cycle and i see ^@^@ in console, cat still run. But haven't touch anything.
Created attachment 30418 [details] git bisect log
so, after days of bisecting, git show me first buggy commit: 9be1df98bca44dbe3769cd22f4ab8122b76c5313 is the first bad commit commit 9be1df98bca44dbe3769cd22f4ab8122b76c5313 Author: Zhang Rui <rui.zhang@intel.com> Date: Thu Jan 8 14:11:30 2009 +0000 bd->props.brightness doesn't reflect the actual backlight level. Always invoke backlight_update_status when users want to change the backlight. For setups where brightness change is an expensive operation, this could be done in the driver rather than the core. http://bugzilla.kernel.org/show_bug.cgi?id=12249 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com> :040000 040000 2694cce1b17fc7459d947663fabec8209a2f58da 62e3058a2a44a029887123626dbaa45b03e23b40 M drivers if I make a $ xrandr --output LVDS --set BACKLIGHT_CONTROL native screensleep works well but but with "^@^@" in pure term still here
Rui, any thoughts here?
xev log: KeyPress event, serial 32, synthetic NO, window 0x1800001, root 0x105, subw 0x0, time 23931912, (-52,31), root:(582,246), state 0x0, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 32, synthetic NO, window 0x1800001, root 0x105, subw 0x0, time 23931912, (-52,31), root:(582,246), state 0x0, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 32, synthetic NO, window 0x1800001, root 0x105, subw 0x0, time 23932781, (-52,31), root:(582,246), state 0x0, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 32, synthetic NO, window 0x1800001, root 0x105, subw 0x0, time 23932781, (-52,31), root:(582,246), state 0x0, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False
more info about MSI's BIOS https://bugs.launchpad.net/ubuntu/+source/hal-info/+bug/415023/comments/80
Rui or Yakui, any ideas?
xrandr --output LVDS --set BACKLIGHT_CONTROL legacy work well too
(clear NEEDINFO) Rui? Yakui?
Created attachment 34909 [details] read the input event please first attach the output of "grep . /sys/class/input/input*/*". and then do this test, 1. gcc read-input-event.c 2. sudo ./a.out /dev/input/eventX (X = {0, 1, ..., the maximum event index in /dev/inpout/ }) 3. switch off the display 4. watch if there is any output the screen comes back, if yes, please attach the output so that we can know which input device generates this event.
please attach the acpidump as well.
Created attachment 34919 [details] result of "grep . /sys/class/input/input*/*"
Created attachment 34920 [details] ACPI Dump MSI Wind U100 (Roverbook Neo U100L)
there is no output of read-input-event.c from any /dev/input/event[0123456789]
oh sorry, I missed event1 ;) $ sudo ./a.out /dev/input/event1 event[1] type 0004, code 0004, value 00000247 event[1] type 0001, code 0224, value 00000001 event[1] type 0000, code 0000, value 00000000 event[1] type 0004, code 0004, value 00000247 event[1] type 0001, code 0224, value 00000000 event[1] type 0000, code 0000, value 00000000 event[1] type 0004, code 0004, value 00000247 event[1] type 0001, code 0224, value 00000001 event[1] type 0000, code 0000, value 00000000 event[1] type 0004, code 0004, value 00000247 event[1] type 0001, code 0224, value 00000000 event[1] type 0000, code 0000, value 00000000 ^c $
the event is sent from atkb driver... I don't see why 9be1df98bca44dbe3769cd22f4ab8122b76c5313 introduces this problem. would you please verify if the problem still exists after reverting this commit?
the parent of 9be1df98bca44dbe3769cd22f4ab8122b76c5313 is 0ec561f4b648260a46ace87acbc558241808455f so I will try this If I'm wrong -- please correct me
Sounds like an input or ACPI problem, if you still have this issue please re-file at bugzilla.kernel.org against the input layer or send a note to lkml.
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.