xbacklight on intel

[Jesse Barnes]

On Tuesday, November 27, 2007 9:15 am Colin Guthrie wrote:
> Jesse Barnes wrote:
> > On Tuesday, November 27, 2007 8:08 am Khashayar Naderehvandi wrote:
> >>> What does 'xrandr --prop' report when you're running the 2.2 driver?
> >>
> >> This is what I get:
> >>
> >> khashayar at dionysos ~ $ xrandr --prop
> >> Screen 0: minimum 320 x 200, current 1280 x 768, maximum 1280 x 1280
> >> VGA disconnected (normal left inverted right x axis y axis)
> >> LVDS connected 1280x768+0+0 (normal left inverted right x axis y axis)
> >> 0mm x 0mm
> >>         BACKLIGHT_CONTROL: native
> >>                 supported: native       legacy       combination
> >> kernel
> >>         BACKLIGHT: 0 (0x00000000) range:  (0,0)
> >>    1280x768       59.2*+   85.0     75.0     70.0     60.0
> >>    1280x720       85.0     75.0     70.0     60.0
> >>    1152x768       54.8
> >>    1024x768       85.0     75.0     70.1     60.0
> >>    832x624        74.6
> >>    800x600        85.1     72.2     75.0     60.3     56.2
> >>    640x480        85.0     72.8     75.0     59.9
> >>    720x400        85.0
> >>    640x400        85.1
> >>    640x350        85.1
> >> TMDS disconnected (normal left inverted right x axis y axis)
> >
> > So your machine is defaulting to the native register interface.  I wonder
> > if it should be using the legacy interface instead?  Can you try
> >   $ xrandr --output LVDS --set BACKLIGHT_CONTROL legacy
> > and see if xbacklight works for you then?
>
> Weird...
>
> On mine I just realised my backlight wont work with the built in buttons
> (not tried xbacklight) - it just flickers but stays always at 100%.
>
> I have:
>         BACKLIGHT_CONTROL: kernel
>                 supported: native       legacy       combination  kernel
>
>         BACKLIGHT: 100 (0x00000064) range:  (0,100)
>
> Setting it to "legacy" as you stated above caused my X to go into
> infinite loop (100% CPU).
>
> I tried stracing the process after ssh'ing in from a separate machine
> but all I got was lots of calls with the word alarm in it (SIGALARM,
> rt_sigalarm and such like).....

Hm, that sounds bad...  Can you file a bug for the problem?

The buttons may not be working due to a kernel driver bug, but at this point 
the driver doesn't do much with ACPI events at all (assuming the buttons 
generate them in this case).

Jesse