Acer Aspire 5920G - some Fn keys not working

Ok, so with attached 30-keymap-acer.fdi all your keys should work now. Please test and verify.

With this, you should still get the "double brightness switch" keys. The keys shouldn't be set to "reserved", since pressing them should still give UI feedback about the brightness change. They just shouldn't actually change the brightness.

This is done in /usr/share/hal/fdi/information/10freedesktop/10-laptop-panel-hardware.fdi. Can you please do

  lshal > /tmp/hal.txt

and attach /tmp/hal.txt here? From that I can create an entry in 10-laptop-panel-hardware.fdi which will fix the brightness keys.

Thank you!

Martin, please use the attached .fdi. It only differs from your last one in 2 lines.

Sorry for forgetting about lshal before, here it is:

Thanks for the update; I'll commit this once we sorted out the brightness issue.

Hm, it seems that your hal already seems to know that it should control the brightness in hardware, from your lshal:

    laptop_panel.brightness_in_hardware = true (bool)

so changing 10-laptop-panel-hardware.fdi won't help. Could you try

  sudo mv /etc/acpi/events /etc/acpi/events.disabled

and see whether this changes anything? If not, please change it back:

   sudo mv /etc/acpi/events.disabled /etc/acpi/events

Thanks!

I didn't see any difference with
sudo mv /etc/acpi/events /etc/acpi/events.disabled

A workaround for the brightness problem is to blacklist the video module. I don't know if this is a good thing to do or not; but I've been using my laptop like this for a lot of months now without a problem.

With the video module *not* blacklisted:

alkisg@alkisg:~$ find /sys -name '*bright*' 2>&-
/sys/devices/platform/acer-wmi/backlight/acer-wmi/brightness
/sys/devices/platform/acer-wmi/backlight/acer-wmi/actual_brightness
/sys/devices/platform/acer-wmi/backlight/acer-wmi/max_brightness
/sys/devices/virtual/backlight/acpi_video0/brightness
/sys/devices/virtual/backlight/acpi_video0/actual_brightness
/sys/devices/virtual/backlight/acpi_video0/max_brightness
<...omitting some non-useful devices...>
/sys/module/video/parameters/brightness_switch_enabled
/sys/module/acer_wmi/parameters/brightness

With the video module *blacklisted*:

/sys/devices/platform/acer-wmi/backlight/acer-wmi/brightness
/sys/devices/platform/acer-wmi/backlight/acer-wmi/actual_brightness
/sys/devices/platform/acer-wmi/backlight/acer-wmi/max_brightness
<...omitting some non-useful devices...>
/sys/module/acer_wmi/parameters/brightness

So maybe the problem is that the video module adds a second, fake, brightness "device"?

In the previous hal.txt I attached, I'm afraid that I had messed with /usr/share/hal/fdi/information/10freedesktop/10-laptop-panel-hardware.fdi.

I include two versions of lshal:
lshal-1.txt => with the original 10-laptop-panel-hardware.fdi.
lshal-2.txt => again with the original 10-laptop-panel-hardware.fdi, but also with the video module blacklisted.

Ah, that explains it. Indeed in lshal-1.txt the brightness_in_hardware property is set to false on one device, and on the other it's not existing.

With the fdi files that got you the original hal.txt in comment 3, was brightness working correctly there?

If you replace your /usr/share/hal/fdi/information/10freedesktop/10-laptop-panel-hardware.fdi with this version, does it work correctly?

> With the fdi files that got you the original hal.txt in comment 3, was brightness working correctly there?
No.

> If you replace your /usr/share/hal/fdi/information/10freedesktop/10-laptop-panel-hardware.fdi with this version, does it work correctly?
No.

In both cases I get 5 brightness levels instead of 10, meaning that each "brightness-up" keystroke causes two events.
In both cases, laptop_panel.brightness_in_hardware = true (bool).
If I blacklist the video module, I get the proper 10 brightness levels.

