On Mon, 14 Jan 2008, Matthew Garrett wrote:
> Userspace is in a better position to make this determination. Of course,
That's fine with me.
> this also means not passing the Linux OSI to the firmware. Our hardware
> interaction is sufficiently in flux that any attempt to work around it
> in th
On Sun, Jan 13, 2008 at 11:57:18PM -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 14 Jan 2008, Matthew Garrett wrote:
> > not going to want the low-level ACPI code to do anything video-related
> > on a lot of hardware. The in-kernel modesetting code for Intel machines
> > will be able to han
On Mon, 14 Jan 2008, Matthew Garrett wrote:
> On Mon, Jan 14, 2008 at 12:35:54AM +, Matthew Garrett wrote:
> > No. This breaks on the R50e, at least - I suspect it'd also have
> > problems on any nvidia based machines, but I don't have one to hand at
> > the moment. It can be set at runtime a
On Mon, Jan 14, 2008 at 12:35:54AM +, Matthew Garrett wrote:
> No. This breaks on the R50e, at least - I suspect it'd also have
> problems on any nvidia based machines, but I don't have one to hand at
> the moment. It can be set at runtime already.
Just to clarify this further, in the relat
On Sun, Jan 13, 2008 at 09:41:29PM -0200, Henrique de Moraes Holschuh wrote:
> On Sun, 13 Jan 2008, Pavel Machek wrote:
> > When linux calls video BIOS with lcall (acpi_sleep=s3_bios), they
> > should turn on backlight and put video into text mode. They should
> > also make sure mode setting works
A bit more on this issue. I have received a report that on a X61, it
actually works the opposite from the T61 and you need acpi_osi="!Linux" to
get the "mute" key to work.
Well, I am asking the users to track down exactly *where* the mute key is
comming from in each case (ACPI or keyboard control
On Sun, 13 Jan 2008, Pavel Machek wrote:
> > The reason it shoudl be turned off is that backlight enabling
> > backlight from a native graphics driver is much faster than running
> > through the video BIOS POST. So if we keep the OSI(Linux)
> > video BIOS POST workaround in place permanently, it w
On Sat 2008-01-12 04:16:08, Len Brown wrote:
> On Friday 11 January 2008 21:23, Henrique de Moraes Holschuh wrote:
> > While helping a user find out what happened to his mute key, I found out
> > that the Lenovo BIOSes need the OSI string Linux defined to behave properly
> > in Linux.
> >
> > Leno
On Sat, 12 Jan 2008, Len Brown wrote:
> > Lenovo has been attempting to make things a bit easier for Linux on their
> > ThinkPads, by disabling the more obnoxious behaviours of the firmware (used
> > by their Windows drivers) when in Linux. It looks like they used the OSI
> > string for that.
[..
> Now, what should we do about it? Add a quirk to always define the Linux OSI
> string on ThinkPads (based on DMI information)? All IBM ones (which won't
> have BIOS revisions anymore, anyway) deal well with it, and Lenovo ones
> seem to benefit from it.
If Lenovo systems do the right thing then
On Friday 11 January 2008 21:23, Henrique de Moraes Holschuh wrote:
> While helping a user find out what happened to his mute key, I found out
> that the Lenovo BIOSes need the OSI string Linux defined to behave properly
> in Linux.
>
> Lenovo has been attempting to make things a bit easier for Li
While helping a user find out what happened to his mute key, I found out
that the Lenovo BIOSes need the OSI string Linux defined to behave properly
in Linux.
Lenovo has been attempting to make things a bit easier for Linux on their
ThinkPads, by disabling the more obnoxious behaviours of the firm
12 matches
Mail list logo
