updated to recent 3.0 kernel (oneiric ubuntu build package) and got some behaviour i would not expect.
Got a Samsung P35 Notebook - pressing my "backlight" Key does give this in dmesg:
keyboard: can't emulate rawmode for keycode 240
On and Off, both a mesage.
The native resolution is 1400x1050 of my LVDS Panel.
[ 23.577259] [drm] Panel ID String: Samsung LTN150P1-L02
[ 23.577264] [drm] Panel Size 1400x1050
But after pressing backlight twice (off+on) my screen resolution does change to 1600x1024 - afaik not supported, at least it is not mentioned in Xorg.0.log for detected valid panel Modelines.
But it does use this mode after backlight switch:
(II) RADEON(0): Allocate new frame buffer 1600x1024 stride 1600
I wonder why?
However i am forced to switch my resolution back everytime - don't know if its good for the panel to use this resolution (because i don't know if it will blast my panel away i'll set prio to high - if this won't going to happen please set it back to normal ;-) ).
Bug or Feature? Both (message and resolution change) did not happen with 2.6.32.x before, so i guess its a regression, is it?
Tell me if you need more input or kernel testing.
I am able to select 1600x1024 in 2.6.32.x manually in screen resolution tool if this is of interest.
But i want to use my native resolution, 1400x1050 is selected as default and this res. does stay when pressing backlight switch, tested more than 4 times now. The message about the keycode is also gone.
Sounds like some script/daemon is listening for hotkey events and trying to change the mode with xrandr. Please attach your xorg log and config, xrandr --verbose output and dmesg output.
Config is all autodetect, got no xorg.conf. I am attaching 2.6.32 ones and 3.0 ones. Commented Xorg.0.log-* with my "on"/"off" toggles.
The interesting thing is - this error seems to be a little bit random - sometimes the on resolution is ok, sometimes its wrong - but i guess i should not try to understand because you are the expert and have the knowledge ;). Hope the logs helps.
Created attachment 67742 [details]
xrandr output 2.6.32.x
Created attachment 67752 [details]
xrandr output 3.0
Created attachment 67762 [details]
Created attachment 67772 [details]
Additional Info - these ones are not generated via Fn+Backlight Switch but are caused by Fn+F2 (Battery Info); so this has nothing to do with this task - don't know if i should open another task for those ones or to ignore ...
[ 736.991529] kbd_keycode: 48 callbacks suppressed
[ 736.991540] keyboard: can't emulate rawmode for keycode 240
[ 736.991567] keyboard: can't emulate rawmode for keycode 240
[ 747.397902] keyboard: can't emulate rawmode for keycode 240
[ 747.397933] keyboard: can't emulate rawmode for keycode 240
Created attachment 67782 [details]
Created attachment 67792 [details]
Looks like some program is listening for hotkey events and trying to
change the mode with xrandr. Older xservers used to add 1600x1024 mode by default so that's probably where the mode is coming from. I'm not sure why that mode is getting picked when you hit the backlight key, but it's not something the driver handles. The driver does not listen for hotkey events. You'll have to find out what program is handling the hotkey events on your system. This doesn't look like a driver bug.
Hm grepped my system - no one seems to listen for that event.
To confirm this theory i did this:
mv /usr/bin/xrandr > /usr/bin/xrandr.dist
and replaced the xrandr with:
echo "Called" >> /tmp/xrandr.out
Pressing the backlight key there is no xrandr.out in tmp -> no one called the tool.
Any other things to look for or to try?
The porgram may be talking randr directly to the Xserver. What happens if you hit the button when X isn't running (i.e., just console)?
Oh didn't know this may be possible, my fault, sorry.
If X console is not active all seems to work find - resolution stays the same, so it seems to be a Xorg only problem.
Do you have any hints, docs links or tipps how to find the "one" who talks to the Xserver to know to whom to report this issue - the kernel seems to be the false place, sorry for this false report - but didn't know better and it seems only to be a issue in kernel 3.0 - 2.6.32.x did not have the issue afaik - so to me it seemed to be the new kernel ;-) - sorry; btw thx for input and help - guess can be marked as invalid.
No worries, it can get confusing. Unfortunately, I'm not that familiar with how each desktop environment handles hotkeys.