http://bugzilla.kernel.org/show_bug.cgi?id=9724
------- Comment #26 from [EMAIL PROTECTED] 2008-01-13 10:13 -------
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)?
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
