>
> Read the changelog and thread on the patch that disabled this logic, the
> failure (or at least inconsistent behaviour with the expectations of the
> HP BIOS authors) appears to be in how we initialise ACPI on the HP
> machines that causes the initial value of lid state to be incorrect. Since
>
On Wed, Mar 16, 2011 at 2:26 AM, Indan Zupancic wrote:
> On Wed, March 16, 2011 03:17, Alex Deucher wrote:
>> It's not HDCP, encrypted bluray is the main issue. ?And while
>> there are hacks for bluray around already, contractual obligations
>> don't care whether existing hacks are available or no
On Wed, March 16, 2011 03:17, Alex Deucher wrote:
> It's not HDCP, encrypted bluray is the main issue. And while
> there are hacks for bluray around already, contractual obligations
> don't care whether existing hacks are available or not.
So the contract says to keep it secret, not to make it se
On Wed, Mar 16, 2011 at 2:26 AM, Indan Zupancic wrote:
> On Wed, March 16, 2011 03:17, Alex Deucher wrote:
>> It's not HDCP, encrypted bluray is the main issue. And while
>> there are hacks for bluray around already, contractual obligations
>> don't care whether existing hacks are available or no
On Tue, March 15, 2011 17:06, Alex Deucher wrote:
> On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic wrote:
>> They don't give their Linux devs any Fusion hardware, nor do they
>> open the UVD spec, but at least they release info like this.
>
> They do give us fusion hw; before launch even. That's
On Wed, March 16, 2011 03:17, Alex Deucher wrote:
> It's not HDCP, encrypted bluray is the main issue. And while
> there are hacks for bluray around already, contractual obligations
> don't care whether existing hacks are available or not.
So the contract says to keep it secret, not to make it se
On Tue, Mar 15, 2011 at 8:02 PM, Indan Zupancic wrote:
> On Tue, March 15, 2011 17:06, Alex Deucher wrote:
>> On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic wrote:
>>> They don't give their Linux devs any Fusion hardware, nor do they
>>> open the UVD spec, but at least they release info like thi
>
> Read the changelog and thread on the patch that disabled this logic, the
> failure (or at least inconsistent behaviour with the expectations of the
> HP BIOS authors) appears to be in how we initialise ACPI on the HP
> machines that causes the initial value of lid state to be incorrect. Since
>
On Tue, Mar 15, 2011 at 8:02 PM, Indan Zupancic wrote:
> On Tue, March 15, 2011 17:06, Alex Deucher wrote:
>> On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic wrote:
>>> They don't give their Linux devs any Fusion hardware, nor do they
>>> open the UVD spec, but at least they release info like thi
On Tue, March 15, 2011 17:06, Alex Deucher wrote:
> On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic wrote:
>> They don't give their Linux devs any Fusion hardware, nor do they
>> open the UVD spec, but at least they release info like this.
>
> They do give us fusion hw; before launch even. That's
On Tue, Mar 15, 2011 at 01:32:40PM +, Matthew Garrett wrote:
> Opregion is one mechanism to provide VBT - it doesn't define it.
Then let me repeat that I haven't seen anything in the VBT tables of
the gma500-using netbook I have that didn't seem to be parsed
correctly by the current gpu/drm/i9
On Tue, Mar 15, 2011 at 01:52:26AM +, Matthew Garrett wrote:
> Now that we've got multiple consumers it's probably not helpful to move
> the (potentially chip-specific) VBT handling to general code. We've got
> zero documentation on how GMA500 handles VBT, and not a great deal more
> for i91
On Tue, Mar 15, 2011 at 02:40:59PM +0100, Olivier Galibert wrote:
> On Tue, Mar 15, 2011 at 01:32:40PM +, Matthew Garrett wrote:
> > Opregion is one mechanism to provide VBT - it doesn't define it.
>
> Then let me repeat that I haven't seen anything in the VBT tables of
> the gma500-using netb
On Tue, Mar 15, 2011 at 02:30:55PM +0100, Olivier Galibert wrote:
> On Tue, Mar 15, 2011 at 01:52:26AM +, Matthew Garrett wrote:
> > Now that we've got multiple consumers it's probably not helpful to move
> > the (potentially chip-specific) VBT handling to general code. We've got
> > zero doc
On Tue, March 15, 2011 12:27, Peter Stuge wrote:
> coreboot has existed for about eleven years and some 250 mainboards of
> varying shapes and sizes (from laptop to server) are supported, but it's
I've been wanting to get rid of BIOSes and use Coreboot for ages,
but the amount of hassle needed to
Indan Zupancic wrote:
> Everything would be a lot simpler if the BIOSes were open source.
coreboot has existed for about eleven years and some 250 mainboards of
varying shapes and sizes (from laptop to server) are supported, but it's
only just recently that things are really taking off, with the c
On Tue, March 15, 2011 09:37, Chris Wilson wrote:
> On Tue, 15 Mar 2011 02:18:02 +0100 (CET), "Indan Zupancic"
> wrote:
>> Hello,
>>
>> Some nitpicks below.
>>
>> On Mon, March 14, 2011 18:59, Chris Wilson wrote:
>> > Note: neither the opregion_dev interface or the alse_set_* properly report
>> >
On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic wrote:
> On Tue, March 15, 2011 12:27, Peter Stuge wrote:
>> coreboot has existed for about eleven years and some 250 mainboards of
>> varying shapes and sizes (from laptop to server) are supported, but it's
>
> I've been wanting to get rid of BIOSes
On Tue, Mar 15, 2011 at 7:46 AM, Indan Zupancic wrote:
> On Tue, March 15, 2011 12:27, Peter Stuge wrote:
>> coreboot has existed for about eleven years and some 250 mainboards of
>> varying shapes and sizes (from laptop to server) are supported, but it's
>
> I've been wanting to get rid of BIOSes
On Tue, 15 Mar 2011 02:18:02 +0100 (CET), "Indan Zupancic"
wrote:
> Hello,
>
> Some nitpicks below.
>
> On Mon, March 14, 2011 18:59, Chris Wilson wrote:
> > Note: neither the opregion_dev interface or the alse_set_* properly report
> > failures. As such we have a slight change in behaviour on
On Tue, Mar 15, 2011 at 01:32:40PM +, Matthew Garrett wrote:
> Opregion is one mechanism to provide VBT - it doesn't define it.
Then let me repeat that I haven't seen anything in the VBT tables of
the gma500-using netbook I have that didn't seem to be parsed
correctly by the current gpu/drm/i9
On Tue, Mar 15, 2011 at 01:52:26AM +, Matthew Garrett wrote:
> Now that we've got multiple consumers it's probably not helpful to move
> the (potentially chip-specific) VBT handling to general code. We've got
> zero documentation on how GMA500 handles VBT, and not a great deal more
> for i91
On Tue, Mar 15, 2011 at 02:40:59PM +0100, Olivier Galibert wrote:
> On Tue, Mar 15, 2011 at 01:32:40PM +, Matthew Garrett wrote:
> > Opregion is one mechanism to provide VBT - it doesn't define it.
>
> Then let me repeat that I haven't seen anything in the VBT tables of
> the gma500-using netb
On Tue, Mar 15, 2011 at 02:30:55PM +0100, Olivier Galibert wrote:
> On Tue, Mar 15, 2011 at 01:52:26AM +, Matthew Garrett wrote:
> > Now that we've got multiple consumers it's probably not helpful to move
> > the (potentially chip-specific) VBT handling to general code. We've got
> > zero doc
On Tue, March 15, 2011 12:27, Peter Stuge wrote:
> coreboot has existed for about eleven years and some 250 mainboards of
> varying shapes and sizes (from laptop to server) are supported, but it's
I've been wanting to get rid of BIOSes and use Coreboot for ages,
but the amount of hassle needed to
Indan Zupancic wrote:
> Everything would be a lot simpler if the BIOSes were open source.
coreboot has existed for about eleven years and some 250 mainboards of
varying shapes and sizes (from laptop to server) are supported, but it's
only just recently that things are really taking off, with the c
On Tue, March 15, 2011 09:37, Chris Wilson wrote:
> On Tue, 15 Mar 2011 02:18:02 +0100 (CET), "Indan Zupancic"
> wrote:
>> Hello,
>>
>> Some nitpicks below.
>>
>> On Mon, March 14, 2011 18:59, Chris Wilson wrote:
>> > Note: neither the opregion_dev interface or the alse_set_* properly report
>> >
Hello,
Some nitpicks below.
On Mon, March 14, 2011 18:59, Chris Wilson wrote:
> From: Matthew Garrett
>
> The Integrated Graphics Device opregion specification defines a mechanism
> for the OS and system firmware to collaborate on various graphics-related
> functionality. This is currently imple
On Tue, Mar 15, 2011 at 02:18:02AM +0100, Indan Zupancic wrote:
> > +
> > + if (dev->set_backlight)
> > + dev->set_backlight(dev->drm_dev, bclp * max / 255);
>
> I would hide the max backlight from the opregion code and move this
> calculation into set_brightness. Then change the inter
On Tue, 15 Mar 2011 02:18:02 +0100 (CET), "Indan Zupancic" wrote:
> Hello,
>
> Some nitpicks below.
>
> On Mon, March 14, 2011 18:59, Chris Wilson wrote:
> > Note: neither the opregion_dev interface or the alse_set_* properly report
> > failures. As such we have a slight change in behaviour on I
On Tue, Mar 15, 2011 at 02:18:02AM +0100, Indan Zupancic wrote:
> > +
> > + if (dev->set_backlight)
> > + dev->set_backlight(dev->drm_dev, bclp * max / 255);
>
> I would hide the max backlight from the opregion code and move this
> calculation into set_brightness. Then change the inter
Hello,
Some nitpicks below.
On Mon, March 14, 2011 18:59, Chris Wilson wrote:
> From: Matthew Garrett
>
> The Integrated Graphics Device opregion specification defines a mechanism
> for the OS and system firmware to collaborate on various graphics-related
> functionality. This is currently imple
From: Matthew Garrett
The Integrated Graphics Device opregion specification defines a mechanism
for the OS and system firmware to collaborate on various graphics-related
functionality. This is currently implemented in the i915 driver but isn't
strictly limited to these devices. Move it to a more
From: Matthew Garrett
The Integrated Graphics Device opregion specification defines a mechanism
for the OS and system firmware to collaborate on various graphics-related
functionality. This is currently implemented in the i915 driver but isn't
strictly limited to these devices. Move it to a more
34 matches
Mail list logo
