Bug 9724

> Latest working kernel version: ?
> Earliest failing kernel version: 2.6.24-rc7

Did any version of Linux ever work in ACPI mode on this system?

duplicate of bug 9663?

I only rty to use linux debian with recompiled kernels, which has been taken rfom official kernel site.
I try 2.6.[22,23,24-rc[6,7]] and in all them I watch this bug.
All other part of ACPI works well, only brightness vs hotkeys...

>duplicate of bug 9663?

There was solved one but there is another...
so mabye

please attach acpidump.

Created attachment 14416 [details]
The result of acpidump

Mihail,
Please try -rc7 with patch from bug #9627.

OK I`l try.

So I have rtied patch from bug #9627 with .24-rc7 -- so we returned to the bug #9663
We have got fully working /sys but fukky bloked fn keys that even hasn`t generated interupt`s!
Can it work together - working fn + /sys ?

Mihail,
It would be great if you spell-check messages, it is really hard to read them.
bug #9663 says that to get Fn keys working, you need to remove _INI presence check, thus allowing early init of EC from DSDT.
The patch from 9627 does the same, it inits EC before any other device, but you claim that contrary to #9663 Fn keys are not working, while /sys interface does.
hotkeys could be controlled by BIOS itself, thus if video driver (/sys interface to brighness) is loaded, it will disable BIOS control of brightness. To make Fn keys send events, you need some hw-specific driver, which in your case must be toshiba.c, which gives following string in dmesg published in 9663:
--------------------------------------------------------------------
toshiba.c: toshiba.c: toshiba.c: toshiba.c: toshiba.c: toshiba.c: toshiba.c: toshiba: not a supported Toshiba laptop
--------------------------------------------------------------------
So, my guess is that EC with patch from 9627 does its best to enable loading of video driver and making /sys interface work. You may check that it is video.c who disable BIOS and Fn keys by unloading it. You could try to find out what needs to be done in toshiba.c in order for it to recognize your machine and start accepting hotkeys -- contact the toshiba.c author for that...
I'm lowering the severity of this bug, as it is definitely not blocker.

*** This bug has been marked as a duplicate of bug 9627 ***

So I`m sorry for grammar in my messages.
About toshoba.c I can say that this driver isn`t support toshiba laptops with phoenix bios. More of all last laptops came with this bios...
--------------------------------------------------------------------
toshiba.c: toshiba.c: toshiba.c: toshiba.c: toshiba.c: toshiba.c: toshiba.c:
toshiba: not a supported Toshiba laptop
--------------------------------------------------------------------
The first line is the result of adding printk messages in the place where toshiba.c driver check the vendor of bios - it reads vendor from very strange place, which doesn`t contain this information at all. So there are more checks that doesn`t passed on my machine... I don`t think that this driver ever will work on it.

The _INI present in "if" statament, that always true on my machine. So this function always return -ENODEV. And fn keys doesn`t work bun /sys works!
If I remove this statement fn keys works and /sys doesn`t works. It mean that I can`t set brithness via /sys/slass/...../brithness. For example so:
echo 100 > /sys/class/backlight/acpi_video0/brightness
This command has no effect. But when I begin change brightness by using fn keys it change from the value I have set bu the previous command, not from current LCD brightness!
Also the /sys/class/backlight/acpi_video0/actual_brightness shown the real value.
So vorks anything expect immediately software brightness control.

another driver - omnibook created for laptop wiht phoenix bios doesn`t work at all. I have tried to connect with author of this driver, but this afford has no effect.

Resume: I think that common ACPI subsystem works very well, but there is some little thing that doesn`t allow this system to work for 100%. I hope that there is a method to repair it. 

_INI presence check works in exactly opposite way, -ENODEV is returned if it is not present, which is true on your machine (it does not have any _INI methods depending on EC region). Thus, init of EC could be (and should be) done after
all ACPI devices and regions are initialized. Patch from #9627 does exactly that.
If patch is applied, "video" driver finds brightness controls and is able to change it with /sys interface. It also disables BIOS control of the brightness, so 
function keys stop to work. If the patch is not applied, "video" driver is not able to attach and does not disable BIOS control over brightness.
With the patch applied, did you try to unload "video" driver as I asked?

Yes I tried.
fn keys doesn`t work in that case.

