Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1058073 - HP G42-240BR: Brightness Down fn key won't lower brightness in gnome3
Summary: HP G42-240BR: Brightness Down fn key won't lower brightness in gnome3
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-26 21:16 UTC by Rafael Luik
Modified: 2015-05-26 09:03 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-10 15:00:44 UTC


Attachments (Terms of Use)

Description Rafael Luik 2014-01-26 21:16:59 UTC
Description of problem:
The notebook I installed Fedora 20 has a pt-BR keyboard. There are multiple "Fn" keys at the top (they work without having to press Fn - Fn is used to access F1, F2, etc). Among the keys are Volume +, -, Play, Pause, etc, and all of them work including Brightness Up except Brightness Down that does nothing but show the current Brightness level.


How reproducible:
Just run the GNOME LiveDVD.
The notebook model is HP G42-240BR.

Steps to Reproduce:
1. Logon.
2. Press the Brightness - key.

Actual results:
The Brightness indicator will appear in the screen but the level of brightness won't lower, neither in the indicator nor the brightness of the display itself.

Expected results:
It should lower the brightness like all the other Fn keys work including the Brightness Up.

Additional info:
Sorry if I'm reporting this to the wrong component. I have no idea what piece of the big package puzzle handles these keys.

Comment 1 Benjamin Kwiecien 2014-06-27 07:19:04 UTC
Same bug is affecting my current installation. Brightness works when I use the F20 live USB, but after updates my brightness function keys broke in Gnome.

At one point a kernel update had broken brightness control completely. A future update fixed this, but now that my kernel is supporting backlight adjustment again, Gnome's handling of function keys is completely broken. OSD pops up but the brightness gets stuck in one position and won't move. If I adjust brightness using the mouse control instead of the function keys it works.

Comment 2 Hans de Goede 2014-06-27 10:06:44 UTC
Hi,