With the 10-laptop-panel-hardware.fdi you've attached I've noticed one difference though: I can see the brightness window again (I haven't been seeing it at all in Intrepid). But while I can see the window, I *can't* see the progress bar value, it's always empty, even when the actual brightness is at its maximum (see the attached screenshot).

Thanks,
Alkis

Thanks for your investigations. Then it seems this needs to be fixed at the kernel level, there's no workaround in hal-info (except the wrong one with totally disabling the brightness keys). I open a kernel task for this.

Indeed it seems since both acer_wmi and the general acpi laptop panel exist on your system, you get each key event acted on twice.

So for now I'll commit the updated key symbols to hal-info. I'm afraid you need to leave your "blacklist video" approach on your sytem for now.

Committed upstream.

Will the 'kernel task' exist in bugzilla? Can you link from here when the process starts?

Cheers
Charlie

FokkerCharlie [2009-03-06 18:22 -0000]:
> Will the 'kernel task' exist in bugzilla? Can you link from here when
> the process starts?

I won't drive the kernel side bug triage, as I don't know much about
the kernel side of key event handling, I'm afraid.

I've installed Jaunty and I want to report the brightness behaviour there; I hope I didn't need to open a new bug report.

* I again blacklisted the video module because of the same problem (each key changing the brightness twice).

* With the default /usr/share/hal/fdi/information/10freedesktop/10-laptop-panel-hardware.fdi file, laptop_brightness_in_hardware was not defined, and I assume it defaults to false, because the brightness adjustment window had a "software brightness level" of its own, and when I changed the brightness too rapidly the software level was different than the hardware level and there were glitches.

* I overwritten 10-laptop-panel-hardware.fdi with the new version Martin uploaded here; now I have laptop_panel.brightness_in_hardware = true and this saved me from the previous glitches while rapidly changing the brightness.
Now the problem is that the brightness adjustment window always thinks the level is zero; it can't read the hardware brightness level.
Nevertheless, `cat /sys/devices/platform/acer-wmi/backlight/acer-wmi/actual_brightness` does allow me to see the correct brightness level, so the kernel knows about it.

Any help with the last problem?

This bug was fixed in the package hal-info - 20090324-0ubuntu1

---------------
hal-info (20090324-0ubuntu1) jaunty; urgency=low

  * New git snapshot:
    - Ignore U3 (Windows software) on SanDisk Cruzer Titanium (LP: #347457)
    - Nokia 5300 mobile phone modem (LP: #329633)
    - Insignia Pilot portable audio player (LP: #335965)
    - Fix Acer Aspire 5920G keymap (LP: #338328)
    - Sansa Fuze not listed as supporting Vorbis and FLAC (LP: #345249)

 -- Martin Pitt <email address hidden> Wed, 25 Mar 2009 10:54:08 +0100

Hi Alkis,

This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/lucid.

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 338328

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Lucid doesn't use hal anymore, so the only issue left is the brightness issue, which still exists, i.e.:
 * I don't see the brightness notification window when I change the brightness,
 * I only have 5 levels for brightness instead of 10,
 * When I blacklist the video module I correctly have 10 levels of brightness.

I've ran the apport command from my Lucid but without the -p switch, maybe that's specific to apport-cli.
I did that with the video module blacklisted.

I'll test with an upstream kernel in a couple of weeks, thanks.

Alkis,
   That is most helpful. Thanks for following up on this bug. I'll discuss this issue with the team.

Thanks!

~JFo

I tried with the daily Lucid live cd, and I'm able to see the brightness window - so there must be something wrong in my hard disk installation - I've first installed Lucid in alpha 1 and I've been upgrading since (I've tried with a new user so it must be a system setting).

So the only problem that remains is the 5 levels of brightness instead of 10 when I blacklist the video module.
I'm willing to provide any information needed, but it's really not important anymore, so feel free to close this bug report at any time. :)

Instead of blacklisting the video module, I found a new workaround:
  $ echo "options video brightness_switch_enabled=0" | sudo tee /etc/modprobe.d/video.conf
This again gives me 10 levels of brightness on my laptop instead of just 5.

I wonder if the video module can special-case some hardware configurations, so that brightness_switch_enabled is false for them by default. It appears to contain some list of Acer Aspire models, but not mine:

# strings /lib/modules/2.6.32-24-generic-pae/kernel/drivers/acpi/video.ko | grep "Acer Aspire"
Acer Aspire 5720
Acer Aspire 5710Z
Acer Aspire 5315
Acer Aspire 7720

# dmidecode -s system-product-name
Aspire 5920G

Alkis Georgopoulos, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder, but the one at the top) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc4

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

That laptop has died 3 years ago, feel free to let the bug report expire.

I'll be reporting all other kernel-related bugs upstream from now on since those that I've reported in launchpad only get the occasional "can we close it now?" feedback every few years. It's understandable, and sorry I just didn't know where's the right place to report the bugs back then. Thank you for your time!

Alkis Georgopoulos, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/hal-info/+bug/338328/comments/40 regarding you no longer have the hardware. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.