On Fri, 2008-02-22 at 18:10 +, Matthew Garrett wrote:
On Fri, Feb 22, 2008 at 03:07:42PM +0100, Thomas Renninger wrote:
So to what Windows version are we compatible?
Microsoft has been very good at keeping backwards compatibility for this
functionality, so the obvious aim is to be
On Wed, 2008-02-20 at 17:32 +, Matthew Garrett wrote:
Let's look at this differently. Most hardware is produced by vendors who
don't care about Linux. We need to make that hardware work anyway. The
only way we can achieve that is to be bug-compatible with Windows.
Therefore, any way in
On Fri, Feb 22, 2008 at 03:07:42PM +0100, Thomas Renninger wrote:
So to what Windows version are we compatible?
Microsoft has been very good at keeping backwards compatibility for this
functionality, so the obvious aim is to be compatible with the current
version of Windows and all previous
On Thursday 21 February 2008 12:15, Theodore Tso wrote:
On Thu, Feb 21, 2008 at 04:41:21PM +0100, Thomas Renninger wrote:
OEMs that really want to modify the BIOS to recognize
OS interfaces that are in Linux should propose
new OSI strings that specify interfaces, not broad
categories
Thomas,
Thanks for the note.
Please read the messages on linux-acpi with dmi in the subject
for some background.
yes, OSI(Linux) was enabled by default through 2.6.22
and was disabled by default starting in 2.6.23.
The reason it has come up recently is because
it got into a reference BIOS -- and
On Thu, Feb 21, 2008 at 12:13:24AM -0300, Henrique de Moraes Holschuh wrote:
On Wed, 20 Feb 2008, Matthew Garrett wrote:
It doesn't punish them. They're the ones who are going to work with us
to ensure that Linux works on their hardware, and their needs are going
And since when we have
On Thu, Feb 21, 2008 at 09:15:32AM +, Matthew Garrett wrote:
Offering OSI(Linux) makes a statement about our implementation - we're
telling the firmware that it behaves in a certain way. That lets vendors
start depending on that behaviour, and if that behaviour turns out to be
On Thu, Feb 21, 2008 at 08:51:32AM -0500, Theodore Tso wrote:
It would be much better if we define feature-specific OSI() strings
that have well defined meanings for each place where Lenovo has to do
something different than What Happens With Windows --- especially for
stuff which is generic,
On Thu, Feb 21, 2008 at 05:48:33PM +0300, Alexey Starikovskiy wrote:
How about WMI?
Do you think that there will be some point in the future,
when we could claim that our WMI implementation is the
same as Windows + HW manufacturer private driver?
When vendors require custom drivers, we're
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 08:51:32AM -0500, Theodore Tso wrote:
It would be much better if we define feature-specific OSI() strings
that have well defined meanings for each place where Lenovo has to do
something different than What Happens With Windows --- especially
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 05:48:33PM +0300, Alexey Starikovskiy wrote:
How about WMI?
Do you think that there will be some point in the future,
when we could claim that our WMI implementation is the
same as Windows + HW manufacturer private driver?
When vendors
On Thursday 21 February 2008 09:41:13 you wrote:
Thomas,
Thanks for the note.
Please read the messages on linux-acpi with dmi in the subject
for some background.
Can you be a bit more specific. Grepping for dmi is a bit verbose on the
linux-acpi list.
yes, OSI(Linux) was enabled by default
On Thu, 21 Feb 2008, Sergio Monteiro Basto wrote:
On Thu, 2008-02-21 at 00:13 -0300, Henrique de Moraes Holschuh wrote:
On Wed, 20 Feb 2008, Matthew Garrett wrote:
It doesn't punish them. They're the ones who are going to work with us
to ensure that Linux works on their hardware, and
On Thu, Feb 21, 2008 at 04:41:21PM +0100, Thomas Renninger wrote:
The bug is rather complicated to fix/workaround through the OS (E.g. suspend
reordering, AML bug, you simply misread the ACPI spec and it did work for
Windows (the ACPI kernel maintainer likes to add the compatibility hack,
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
On Wed, 20 Feb 2008, Tomas Carnecky wrote:
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:
No, I haven't. Len is the mastermind behind it, AFAIK. I am
On Wed, 2008-02-20 at 11:31 +0100, Tomas Carnecky wrote:
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
On Wed, 20 Feb 2008, Matthew Garrett wrote:
Let's look at this differently. Most hardware is produced by vendors who
don't care about Linux. We need to make that hardware work anyway. The
only way we can achieve that is to be bug-compatible with Windows.
Therefore, any way in which Linux
On Wed, 2008-02-20 at 17:32 +, Matthew Garrett wrote:
Let's look at this differently. Most hardware is produced by vendors who
don't care about Linux. We need to make that hardware work anyway.
Not really. If you buy machine noname XY, you have to face the fact that
HW may not work on Linux
On Wed, Feb 20, 2008 at 07:21:57PM +0100, Thomas Renninger wrote:
On Wed, 2008-02-20 at 17:32 +, Matthew Garrett wrote:
Let's look at this differently. Most hardware is produced by vendors who
don't care about Linux. We need to make that hardware work anyway.
Not really. If you buy
On Wed, Feb 20, 2008 at 03:23:40PM -0300, Henrique de Moraes Holschuh wrote:
On Wed, 20 Feb 2008, Matthew Garrett wrote:
Let's look at this differently. Most hardware is produced by vendors who
don't care about Linux. We need to make that hardware work anyway. The
only way we can achieve
On Thu, 2008-02-21 at 00:13 -0300, Henrique de Moraes Holschuh wrote:
On Wed, 20 Feb 2008, Matthew Garrett wrote:
It doesn't punish them. They're the ones who are going to work with us
to ensure that Linux works on their hardware, and their needs are going
And since when we have to work
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
23 matches
Mail list logo
