Description of problem: There is a laptop Samsung RV520 with installed Fedora 16. Some hotkeys (Fn + <key>) don't work, e.g. [Fn + Up/Down] (backlight brightness control), [Fn + F5] (display backlight off/on), [Fn + F9] (wireless devices on/off). At the same time, hotkeys [Fn + Esc] (suspend), [Fn + Right/Left] (volume level up/down) and [Fn + F6] (volume off/on) work fine. <lsmod> shows that <samsung-laptop> module isn't loaded. Attempt to load this module fails with error "No such device". When I press [Fn + Up/Down], the contents of the files (<actual_brightness>, <brightness>) at the path </sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0/> change. But actually brightness level doesn't change. ___________________________________ Version-Release number of selected component (if applicable): kernel-3.1.0-7.fc16.i686 / kernel-3.2.6-3.fc16.i686, udev-173-3.fc16.i686 ___________________________________ How reproducible: always ___________________________________ Steps to Reproduce: 1. Press [Fn + Up/Down/F9] (Samsung RV520, Fedora 16) 2. Backlight level doesn't change, wireless devices don't switch ___________________________________ Actual results: Some [Fn + <key>] hotkeys don't work. ___________________________________ Expected results: All [Fn + <key>] hotkeys (e.g. brightness control and wireless devices on/off) work fine. Additional info: <dmidecode -s system-product-name> command returns <RV420/RV520/RV720/E3530/S3530/E3420/E3520>. The passing the <acpi_backlight=vendor> argument to the kernel doesn't help. This trouble appears also in the Live-CD mode.
I've tried to change the display brightness level with the <setpci> command, but this attempt has failed: $ lspci | grep VGA 01:00.0 VGA compatible controller: nVidia Corporation Device 1050 (rev a1) $ sudo setpci -s 01:00.0 F4.B 00 $ sudo setpci -s 01:00.0 F4.B=50 $ sudo setpci -s 01:00.0 F4.B 00
Theoretically, the patches for this are here: http://thread.gmane.org/gmane.linux.drivers.platform.x86.devel/2700/focus=2701 and queued up in the platform maintainer's git tree somewhere. The don't seem to have made the 3.3 kernel though.
As far as I'm concerned, the necessary changes at the <samsung-laptop> driver will be in the kernel 3.4 or, if lucky, in 3.3. Right?
I've took a workaround, which made brightness control to work: I've put this code to the <samsung-laptop.c> ___________________________________ { .ident = "RV420/RV520/RV720/E3530/S3530/E3420/E3520", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), DMI_MATCH(DMI_PRODUCT_NAME, "RV420/RV520/RV720/E3530/S3530/E3420/E3520"), DMI_MATCH(DMI_BOARD_NAME, "RV420/RV520/RV720/E3530/S3530/E3420/E3520"), }, .callback = dmi_check_cb, }, ___________________________________ and compiled the module with this Makefile: ___________________________________ obj-m := samsung-laptop.o KERNELDIR ?= /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) all: $(MAKE) -C $(KERNELDIR) M=$(PWD) clean: rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c rm -f Module.markers Module.symvers modules.order rm -rf .tmp_versions Modules.symvers ___________________________________ Then I've put <samsung-laptop.ko> to the </lib/modules/$(uname -r)/kernel/drivers/platform/x86/> directory and run <# depmod -a>. Now the brightness level is adjustable.
[mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update.
When the new kernel-3.3.0-4 had appeared at the Fedora repository, the first thing I've done was testing the samsung-laptop kernel module on my Samsung RV-520. The result is the same. This module isn't automaticaly loadable. The work around is a rebuilding this module with the same instruction as before.
* This module isn't loadable at all.
The patches I mentioned in comment #2 should go into the 3.4 kernel. That won't be immediately available in F17.
I've exactly understood this. Thanks.
Well! Kernel 3.4 has been built for Fedora 17 here: http://koji.fedoraproject.org/koji/buildinfo?buildID=321678 I've installed it and now the <samsung-laptop> kernel module is loadable. But the new trouble has appeared: when I try to change the brightness level, the maximum brightness limit becomes very low (~30%). Then, when I press <Fn + Up> (brightness up) further, a backlight is blinking for a short time, but the brightness level doesn't change. <Fn + Down> (brightness down) works well. If I unplug the supply cable and then plug it back, the brightness level becomes maximum (100%). But after decreasing the brightness level the problem with <Fn + Up> repeats again.
Addition: now I use F17.
# cat /sys/devices/platform/samsung/backlight/samsung/max_brightness 8 # echo 8 > /sys/devices/platform/samsung/backlight/samsung/actual_brightness -bash: /sys/devices/platform/samsung/backlight/samsung/actual_brightness: Permission denied But the backlight is blinking for a short time, if I execute this: # echo 8 > /sys/devices/platform/samsung/backlight/samsung/brightness
Created attachment 589037 [details] the working <samsung-laptop> source If I build the <samsung-laptop> (with the attached <samsung-laptop.c> and <Makefile>), put the <samsung-laptop.ko> into </usr/lib/modules/3.4.0-1.fc17.i686.PAE/updates/>, type <# modprobe -r samsung_laptop> / <# depmod -a> / <# modprobe samsung-laptop> the brightness level becomes fully adjustable.
Created attachment 589038 [details] <Makefile> for building the working <samsung-laptop> kernel module See a previous comment (attachment).
I've updated kernel up to 3.4.1 from here: http://koji.fedoraproject.org/koji/buildinfo?buildID=321994 The situation is the same: after the brightness level decreasing it's not possible to increase it back higher some limited level. That's some console output (after <Fn + Down> to min and <Fn + Up> to max): > $ cat /sys/devices/platform/samsung/backlight/samsung/actual_brightness > 2 > $ cat /sys/devices/platform/samsung/backlight/samsung/brightness > 8 > $ cat /sys/devices/platform/samsung/backlight/samsung/max_brightness > 8
<kernel-3.5.0-1.fc17.i686.PAE>: the situation is the same. I've additionally reported this bug to upstream. https://bugzilla.kernel.org/show_bug.cgi?id=45311
(In reply to comment #15) > Created attachment 589037 [details] > the working <samsung-laptop> source > I'm confused as to what this is exactly. Where did it come from? Instead of attaching a full .c file, can you create a unified diff and send that to the driver maintainer for review with platform-driver-x86.org on CC?
# Mass update to all open bugs. Kernel 3.6.2-1.fc16 has just been pushed to updates. This update is a significant rebase from the previous version. Please retest with this kernel, and let us know if your problem has been fixed. In the event that you have upgraded to a newer release and the bug you reported is still present, please change the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. If you are not the original bug reporter and you still experience this bug, please file a new report, as it is possible that you may be seeing a different problem. (Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
(In reply to comment #19) > (In reply to comment #15) > > Created attachment 589037 [details] > > the working <samsung-laptop> source > > > > I'm confused as to what this is exactly. Where did it come from? When the <kernel> version was 3.3 it had no support for my laptop. And I has followed this instruction: http://linuxtweaking.blogspot.com/2011/11/enabling-samsung-laptop-backlight.html So I had a working <samsung-laptop> module. I don't know what is this module version. > Instead of attaching a full .c file, can you create a unified diff and send > that to the driver maintainer for review with platform-driver-86.org on CC? Then the <samsung-laptop> module has been modified enough at the 3.4 <kernel> version, in particular, the mechanism for determining the hardware. Now there is no need to modify the <samsung-laptop.c> with DMI output for each notebook model. So diff is useless. The bug is in that it's impossible to increase the brightness level with native kernel <samsung-laptop> driver. I can not fix it myself, because I don't know programming languages and can not find a suitable manual for fixing it in the <samsung-laptop> module from kernel >= 3.4.
UPD: Now I already use F18.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.