On Jan 15, 2008, at 8:34 PM, Eric Anholt wrote: > On Mon, 2008-01-14 at 16:01 +0000, Rui Paulo wrote: >> I have the backlight module ready to be committed (needs approval >> first), but it would be great if we could create a general backlight >> API. I have some initial ideas, but needs a bit more thought. >> >> Also, xrandr on (7.3 with "intel" video driver) seems to be able to >> control the LCD backlight on MacBooks, but it seems bogus: >> >> % xrandr --prop >> Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280 >> VGA disconnected (normal left inverted right x axis y axis) >> LVDS connected 1280x800+0+0 (normal left inverted right x axis y >> axis) 286mm x 179mm >> EDID_DATA: >> 00ffffffffffff0006105b9c00000000 >> 0e100103801d12780a87f594574f8c27 >> 27505400000001010101010101010101 >> 010101010101bc1b00a0502017303020 >> 36001eb3100000190000000100061020 >> 00000000000000000a20000000fe004c >> 544e31333357310000000a20000000fc >> 00436f6c6f72204c43440a20202000c6 >> BACKLIGHT: 296 (0x00000128) range: (0,296) >> >> I don't really know about how exactly this control works, because: >> >> 1) the range is wrong. >> 2) setting values with xrandr --output LVDS --set BACKLIGHT <value>, >> doesn't seem to be doing anything good. It just sets a high and low >> value for the backlight brigthness. >> >> If anyone knows anything about this, I would appreciate if you could >> step forward. >> >> There's another problem: xv (try it with mplayer -vo xv) seems to be >> setting the backlight value on initialization. So, if you start Xorg >> with backlight value of 50, then reduce it to 20 and after that try >> to play a video with mplayer, the backlight value seems to come back >> to 50. There are very strange interactions between xrandr and my own >> backlight control kernel module. It would be great to disable >> xrandr's >> backlight control, at least. >> >> Regards. >> -- >> Rui Paulo >> I have the backlight module ready to be committed (needs approval >> first), but it would be great if we could create a general backlight >> API. I have some initial ideas, but needs a bit more thought. >> >> Also, xrandr on (7.3 with "intel" video driver) seems to be able to >> control the LCD backlight on MacBooks, but it seems bogus: >> >> % xrandr --prop >> Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280 >> VGA disconnected (normal left inverted right x axis y axis) >> LVDS connected 1280x800+0+0 (normal left inverted right x axis y >> axis) 286mm x 179mm >> EDID_DATA: >> 00ffffffffffff0006105b9c00000000 >> 0e100103801d12780a87f594574f8c27 >> 27505400000001010101010101010101 >> 010101010101bc1b00a0502017303020 >> 36001eb3100000190000000100061020 >> 00000000000000000a20000000fe004c >> 544e31333357310000000a20000000fc >> 00436f6c6f72204c43440a20202000c6 >> BACKLIGHT: 296 (0x00000128) range: (0,296) >> >> I don't really know about how exactly this control works, because: >> >> 1) the range is wrong. >> 2) setting values with xrandr --output LVDS --set BACKLIGHT <value>, >> doesn't seem to be doing anything good. It just sets a high and low >> value for the backlight brigthness. > > That xrandr --prop output may be broken. My xlib fu is weak. > >> If anyone knows anything about this, I would appreciate if you could >> step forward. >> >> There's another problem: xv (try it with mplayer -vo xv) seems to be >> setting the backlight value on initialization. So, if you start Xorg >> with backlight value of 50, then reduce it to 20 and after that try >> to play a video with mplayer, the backlight value seems to come back >> to 50. There are very strange interactions between xrandr and my own >> backlight control kernel module. It would be great to disable >> xrandr's >> backlight control, at least. > > I use xbacklight -set <percentage> to control backlight. Your issue > with it flipping to only a high/low value may have been the one > jbarnes > fixed in git recently (apparently a low bit got redefined on us). That's great news. This way we can rely on Xorg to set the backlight instead of adding one more kernel module. Thanks for the information. -- Rui PauloReceived on Fri Jan 18 2008 - 22:27:37 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:26 UTC