From: Tony Vroon <tony@linx.net>
To: nokos@gmx.net
Cc: Stephen Gildea <stepheng+linux@gildea.com>,
Julian Brown <jules@panic.cs-bristol.org.uk>,
linux-acpi@vger.kernel.org,
Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
Subject: Re: [PATCH 2.6.29] fujitsu-laptop: Add BL power, LED control and
Date: Sun, 04 Jan 2009 20:44:07 +0000 [thread overview]
Message-ID: <49611F97.6020601@linx.net> (raw)
In-Reply-To: <1231066111.10356.10.camel@earth.gruber.myown>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
nokos@gmx.net wrote:
> with ACPI_VIDEO:
> both alt and std interface works (SBLL/SBL2), but only while X is
> running (I think with ACPI_VIDEO all brighness change etc is handled by
> the IGD stuff in i915 which is only active if X is running)
Okay, perhaps kernel mode setting will improve this situation. As
userland isn't ready for KMS now I will back off on this and bring it up
again at around the 2.6.30/2.6.31 timeframe. (As I do agree things
should work correctly without X running)
> without ACPI_VIDEO:
> only alt interface changes brightness and it works regardless of X
On the current interface though, mind if I remove the distinction
between GBLL & GBLS? The only difference between them (that you already
noticed, based on code comments) is that GBLS does not clear GHKS. GHKS
is the "change caused by brightness keys" flag.
As a result you already have to override use_alt in 1 case.
A simplier way to autodetect (taking into account your next mail about
BLNF) would then be to see whether SBL2 exists, and use if it does.
(I've checked all other DSDTs that I have, SBL2 is unique to the S64XX
series).
My ultimate goal in this is to make the DMI-based recognition of
machines unnecessary, especially if BTNI turns out to be useful in
knowing the keymap.
> Peter
Regards,
Tony V.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklhH5cACgkQp5vW4rUFj5oSJwCfci3c42ogoUhi/Il99Oy8L3BV
07AAoK/qdg+NC35CyPH0H3b47H0VDecF
=xGab
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2009-01-04 20:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-31 18:19 [PATCH 2.6.29] fujitsu-laptop: Add BL power, LED control and radio state information Tony Vroon
2008-12-31 21:08 ` Len Brown
2009-01-02 2:06 ` [PATCH 2.6.29] fujitsu-laptop: Add BL power, Jonathan Woithe
2009-01-02 12:10 ` [PATCH 2.6.29] fujitsu-laptop: Add BL power, LED control and radio state information nokos
2009-01-03 22:37 ` [PATCH 2.6.29] fujitsu-laptop: Add BL power, LED control and Jonathan Woithe
2009-01-03 22:57 ` Tony Vroon
2009-01-04 10:48 ` nokos
2009-01-04 20:44 ` Tony Vroon [this message]
2009-01-04 22:40 ` Jonathan Woithe
2009-01-04 16:30 ` nokos
2009-01-04 0:14 ` Tony Vroon
2009-01-05 1:56 ` Jonathan Woithe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49611F97.6020601@linx.net \
--to=tony@linx.net \
--cc=jules@panic.cs-bristol.org.uk \
--cc=jwoithe@physics.adelaide.edu.au \
--cc=linux-acpi@vger.kernel.org \
--cc=nokos@gmx.net \
--cc=stepheng+linux@gildea.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox