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
>
> 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, 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 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 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: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
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, 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
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
12 matches
Mail list logo
