Bug 40622

Summary:	[radeon] - kms wrong resolution mode used after backlight on/off switch
Product:	Drivers	Reporter:	Torsten Krah (krah.tm)
Component:	Video(DRI - non Intel)	Assignee:	drivers_video-dri
Status:	RESOLVED OBSOLETE
Severity:	high	CC:	alan, alexdeucher
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	3.0	Subsystem:
Regression:	Yes	Bisected commit-id:
Attachments:	xrandr output 2.6.32.x xrandr output 3.0 dmesg 2.6.32 dmesg 3.0 Xorg.0.log 2.6.32 Xorg.0.log 3.0

Description Torsten Krah 2011-08-05 20:10:27 UTC

Hi,

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.

Comment 1 Torsten Krah 2011-08-05 20:26:42 UTC

Additional Info:

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.

Comment 2 Alex Deucher 2011-08-05 20:33:42 UTC

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.

Comment 3 Torsten Krah 2011-08-06 10:40:09 UTC

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.

Comment 4 Torsten Krah 2011-08-06 10:46:47 UTC

Created attachment 67742 [details]
xrandr output 2.6.32.x

xrandr --verbose

Comment 5 Torsten Krah 2011-08-06 10:51:25 UTC

Created attachment 67752 [details]
xrandr output 3.0

xrandr --verbose

Comment 6 Torsten Krah 2011-08-06 10:56:54 UTC

Created attachment 67762 [details]
dmesg 2.6.32

Comment 7 Torsten Krah 2011-08-06 11:04:51 UTC

Created attachment 67772 [details]
dmesg 3.0

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

Comment 8 Torsten Krah 2011-08-06 11:08:49 UTC

Created attachment 67782 [details]
Xorg.0.log 2.6.32

Comment 9 Torsten Krah 2011-08-06 11:18:40 UTC

Created attachment 67792 [details]
Xorg.0.log 3.0

Comment 10 Alex Deucher 2011-08-06 13:33:46 UTC

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.

Comment 11 Torsten Krah 2011-08-07 09:54:20 UTC

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:

#!/bin/bash
touch /tmp/xrandr.out
echo "Called" >> /tmp/xrandr.out
/usr/bin/xrandr.dist $@


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?

Comment 12 Alex Deucher 2011-08-07 14:44:59 UTC

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)?

Comment 13 Torsten Krah 2011-08-08 15:43:11 UTC

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.

Comment 14 Alex Deucher 2011-08-08 16:28:15 UTC

No worries, it can get confusing.  Unfortunately, I'm not that familiar with how each desktop environment handles hotkeys.