|
Description
altadeos
2013-06-30 14:16:12 MSK
Unlikely, that the only difference between systems, you have been tested, is arch. Most probably at least the kernel versions are different, so on both of OS with your acpi* options and without them do this and attach output: uname dmesg ls /sys/class/backlight Try to manipulate brightness through /sys/class/backlight/*/brightness if you have any directory there try to change brightness with setpci utility as described here https://wiki.archlinux.org/index.php/Backlight attach lspci Can brightness be regulated by Fn keys? Created attachment 1579 [details]
result of the commands ont R1 x64 live
here are tests with x64 live R1 -> brightness/backlight doesn't work with acpi_osi=Linux acpi_backlight=vendor
/sys/class/backlight is empty
Created attachment 1580 [details]
here is the result on R1 X86 live
result of the commands on R1 x86 live
here are tests with x86 live R1 -> brightness/backlight doesn't work with acpi_osi=Linux acpi_backlight=vendor
/sys/class/backlight is empty
With an updated system the problem is the same. /sys/class/backlight is empty. I am downloading Desktop fresh original iso that work i will give you the same informations. backlight/brightness can be regulated by Fn keys only if i put acpi_osi=Linux acpi_backlight=vendor and only with Rosa desktop before R1. Regards. As I can see from logs you have attached, neither of this systems can switch brightness programatically. However, I need uname, dmesg and "ls /sys/class/backlight" from system, where switching works fine. Your firmware provides ACPI interface to backlight [ 6.429789] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 6.429900] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input6 So I need to examine the implementation of GFX0 device section. Find out where does it reside by running grep GFX /sys/firmware/acpi/tables/[D,S]SDT* most probably it will be DSDT. Then attach cat /sys/firmware/acpi/tables/<your table> If you boot without your acpi_[backlight,osi] options, then acpi_video0 device node should appear inside sysfs backlight directory. Maybe not only one with option video.allow_duplicates=1. Make sure /sys/module/video/parameters/brightness_switch_enabled set to Y, cause it can be disabled by initialization software. Attach "cat max_brightness", then try to write some values to brightness file and attach dmesg after doing that. If it is a regression in kernel, you should check out the last version of kernel, where switching brightness works, then it will be possible to guess what commit offended your system Thanks for your answer. I'am downloading Rosa desktop fresh x64 original iso. (with working backlight/brightness support) I will give you the informations you need. Is there a way to know what graphical driver is used? We will do the investigations with x64 so that tests will be more easy and when the bug is identified i think it can be more easy to port the fix to x86 flavour. Are you ok with this? Add to /etc/default/grub in string GRUB_CMDLINE_LINUX_DEFAULT acpi_osi="!Windows 2012" Then update grub with update-grub2 Created attachment 1584 [details]
tests with R1 live x64 without acpi* options
cat /sys/firmware/acpi/tables/DSDT return me some strange informations
a lot of caracters are ?
when i manipulate brightness file like echo 8 > /sys/class/backlight/acpi_video0/brightness changes are ok on the file but nothing happen on screen. No backlight change.
I will test with acpi_osi="!Windows 2012" with live R1 x64 and post another attachment
Created attachment 1585 [details]
R1 x64 with acpi_osi windows 2012 option
cat /sys/firmware/acpi/tables/DSDT return me some strange informations
a lot of caracters are ?
when i manipulate brightness file like echo 8 > /sys/class/backlight/acpi_video0/brightness changes are ok on the file but nothing happen on screen. No backlight change.
Created attachment 1586 [details]
Desktop fresh original x64 with acpi* options all is ok
test with first original Rosa Desktop Fresh x64 iso (live)
options: acpi_osi=Linux acpi_backlight=vendor
All is working: fn keys and with kde i can change backlight/brightness.
Created attachment 1587 [details]
Desktop fresh original x64 with acpi* options Xorg.0.log
i don't know if it is necessarry
Created attachment 1588 [details]
Rosa Desktop Original x64 acpi_osi windows 2012 tests
Rosa Desktop original iso x64 live
option: acpi_osi="!Windows 2012"
cat /sys/firmware/acpi/tables/DSDT return me some strange informations
a lot of caracters are ?
2 directories in /sys/class/backlight
acpi_video0@ intel_backlight@
FN keys not working but i can change backlight when i manipulate /sys/class/backlight/intel_backlight/brightness file
Created attachment 1589 [details]
Rosa Desktop Original x64 acpi_osi windows 2012 Xorg.0.log
Created attachment 1590 [details]
Rosa Desktop original x64 acpi_osi=vendor tests
Rosa Desktop original x64 iso
options: acpi_backlight=vendor
cat /sys/firmware/acpi/tables/DSDT return me some strange informations
a lot of caracters are ?
FN Keys are not working but i can change brightness with kde or when i manipulate /sys/class/backlight/intel_backlight/brightness file
Created attachment 1591 [details]
Rosa Desktop original x64 acpi_osi=vendor Xorg.0.log
Created attachment 1592 [details]
Rosa Desktop original x64 live acpi_osi=Linux tests
Rosa Desktop original x64 live tests
options: acpi_osi=Linux
FN Keys are ok, i can change brightness when i manipulate /sys/class/backlight/intel_backlight but i can't change it with kde
Created attachment 1593 [details]
Rosa Desktop original x64 live acpi_osi=Linux Xorg.0.log
Created attachment 1594 [details]
Rosa Desktop original x64 without options tests
Rosa Desktop original x64 live without options
FN Keys doesn't work
i can't change brightness with kde
when i manipulate /sys/class/backlight/intel_backlight/brightness i can change brightness
Created attachment 1595 [details]
Rosa Desktop original x64 without options Xorg.0.log
Disappearing of intel_backlight is fixed in 3.9-mainline https://patchwork.kernel.org/patch/2547651/ So you should upgrade your kernel and after that backlight will work fine again with your options. Confirm and mark bug as resolved However, it is not recommended to use acpi_osi=Linux, since it can expose a lot of firmware bugs. You actually don't need this option(and acpi_video), your X server by default using acpi_video0 directory, but this can be changed in xorg.conf Option "Backlight" "intel_backlight" After that it will use intel's backlight directories and you can safely get rid of changing osi And I still want to see dsdt, "strange symbols" is aml code. There is small chance to fix acpi_video0 by patching acpi tables Thank you for your help. Informations you told me are really good. I will install a Rosa Desktop R1 x64, update it and install a 3.9.x linux kernel. After that i will test without and with options. I will post here the results for informations. Do i only need to run in a terminal "cat /sys/firmware/acpi/tables/DSDT" and copy paste on a text file the return? If it's this i will post you the file this evening. I think there was no xorg.conf file do i need to generate one with the drake tool from system center? Really thank you for the time you passed on my problem. Created attachment 1625 [details]
DSDT from Rosa R1 x64 up to date
Rosa R1 installed on the hdd of my laptop
Created attachment 1626 [details]
Rosa R1 x64 with kernel 3.9.8 no acpi* options
i can change backlight/brightness with kde or when i manipulate the brightness file
FN keys doesn't work
xorg.conf have option "Backlight" "intel_backlight"
Created attachment 1627 [details]
xorg.conf
after some tests with 3.9.8 laptop kernel i notice this: - if i only put the backlight option in xorg.conf i can modify my backlight/brightness with kde but FN keys doesn't work - if i boot with acpi_osi=Linux acpi_backlight=vendor options it's the same fn keys doesn't work and i can only change with kde - if i boot with acpi_osi="!Windows 2012" option same things happen FN keys doesn't work anymore Do you want a test with kernel 3.10 if available? (In reply to comment #26) > after some tests with 3.9.8 laptop kernel i notice this: > - if i only put the backlight option in xorg.conf i can modify my > backlight/brightness with kde but FN keys doesn't work > - if i boot with acpi_osi=Linux acpi_backlight=vendor options it's the same > fn keys doesn't work and i can only change with kde > - if i boot with acpi_osi="!Windows 2012" option same things happen > > FN keys doesn't work anymore > Do you want a test with kernel 3.10 if available? Extra keys, even those, that control backlight's level, have nothing to do with backlight infrastucture actually. The only kernel's duties are mapping scancodes to keycodes and raising events on presses or releases through evdev infrastructure(usually /dev/input/event*), then one of the userspace applications captures them and takes some actions according to its policy. If that keys meant to control backlights, then this app may write something in appropriate backlight's sysfs files. Since backlight and keys, it controlled by, have no relationship with each other, you should fill another bug. Now, if you can change brightness level through sysfs and kde's powerdevil handles it as well, you should mark this bug as solved p.s. before filling a bug about your new problem, check out this articles: https://wiki.archlinux.org/index.php/Extra_Keyboard_Keys#Using_showkey https://wiki.archlinux.org/index.php/Map_scancodes_to_keycodes p.p.s. dsdt, you have attached, is invalid. I believe, content, you copied from terminal window to file(if you did so), considered ascii, but in fact it is binary. Do cat DSDT > dsdt.aml and attach dsdt.aml Created attachment 1633 [details]
dsdt.aml
[root@laptop ~]# cat /sys/firmware/acpi/tables/DSDT > /home/rom1/dsdt.aml
i have tried with xev and showkey for FN + F11 (backlight down) and FN + F12 (backlight up) but they don't return anything. No keycodes. Do i need to open a new bug report for this? Resolved in kernel 3.9.x for the Fn+F11 (backlight decrease) and Fn+F12 (backlight increase) combinaison keys that doesn't work anymore else with acpi_osi=Linux i will open a new bug report |