(In reply to Benjamin Kwiecien from comment #1)
> Same bug is affecting my current installation. Brightness works when I use
> the F20 live USB, but after updates my brightness function keys broke in
> Gnome.
> 
> At one point a kernel update had broken brightness control completely. A
> future update fixed this, but now that my kernel is supporting backlight
> adjustment again, Gnome's handling of function keys is completely broken.
> OSD pops up but the brightness gets stuck in one position and won't move. If
> I adjust brightness using the mouse control instead of the function keys it
> works.

Please don't add "me too" comments to hardware related bugs unless you've the exact same model hardware as the reporter. Chances are that of you don't have the exact same hardware, you may be seeing similar symptons, but you actually have a completely different bug. From your description that may be the same issue as bug 1026090, or it may be a completely different issue.

First lets see if it is the same as bug 1026090, do "ls /sys/class/backlight", and for each directory under
/sys/class/backlight do:

cat /sys/class/backlight/<dir>/max_brightness

If you've a very small value in there for one of the devices (smaller then 20) you are likely affected by bug 1026090.

If all max_brightness values are > 20, then please walk through: http://hansdegoede.livejournal.com/13889.html and file a new bug against the kernel, with your hardware model name (+ problem summary) in the summary. Please provide all info requested in that blog post, and make sure to put me in the CC of the bug.

Comment 3 Hans de Goede 2014-06-27 10:09:54 UTC
Hi,

(In reply to Rafael Luik from comment #0)
> Description of problem:
> The notebook I installed Fedora 20 has a pt-BR keyboard. There are multiple
> "Fn" keys at the top (they work without having to press Fn - Fn is used to
> access F1, F2, etc). Among the keys are Volume +, -, Play, Pause, etc, and
> all of them work including Brightness Up except Brightness Down that does
> nothing but show the current Brightness level.
> 
> 
> How reproducible:
> Just run the GNOME LiveDVD.
> The notebook model is HP G42-240BR.
> 
> Steps to Reproduce:
> 1. Logon.
> 2. Press the Brightness - key.
> 
> Actual results:
> The Brightness indicator will appear in the screen but the level of
> brightness won't lower, neither in the indicator nor the brightness of the
> display itself.

Can you control the brightness with the slider in the system-menu (the menu in the upper right corner) ? If so, if you put the brightness at a different value does the brightness - key work then ?

Can you please do "ls /sys/class/backlight", and for each directory under
/sys/class/backlight do:

cat /sys/class/backlight/<dir>/max_brightness

And let me know the output of each command (including for which dir it was) ?

Thanks,

Hans

Comment 4 Benjamin Kwiecien 2014-06-28 14:37:22 UTC
(In reply to Hans de Goede from comment #2)
> Please don't add "me too" comments to hardware related bugs unless you've
> the exact same model hardware as the reporter. Chances are that of you don't
> have the exact same hardware, you may be seeing similar symptons, but you
> actually have a completely different bug. From your description that may be
> the same issue as bug 1026090, or it may be a completely different issue.
> 
> First lets see if it is the same as bug 1026090, do "ls
> /sys/class/backlight", and for each directory under
> /sys/class/backlight do:
> 
> cat /sys/class/backlight/<dir>/max_brightness
> 
> If you've a very small value in there for one of the devices (smaller then
> 20) you are likely affected by bug 1026090.
> 
> If all max_brightness values are > 20, then please walk through:
> http://hansdegoede.livejournal.com/13889.html and file a new bug against the
> kernel, with your hardware model name (+ problem summary) in the summary.
> Please provide all info requested in that blog post, and make sure to put me
> in the CC of the bug.

Hans, thanks for the reply. I apologize and will refrain from doing so in the future. I did more investigation into my own problem and discovered the following:

My system has two directories in /sys/class/backlight/, dell_backlight and intel_backlight. Xorg was defaulting to dell_backlight, which has a max_brightness of 8 on my system. I edited my Xorg configuration to use intel_backlight instead, resolving the sticky backlight issue. Gnome function keys now work, although the backlight flickers brightly when adjusting this way.

I have CC'd myself to bug 1026090. As for the backlight flickering, it is not critical, but should I report it?

Comment 5 Hans de Goede 2014-06-29 12:18:18 UTC
Hi,

(In reply to Benjamin Kwiecien from comment #4)
> (In reply to Hans de Goede from comment #2)
> > Please don't add "me too" comments to hardware related bugs unless you've
> > the exact same model hardware as the reporter. Chances are that of you don't
> > have the exact same hardware, you may be seeing similar symptons, but you
> > actually have a completely different bug. From your description that may be
> > the same issue as bug 1026090, or it may be a completely different issue.
> > 
> > First lets see if it is the same as bug 1026090, do "ls
> > /sys/class/backlight", and for each directory under
> > /sys/class/backlight do:
> > 
> > cat /sys/class/backlight/<dir>/max_brightness
> > 
> > If you've a very small value in there for one of the devices (smaller then
> > 20) you are likely affected by bug 1026090.
> > 
> > If all max_brightness values are > 20, then please walk through:
> > http://hansdegoede.livejournal.com/13889.html and file a new bug against the
> > kernel, with your hardware model name (+ problem summary) in the summary.
> > Please provide all info requested in that blog post, and make sure to put me
> > in the CC of the bug.
> 
> Hans, thanks for the reply. I apologize and will refrain from doing so in
> the future. I did more investigation into my own problem and discovered the
> following:

No need to apologize (*), but still apologies excepted.

*) I was just trying to educate you for future bug reports.

> 
> My system has two directories in /sys/class/backlight/, dell_backlight and
> intel_backlight. Xorg was defaulting to dell_backlight, which has a
> max_brightness of 8 on my system.

Right, xorg will always pick a firmware interface over a raw interface, so that it picks the dell one in normal.

> I edited my Xorg configuration to use
> intel_backlight instead, resolving the sticky backlight issue. Gnome
> function keys now work, although the backlight flickers brightly when
> adjusting this way.
> 
> I have CC'd myself to bug 1026090. As for the backlight flickering, it is
> not critical, but should I report it?

Do you the flickering too when you remove the xorg.conf changes (so that dell_backlight gets used) and then change the brightness through the slider in the system settings menu ?

If yes, then you should file a bug. Please file a bug directly with Intel, as described here:
https://01.org/linuxgraphics/documentation/how-report-bugs

Filing a bug in Fedora's bugzilla will only lead to you getting a request to file at Intel, so lets skip that step :)

If it does not flicker when using dell_backlight, then I see no reason to file a bug. dell_backlight is the one which should peferably be used and you've now overridden that choice to work around a gnome bug, so if dell_backlight does work, then the correct fix would be to fix the gnome bug.

Regards,

Hans

Comment 6 Justin M. Forbes 2014-12-10 15:00:44 UTC
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

Comment 7 Rafael Luik 2015-05-26 09:03:33 UTC
WFM in Fedora 22.


Note You need to log in before you can comment on or make changes to this bug.