Please try to disable ACPI/video in .config 

I will try to do it now...

You might also want to experiment with calls to _DOS in drivers/acpi/video.c

The sequence of execution and params in functions in video.c are the same in both cases - when _INI disabled and when _INI enabled. But results aren`t the same :(

You could just try to disable call to _DOS -- this function will disable BIOS control over brightness.

OK, but all, not only brightness control, fn keys stops working. What about them?

is this really closed as a duplicate of bug 9627?
if yes, lease work it there.

Hi,
Only one question:
hy when i haven`t got _INI all fn keys works and video.c works (It shows some usefull information...)
But when I have _INI works only fn or video.c but not together?

So one more interesting thing,
When I Use X with the patched kernel - there is _INI, and X loaded after video module brightness control keys doesn`t work under X (v7.3)! If I unload and then load video module brightness keys begin to work. But, on toshibe there are 0-7 brightness modes - 0, 14, 28, 42, 56, 70, 84, 100. In patced kernel I have such sequences: when rise: 0 ,28, 56, 84, 100; when down: 100, 700, 42, 14, 0
[fn] key generates no interrupt when _INI enabled properly - the return -ENODEV; present and execute. When this instruction whith if statament above commented [fn] generates interupts. This behavior doesn`t depend on video module at all.
Heve anybody some ideas about that?

>is this really closed as a duplicate of bug 9627?

I think that this problem doesn`t solved! ACPI behaviour is incorrect for my mind

Mikhail,
Let's define terms... in #23 you mentioned patched kernel -- what patch did you use? Strange numbers appear as each keypress gives you two increments/decrements in brightness. Check how many events do you receive from single key press.
I just explained you twice, how commenting out this if-statement affects video and 
fn keys, you seem to ignore these explanations. 

OK, I understand your explanation but I don`t understand one little thing from it:
>init of EC could be (and should be) done after all ACPI devices and regions
>are initialized. Patch from #9627 does exactly that.

OK I understand that.

>If patch is applied, "video" driver finds brightness controls and is able to
change it with /sys interface. It also disables BIOS control of the brightness,so function keys stop to work. If the patch is not applied, "video" driver is not able to attach and does not disable BIOS control over brightness.

I load a video.c as a module after I have a login prompt, after it I start X and I can`t control brightness. If I start X and then load video.c I can but in strange way. Where is the dependence from the acpi initialization sequence in that case? (I don`t load video.c module on kernel startup!)

>what patch did you use
I use second patch from bug #9627

>Strange numbers appear as each keypress gives you two
increments/decrements in brightness.

Yuor means that: 
when rise: 0 ,28, 56, 84, 100; when down: 100, 70, 42, 14, 0 ?

I can explain if in such way:
I make lowerest brightness
cat /sys/class/backlight/acpi_video0/actual_brightness
shows 0
than I press fn+br_up key and the previous command gives 28
and so up to the 100. Whei I down brightness I have got 100 then 70 and so on up to 0.
On my toshiba laptop only 0, 14, 28, 42, 56, 70, 84, 100 values in /sys/class/backlight/acpi_video0/brightness are valid.
So it jumps throught some values - it`s very inconvenient 

>Check how many events do you receive from single key press.
It`s very funny but there are NO EVENTS FROM FN KEYS!

Without patch (in 2.6.23 kernel for example and in .24-rc7 without patch) each fn+fx key generate one event on press and one on raise, but now... 

So one more question:
> It also disables BIOS control of the brightness,so function keys stop to work
Is it normal than all fn keys stops to work?

