Latest working kernel version:-
Earliest failing kernel version:188.8.131.52
Hardware Environment: Fujitsu-Siemens Amilo Pi 2515
Problem Description: I am able to load fujitsu-laptop module, dmesg says:
fujitsu-laptop: driver 0.3 successfully loaded.
The modules creates entries in /sys/devices/platform/fujitsu-laptop/ and /sys/class/backlight/fujitsu-laptop/. I am unable, however, to change my brightness via /sys/class/backlight/fujitsu-laptop/brightness or /sys/devices/platform/fujitsu-laptop/lcd_level. The values are written in corresponding files, but nothing happens. actual_brightness is always 0 regardless of initial brightness level. No errors in dmesg.
Created attachment 14725 [details]
output of acpidump
Sporadic comments coming in seem to indicate that Fujitsu have a number of different incompatible methods of controlling LCD brightness. The current Fujitsu laptop module works for the S702x lifebook series and a handful of others. Particularly on newer laptops it seems that while the "Fujitsu 02B1" device is still physically present (and providing some functionality), control of the LCD brightness has been moved to something else. The presence of the 02B1 device is the reason why the fujitsu module loads and appears to work while not actually affecting the LCD brightness.
I will see if I can work out a way of identifying laptops which use the 02B1 for brightness control so the module only loads for those machines. However, this may be complicated by the fact that I don't have a machines for which this module doesn't work.
An interim fix may be to change the configuration item help text to explicitly mention all machines for which we know it does work, rather than being generic.
it seems that you don't need to use the fujitsu-laptop driver.
Please apply the patch at http://bugzilla.kernel.org/show_bug.cgi?id=10042#c8, set CONFIG_ACPI_VIDEO and recompile the kernel.
Load ACPI video driver and see if it works.
I'll give this a go on my S7020. I had a look at the patch but it seems to relate to systems where the ACPI video driver actually accepts the hardware. On my S7020 from memory that doesn't happen - with the acpi_video driver loaded the relevant area of /sys is empty (sorry, I can't recall the precise path off the top of my head). I will however test and report back.
From the acpidump attached,
we can see that the Fujitsu-Siemens Amilo Pi 2515 backlight control go via ACPI video extensions rather than Fujitsu platform specific control methods.
So fujitsu-laptop should have no effects on this laptop.
Patch at http://bugzilla.kernel.org/show_bug.cgi?id=10042#c8 is to fix a BIOS bug which is shown in the acpidump.
BTW: I think there are some problems on probing a device in fujitsu-laptop driver. Generally speaking, the .init call should do nothing except registering the driver. And the driver .add methods should be used to probe a compatible device, if there is any, and build the sys backlight I/F for this device. Or else users may be confused by the /sys/class/backlight/fujitsu-laptop/ like in this bug report. what do you think? :)
Ah right, yes, I see that now: the Pi 2515 backlight goes via ACPI while the one on the S7020 doesn't.
As to the second point, it's a good thought. I'll look into this. You don't happen to know of a driver which does this right which I could use for information, do you? I copied one of the existing "laptop extras" drivers as a template and so inherited the current state of affairs from that.
Sys I/F works with kernel 2.6.25-r5 and ACPI video module. fujitsu-laptop not needed in this case.
(In reply to comment #6)
> As to the second point, it's a good thought. I'll look into this. You don't
> happen to know of a driver which does this right which I could use for
> information, do you?
First, are you sure there is only one "FUJ02B1" devices can be shown ACPI namespace?
IMO, we should build a fujitsu_t structure and register a backlight class device for each "FUJ02B1" device, unless it's documented somewhere that no multiple "FUJ02B1" devices allowed.
Second, we can set a flag in the acpi_fujitsu_driver .add method. And in the fujitsu_init, check the flag after acpi_bus_register_driver and return -ENODEV if the flag is cleared. :)
As this is not a bug, I'll reject it and mark it as closed.
for the driver issue, let's discuss in the acpi_devel, where we can get more comments and the patch can be accepted by len sooner. :)