Re: 2.6.25-rc2 Regression Thinkpad acpi
Lukas Hejtmanek wrote: On Mon, Feb 25, 2008 at 06:01:13PM -0300, Henrique de Moraes Holschuh wrote: Not even over the new netlink socket? Or the thinkpad-acpi input device? how can I check this? A while ago I worked on a new acpi daemon that could receive events from both netlink and /dev/input devices. Right now it's more like a testing tool then a real replacement for the current acpid. I haven't had time to work on it. http://git.dbservice.com/?p=acpid;a=summary $ git clone git://dbservice.com/acpid You'll need dbus and lua to compile it. There's also a readme that describes how to get it running and how it works. In its default configuration it will print the events into stdout. tom - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
Thomas Renninger wrote: Hi, please correct me if I am wrong or missed something: osi=linux was an ability for vendors to provide Linux specific BIOS updates/quirks. _OSI(Linux) returned true until kernel version 2.6.23 (included?). This has been replaced by rather huge black+white lists (at least they most probably will grow huge) to get rid of it again. Goal is to not return _OSI(Linux) as Intel identified it (after inventing it? Doesn't really matter...) as not the right thing to do as it does not consider fixes that might show up in specific kernel versions in the future. This is the only reason I found, did I miss one or the other? Linux is way too generic. The kernels is such fast moving target that changes with every other version. The idea is to replace _OSI(Linux) with _OSI(Needs video POST after resume) etc. To allow the BIOS to figure out what _exactly_ it needs to do, rather then guessing based on the kernels version etc. A lot has been discussed in linux-acpi, though mostly hidden in related threads. Ask Henrique, he's been trying to come up with a proper _OSI() interface. See for example this thread: http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg12262.html The idea to remove _OSI(Linux) it to get the hardware vendors to stop using it _now_, we don't want them to use it any longer. It will take some time to come up with a proper interface, but at least we'll have less legacy to deal with. Some questions and suggestions: Is there already a replacement or will there pop up something soon, which I may have missed? This is an interface to the outside world (out of the kernel... in this case not to userspace via /proc /sys ioctl, but to the BIOS). Such interfaces should have a very long lifetime, once they are implemented. In this case it should have an even much longer life time than any /sys or whatever userspace interface. Telling vendors that this will vanish and giving them time to remove it from their BIOSes or better replace it with something else is the way to go here IMO. The current policy is to just return zero on _OSI(Linux). I don't get it why you do this. You break machines on purpose. Machines were vendors possibly have invested time to improve them for Linux. Why don't you just announce it, write it down in Documentation, also write it to dmesg, instead of pls send acpidump to acpi list, something like: osi=linux is deprecated and will get removed (ok there popped up a way too much of these, but maybe dmiblacklist the message, don't do any functional change for now...). Maybe that just didn't get outside of the linux-acpi mailinglist, but that that _OSI(Linux) is deprecated has been known for some time now. But you are right, it was never publicly announced. First users were asked to try acpi_osi=!Linux (sometime in the .23/.24 timeframe?)and see if it works better. Now !Linux is default, and they are asked to try acpi_osi=Linux so that we can fill the blacklist. Why shouldn't I remove the whole dmi black/white listing from our OpenSUSE kernel and return true for _OSI(Linux), this probably fixes a lot machines and avoids bug reports (and annoyed users). I plan to do this rather soon if I don't get some good arguments. IMO this should also be done mainline. It is a pity that 2.6.24 now has this. IMO this should even go back to a 2.6.24.X stable kernel. Just let it in and announce to not use it and provide something else (this has time then...). --- Here a suggestion for an enhanced Linux Operation System Identification interface for ACPI: For general BIOS hot-fixes a check for osi=linux is sufficient for vendors and allows them to provide a fix without risking breakage of their Windows OS. This one should stay. No, it's not sufficient, it's useless. Linux - what should that stand for? How should the BIOS vendors interpret it? It's totally ambiguous. It was removed, and should stay removed. BIOS can do _OSI(Windows 2006) because Windows 2006 defines a non-moving target. MS will not change how Vista behaves without changing the string (they sometimes update the string in service packs). The problem is you do not know in what kernel version this might get fixed at the time the BIOS is published with the short term workaround. While this knob is essential for vendors for pre-loads, it might break the machine if the user is trying to install a newer Linux distribution with a newer Kernel where the problem got fixed. Then the workaround might even slow down or break the system... An example: Lenovo wants to get rid of brightness switching via their old method (int10?). But this needs in-kernel graphics driver support for Intel graphics cards. Therefore ibm_acpi currently simulates this, the specified ACPI brightness interface cannot be used. In which kernel version in-kernel graphics drivers will be supported and Lenovo can safely throw out int10 brightness switching from their BIOSes is not known yet. I
Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61
Len Brown wrote: I am okay with defining OSI strings for the benefit of BIOS vendors that need to know about Linux capabilities. But the string must identify that specific capability (or lack of a capability). Is there a chance this will be added to future ACPI specs, or have it standardized in one way or another? I think that would be not only good for Linux, but all other UNIX-like operating systems as well (and maybe Windows as well). Not that I care, really, but for me as an outsider to the whole ACPI domain, it seems _OSI() isn't a well thought out interface. Checking for an OS name rather than individual capabilities may not matter as much under Windows, but for Linux, with its rather short release cycle, it certainly does. tom - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ACPI: add DMI to enable OSI(Linux) on ThinkPad T61
Len Brown wrote:
On Sunday 20 January 2008 07:03, Tomas Carnecky wrote:
Len Brown wrote:
I am okay with defining OSI strings for the benefit of BIOS vendors that
need to know about Linux capabilities. But the string must
identify that specific capability (or lack of a capability).
Is there a chance this will be added to future ACPI specs, or have it
standardized in one way or another? I think that would be not only good
for Linux, but all other UNIX-like operating systems as well (and maybe
Windows as well).
Not that I care, really, but for me as an outsider to the whole ACPI
domain, it seems _OSI() isn't a well thought out interface. Checking for
an OS name rather than individual capabilities may not matter as much
under Windows, but for Linux, with its rather short release cycle, it
certainly does.
Originally, there was _OS=insert your OS name to identify the OS to the
BIOS.
We proudly answered _OS=Linux and broke every BIOS on Earth
that assumed that the only two choices for _OS
which corresponded to Win98 and WinNT.
That is why _OS=Microsoft Windows NT is hardwired
into Linux and any other OS that is concerned about
following what has proven to be the only tested
path through the BIOS.
So naming the OS turned out to be a failure (for everybody,
not just for Linux -- consider that XP and Vista claim they are NT
according to _OS or they hit the same BIOS bugs we do...)
_OSI is supposed to tell the BIOS what interfaces the OS supports,
for example Extended Address Space Descriptor.
However, it is being mis-used to identify the
version of the OS, which is why you see this:
static char *acpi_interfaces_supported[] = {
/* Operating System Vendor Strings */
Windows 2000, /* Windows 2000 */
Windows 2001, /* Windows XP */
Windows 2001 SP1, /* Windows XP SP1 */
Windows 2001 SP2, /* Windows XP SP2 */
Windows 2001.1, /* Windows Server 2003 */
Windows 2001.1 SP1, /* Windows Server 2003 SP1 - Added 03/2006 */
Windows 2006, /* Windows Vista - Added 03/2006 */
ie. basically the OS name is a proxy for all the interfaces
that OS supports. Taken another way, OS-version-specific quirks
and workarounds are included in the definition of that interface...
So _OSI _is_ a good interface, it's just being misused. Thanks for the
explanation.
We could do the same with Linux, except that
1. the string Linux is even more poorly defined than those above,
as it has no version information.
Who came up with the idea to use Linux? After what you described
above, this seems even worse choice then what Windows does - they at
least have some information about the version in it.
2. the presence of the string Linux tends to break as many BIOS'
implementations as it fixes -- because it isn't universally tested.
So if new strings come up in the ACPI spec, we can use standard strings.
But I don't think the ACPI spec is necessary to address Linux'
problem-at-hand.
After what you explained above, I don't think either, the ACPI spec is ok.
We as the Linux community can define Needs BIOS S3 video restore as a string
and ship it in our kernel, telling BIOS writers about it.
However, we'd reserve the right to _stop_ answering YES to a query on that
string
when we no longer need it.
Still, it would be nice to have these strings somehow standardized.
Maybe Intel and other vendors or BIOS developers come up with something
and document it properly, include some of the most important strings in
the ACPI spec? Because if Linux starts using some strings and Windows or
BSD different strings, there will surely be a mess - again.
tom
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: suspend to RAM failure on t61p
Andrew Morton wrote: 2.6.24-rc4 on a Lenovo t61p, using FC8 config. echo mem /sys/power/state while running X. It appears to suspend OK but then it instantly resumes and runs OK except the display is blank. http://bugzilla.kernel.org/show_bug.cgi?id=9258 I have a X61 tablet, and the screen is blank after resume, too, but pressing ctrl+alt+F1/F7 usually fixes it. It seems a problem with the X video driver. I'm not sure though. tom - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Announce] acpi daemon with support for netlink and evdev events
Oops, the link to the tarball: http://dbservice.com/ftpdir/tom/acpid-ng.tar.gz tom - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Announce] acpi daemon with support for netlink and evdev events
What is it? = An acpi deamon that processes events from various sources, passes these to scripts for further processing and also broadcasts dbus events. Currently it contains drivers for (generic-)netlink and evdev event sources. Configuration and event processing is done in Lua, a leightweight scripting language. How does it work? === Drivers are automatically registered into the daemon when the binary is loaded into memory. The main executable fist creates a Lua environment and then loads the event source configuration and the scripts which are invoked when an event is received. Each event source (called a channel) is defined by the driver, optional arguments and a function (callback). In the main function a loop polls on all fd's and waits for events. When a channel receives a new event, it is first passed to the channel callback which can perform modifications to the event. Then the event is passed to all scripts (which are really just Lua functions) in a well defined order. Each script can abort the execution at any point. In any case a dbus broadcast even is sent to the system bus. What needs to be done? Overall code cleanup, documentation/readme, error checking. Improve the Lua environment (currently only two useful functions are available), maybe add the Lua base functions (string, table, coroutine etc.). Consult with desktop developers if they need a particular functionality (better adjust the overall design now rather then trying to do it a hacky way later on). What features are missing? I had planed to integrate it more with dbus. One feature I think would be useful is the ability to schedule actions (as opposed to immediate invocation of scripts) and the ability to cancel those through dbus. One particular use-case would be when the user presses the 'sleep' button and the desktop is performing a task that really shouldn't be interrupted, then the desktop could cancel or delay the suspend-to-ram action. How do I use it? == A bit Lua knowledge is required for writing the scripts! To compile it you'll need dbus-1 and lua. Compile acpid with 'make', a sample client application with 'make all'. You'll need to start acpid as root as it needs to register a name with the system bus. Also make sure to copy the attached acpi.conf to /etc/dbus-1/system.d/. You may need to edit config.lua and scripts.lua, but it should work out of the box. Start acpid from the root directory of the source. If your computer now generates an acpi event, you should see some output in stdout. You can also start the client and it will also receive all events and print those to stdout as well. So where can I get the source? Sources are available in a tarball only. You'll see that it also contains a git repository. Once I figure out how to set up gitweb I'll be pushing the source to my server. Questions/Suggestions? Just send me an email. Nico, I saw your email to the LKML and I thought you might be interested in my project and source. tom PS: I'm not subscribed.. you know the drill. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
acpid and /proc/acpi/events
Now that /proc/acpi/events will soon be removed, are there any plans to port acpid to the evdev/netlink interfaces? thanks tom - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