Without patch atkbd.c generates messages about pressing of keys with unknown keycode, with pacth there are no event`s even in 
drivers/input/serio/i8042.c:
static irqreturn_t i8042_interrupt(int irq, void *dev_id)
In normal case the call sequence is:
---->
drivers/input/serio/serio.c:
irqreturn_t serio_interrupt(struct serio *serio,
                unsigned char data, unsigned int dfl)
---------->
drivers/input/keyboard/atkbd.c
static irqreturn_t atkbd_interrupt(struct serio *serio, unsigned char data,
                        unsigned int flags)
/this function in .23 kernel generates messages about unknown key codes fo fn
keys using printk()/

the 
drivers/input/serio/i8042.c:
static irqreturn_t i8042_interrupt(int irq, void *dev_id)
is registered in the kernel via request_irq() - I think this is fundamental.

So, from your previous explanation I don`t undertand (I hasn`t ignore it, please don`t thik so, I`m a beginner in linux kernel hacking and don`t understand many things, mabye obvious things) why all fn keys (not only brightness control) stops to generate any events (interupts that could be cathed by keyboard driver - i8042.c)?

Ok, could you please give symptoms sorted:
1. plain 2.6.24-rc7 
2. 2.6.24-rc7 and commented out "if(..._INI) section"
3. 2.6.24-rc7 and patch from bug #9627

Yes I can.
1) plain 2.6.24-rc7
fn+fx generates no events (I thing interupts). I decided so because 
drivers/input/serio/i8042.c:
static irqreturn_t i8042_interrupt(int irq, void *dev_id)
doesn`t call when I press fn or fn+fx keys.
I can control brightness via /sys (eching the correct value to brightness file)
fn brightness keys does`n work under X. Reload video module solve this but keys jumping throught some values.

2) 2.6.24-rc7 and commented out "if(..._INI) section"
fn+fx generates events (I thing interupts). I decided so because 
drivers/input/serio/i8042.c:
static irqreturn_t i8042_interrupt(int irq, void *dev_id)
calls when I press fn or fn+fx keys.
I can`t control brightness via /sys (eching the correct value to brightness file does nothing)
fn brightness keys works under X. But after eching to the brightness file changing process begins from that value. I can see the current brightness level vie actual_brightness file

3) 2.6.24-rc7 and patch from bug #9627
same as 1)

By events I mean either /proc/acpi/events or uinput events. i8042 is a keyboard controller and should not work here (thus it's interrupts should not appear).
Please read bug #9262 it seems to describe same symptoms as yours, and was the reason why "if (_INI)" block was inserted.

I haven`t got any events in /proc/acpi/events nor with patc nor without patch.
What do you mebb under uinput events?

Ok, according to your DSDT, brightness events come as _Q07 and _Q10, as well as _Q11 and _Q12. You could check if they are sent by inserting printk("%x",value) to
acpi_ec_gpe_query() in ec.c:499. If everything go smooth, it should call acpi_video_device_notify() in video.c with either ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS
or ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS. You could trace it from there...

Created attachment 14443 [details]
The patch for video.c driver that solve the part of a problem

So there is a patch that solve main probem:
fn keys and software control works togeyher.

But there is one more problem, tha I don`t understand yet:
when acpi_video_device_notify() call acpi_bus_generate_proc_event() something
from this call acpi_video_set_brightness(). But it isn`t a catastrophe but it`s parametr bd->props.brightness has old value of brightness, and it immediately reseted back - so fn keys seems not to work... So question:
From where acpi_video_set_brightness() calls in than case?
How I can ajust the value than will be passed as it`s argument from acpi_video_device_lcd_set_level()?

With this patch fn keys works well. /proc interface works well (without _INI /proc also didn`t work), but /sys interface works only for read. echo [smth] > /sys/.../brightness will not work, yet I think.

This patch also resolve the problem with jumping throught the values when I use fn keys.

I`m waiting for your suggestions about remaining problem.

Only one dissapointment remain - other fn keys now haven`t got any events...Mabye there is a way to switch them on?

Re-assign bug to maintainer of acpi-video. 

Hi, Mihail,
Let's repeat the current symptom of your laptop:
1. proc I/F for brightness control works for you.
2. When pressing hotkeys, brightness level changes as expected.
3. sys I/F doesn't work.

Right?
Please revert the patch in comment#32 and apply the patch in comment#11 bug#9277.
For issue 3, please make sure the value you set must be one of those gotton from /proc/acpi/video/GFX0/DD02/brightness.

I alredy have applied the patch in comment#11 (As far as I understand this patch is already in .24-rc8)
With this patch I
1) can control brightness via /proc and /sys
2) I can`t use fn keys - theq does`t work
Without this patch I
1) can not control brightness vi /sys or /proc (Only can see current value, but I can not set it)
2) I can use fn keys

In comment#32 I have post some piece of code that allow me to use fn keys and to control brightness via /proc (not /sys) in the same time.

On my machine there is two problems with video.c acpi driver, when patch from comment#11 installed:
1) When I press fn key acpi_video_device_notify() with right event. So sequence fo brightness correction called and brightness changes. BUT when from acpi_video_device_notify() calls acpi_bus_generate_proc_event() something hapens and, as result, acpi_video_set_brightness() calls with previous value of brightness. As result nothing happens with brightness. And fn keys doesn`t works. I have traced all this calls, by addin printk functon.

I can`t understand where  is  there acpi_video_set_brightness()  call with old value of brightness. I simply disabled this call in my patch, by changing function parametr. This is not a good idea.

2) When video.c calculates next brightness level on my laptop it does it not in right way. The _BQC method already return next not current level! So it skip some levels. I don`t know is it bug of driver or of my notebook... In my patch I have fixed this for me. I don`t know how it will be work on different machines.

>For issue 3, please make sure the value you set must be one of those gotton
from /proc/acpi/video/GFX0/DD02/brightness.
Yes it is from the list.

>1) When I press fn key acpi_video_device_notify() with right event...
Maybe a user space script is monitoring the ACPI events and poking the brightness switch I/F.
Please re-do the test with acpid killed.

Created attachment 14539 [details]
patch: return current brightness level gotton from _BQC

>The _BQC method already return next not current level
Weird, are you sure of this?
Please
1. apply this patch
2. echo 70 > /proc/.../brightness;
3. attach the result of "cat /proc/acpi/.../brightness"

Zhang
At first when I kill acpid I can control brightness both via /proc /sys and fn keys. So as I use debian unstable mabye problem not in kernel... There is many stranges in unstable debian now.

>Weird, are you sure of this?
YES! IN THIS FACT I AM SURE AT ALL 100%
I check it in different configurations on two different lapop of the same model - toshiba U300-13M. Resume - _BQC method already return next not current level when I use fn keys!

There is a sequence of brightness levels when I use fn keys to change brightness from the lowest to higest and to lowest level: (yoyr patch was applied to the vanilla .24-rc8 kernel, my patch wasn`t applied)
MISHA1:/usr/src# cat /proc/acpi/video/GFX0/DD02/brightness
levels:  100 42 0 14 28 42 56 70 84 100
current: 0
MISHA1:/usr/src# cat /proc/acpi/video/GFX0/DD02/brightness
levels:  100 42 0 14 28 42 56 70 84 100
current: 28
MISHA1:/usr/src# cat /proc/acpi/video/GFX0/DD02/brightness
levels:  100 42 0 14 28 42 56 70 84 100
current: 56
MISHA1:/usr/src# cat /proc/acpi/video/GFX0/DD02/brightness
levels:  100 42 0 14 28 42 56 70 84 100
current: 84
MISHA1:/usr/src# cat /proc/acpi/video/GFX0/DD02/brightness
levels:  100 42 0 14 28 42 56 70 84 100
current: 100
MISHA1:/usr/src# cat /proc/acpi/video/GFX0/DD02/brightness
levels:  100 42 0 14 28 42 56 70 84 100
current: 70
MISHA1:/usr/src# cat /proc/acpi/video/GFX0/DD02/brightness
levels:  100 42 0 14 28 42 56 70 84 100
current: 42
MISHA1:/usr/src# cat /proc/acpi/video/GFX0/DD02/brightness
levels:  100 42 0 14 28 42 56 70 84 100
current: 14
MISHA1:/usr/src# cat /proc/acpi/video/GFX0/DD02/brightness
levels:  100 42 0 14 28 42 56 70 84 100
current: 0

2. echo 70 > /proc/.../brightness;
3. attach the result of "cat /proc/acpi/.../brightness"
I have 
levels:  100 42 0 14 28 42 56 70 84 100
current: 70
and what we have from it? The echo xxx > /... works well since the _INI method was added.

Created attachment 14566 [details]
DSDT

Just for fun. There is my ACPI DSDT that I have dissassembled. You can see how _BQC method realised on my laptop...

(In reply to comment #39)
> At first when I kill acpid I can control brightness both via fn keys.
> when I use fn keys!
> There is a sequence of brightness levels when I use fn keys to change
> brightness from the lowest to higest and to lowest level: (yoyr patch was
> applied to the vanilla .24-rc8 kernel, my patch wasn`t applied)
> MISHA1:/usr/src# cat /proc/acpi/video/GFX0/DD02/brightness
> levels:  100 42 0 14 28 42 56 70 84 100
> current: 0
...
> MISHA1:/usr/src# cat /proc/acpi/video/GFX0/DD02/brightness
> levels:  100 42 0 14 28 42 56 70 84 100
> current: 0
You said you can control the brightness via fn keys.
so this is done with acpid killed, right?
It seems that there are two acpi events for a fn key press, or one acpi event but it is handled twice, one in acpi video driver, and another in userspace.
And sure maybe you're right that _BQC returns the next brightness level.
Let's debug further.

> 2. echo 70 > /proc/.../brightness;
> 3. attach the result of "cat /proc/acpi/.../brightness"
> I have 
> levels:  100 42 0 14 28 42 56 70 84 100
> current: 70
With my patch applied, cat /proc/.../brightness will return the brightness level gotton from _BQC.
This suggest that the _BQC method return the correct brightness level rather than the next not current level.

Mihail,
can you please add a debug message at the beginning of acpi_video_device_lcd_set_level:
+       dump_stack();
+       printk("DEBUG: acpi_video_device_lcd_set_level: %d\n", level);
and attach the dmesg output after you press the fn keys for _ONE_ time.
There should be two debug messages if the brightness levels is changed twice.

Yes I can.
>This suggest that the _BQC method return the correct brightness level rather
than the next not current level.
NO you don`t ynderstand me. In the case of use cat /sys/..../actual_brightness op /proc/acpi/..../brightness the _BQC returns the current correct brightness, but... When I press fn key the value that _BQC returns is already next brightness level! So TOSHIBA acpi DSDT change brightness value prior  to acpi_video_device_notify() calls in linux kernel. I say only that when fn key pressed _BQC return next level, and only in that case.

I try to prove my position by results of dmesg with debug messages, but it  will take some time, because I try OpenSUSE 10.3 to understand the acpid role in that process. 

hi, Mihail,
sorry for the late response, does the problem still exist in a later kernel?
Please do the test in comment#41.

Please set CONFIG_ACPI_DEBUG,
echo 0x044 > /sys/module/acpi/parameters/debug_layer
echo 0x8800001f > /sys/module/acpi/parameters/debug_level
there should be some messages when an ACPI interrupts is fired.
Please press the hotkey and see what happens.
Please attach the dmesg output after this test.

Close it due to no response from the bug reporter.