On Fri, Aug 10, 2012 at 05:19:48PM -0500, Seth Forshee wrote:
> First, I don't have a solution for the ordering of initialization. It
> just happens to work out for me right now.
Okay, I've got a proof-of-concept implementation of delaying secondary
GPU initialization until the i2c can be muxed ov
On Fri, Aug 10, 2012 at 05:19:48PM -0500, Seth Forshee wrote:
> First, I don't have a solution for the ordering of initialization. It
> just happens to work out for me right now.
Okay, I've got a proof-of-concept implementation of delaying secondary
GPU initialization until the i2c can be muxed ov
On Mon, Aug 06, 2012 at 07:44:16AM +1000, Dave Airlie wrote:
> >> The "correct" approach is clearly to just have the drm core change the
> >> i2c mux before requesting edid, but that's made difficult because of the
> >> absence of ordering guarantees in initialisation. I don't like quirking
> >> th
On Mon, Aug 06, 2012 at 07:44:16AM +1000, Dave Airlie wrote:
> >> The "correct" approach is clearly to just have the drm core change the
> >> i2c mux before requesting edid, but that's made difficult because of the
> >> absence of ordering guarantees in initialisation. I don't like quirking
> >> th
On Mon, Aug 06, 2012 at 01:23:17PM +0100, Matthew Garrett wrote:
> On Sun, Aug 05, 2012 at 11:40:16PM +0200, Daniel Vetter wrote:
>
> > As long as it's only apple shipping multi-gpu machines with
> > broken/non-existing vbt, I'll happily stomach the quirk list entries.
> > They're bad, but imo the
On Mon, Aug 06, 2012 at 01:23:17PM +0100, Matthew Garrett wrote:
> On Sun, Aug 05, 2012 at 11:40:16PM +0200, Daniel Vetter wrote:
>
> > As long as it's only apple shipping multi-gpu machines with
> > broken/non-existing vbt, I'll happily stomach the quirk list entries.
> > They're bad, but imo the
On Sun, Aug 05, 2012 at 11:40:16PM +0200, Daniel Vetter wrote:
> As long as it's only apple shipping multi-gpu machines with
> broken/non-existing vbt, I'll happily stomach the quirk list entries.
> They're bad, but imo the lesser evil.
Doing this via quirks means that we'll always be broken on t
On Mon, Aug 6, 2012 at 7:40 AM, Daniel Vetter wrote:
> On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote:
>> On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote:
>>
>> > I like this approach more - the only other solution I see is to ask the
>> > currently active driver (i.
On Sun, Aug 05, 2012 at 11:40:16PM +0200, Daniel Vetter wrote:
> As long as it's only apple shipping multi-gpu machines with
> broken/non-existing vbt, I'll happily stomach the quirk list entries.
> They're bad, but imo the lesser evil.
Doing this via quirks means that we'll always be broken on t
On Sun, Aug 05, 2012 at 07:20:31PM -0400, Alex Deucher wrote:
> On Sun, Aug 5, 2012 at 5:44 PM, Dave Airlie wrote:
> > On Mon, Aug 6, 2012 at 7:40 AM, Daniel Vetter wrote:
> >> On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote:
> >>> On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel
On Sun, Aug 05, 2012 at 07:20:31PM -0400, Alex Deucher wrote:
> On Sun, Aug 5, 2012 at 5:44 PM, Dave Airlie wrote:
> > On Mon, Aug 6, 2012 at 7:40 AM, Daniel Vetter wrote:
> >> On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote:
> >>> On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel
On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote:
> On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote:
>
> > I like this approach more - the only other solution I see is to ask the
> > currently active driver (i.e. radeon) at bootime for the right mode. Which
> > sounds
On Sat, Aug 04, 2012 at 11:57:27AM -0500, Seth Forshee wrote:
> On Fri, Aug 03, 2012 at 05:27:02PM +0100, Matthew Garrett wrote:
> > On Fri, Aug 03, 2012 at 11:24:51AM -0500, Seth Forshee wrote:
> >
> > > This is one of the things I wasn't so sure about. There are various
> > > checks in intel_lvd
On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote:
> I like this approach more - the only other solution I see is to ask the
> currently active driver (i.e. radeon) at bootime for the right mode. Which
> sounds much more hellish and fragile ...
The "correct" approach is clearly to jus
On Sun, Aug 5, 2012 at 5:44 PM, Dave Airlie wrote:
> On Mon, Aug 6, 2012 at 7:40 AM, Daniel Vetter wrote:
>> On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote:
>>> On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote:
>>>
>>> > I like this approach more - the only other sol
On Sun, Aug 5, 2012 at 5:44 PM, Dave Airlie wrote:
> On Mon, Aug 6, 2012 at 7:40 AM, Daniel Vetter wrote:
>> On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote:
>>> On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote:
>>>
>>> > I like this approach more - the only other sol
On Mon, Aug 6, 2012 at 7:40 AM, Daniel Vetter wrote:
> On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote:
>> On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote:
>>
>> > I like this approach more - the only other solution I see is to ask the
>> > currently active driver (i.
On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote:
> On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote:
>
> > I like this approach more - the only other solution I see is to ask the
> > currently active driver (i.e. radeon) at bootime for the right mode. Which
> > sounds
On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote:
> I like this approach more - the only other solution I see is to ask the
> currently active driver (i.e. radeon) at bootime for the right mode. Which
> sounds much more hellish and fragile ...
The "correct" approach is clearly to jus
On Sat, Aug 04, 2012 at 11:57:27AM -0500, Seth Forshee wrote:
> On Fri, Aug 03, 2012 at 05:27:02PM +0100, Matthew Garrett wrote:
> > On Fri, Aug 03, 2012 at 11:24:51AM -0500, Seth Forshee wrote:
> >
> > > This is one of the things I wasn't so sure about. There are various
> > > checks in intel_lvd
On Fri, Aug 03, 2012 at 05:27:02PM +0100, Matthew Garrett wrote:
> On Fri, Aug 03, 2012 at 11:24:51AM -0500, Seth Forshee wrote:
>
> > This is one of the things I wasn't so sure about. There are various
> > checks in intel_lvds_init() that can cause it to bail out before we try
> > to get the EDID
On Fri, Aug 03, 2012 at 05:14:16PM +0100, Matthew Garrett wrote:
> On Fri, Aug 03, 2012 at 11:02:19AM -0500, Seth Forshee wrote:
> > Some Apple hybrid graphics machines do not have the LVDS panel connected
> > to the integrated GPU at boot and also do not supply a VBT. The LVDS
> > connector is not
Some Apple hybrid graphics machines do not have the LVDS panel connected
to the integrated GPU at boot and also do not supply a VBT. The LVDS
connector is not registered as a result, making it impossible to support
graphics switching.
This patch changes intel_lvds_init() to register the connector
On Fri, Aug 03, 2012 at 05:27:02PM +0100, Matthew Garrett wrote:
> On Fri, Aug 03, 2012 at 11:24:51AM -0500, Seth Forshee wrote:
>
> > This is one of the things I wasn't so sure about. There are various
> > checks in intel_lvds_init() that can cause it to bail out before we try
> > to get the EDID
On Fri, Aug 03, 2012 at 11:24:51AM -0500, Seth Forshee wrote:
> This is one of the things I wasn't so sure about. There are various
> checks in intel_lvds_init() that can cause it to bail out before we try
> to get the EDID, and I don't fully understand all of them. If non-laptop
> machines are ex
On Fri, Aug 03, 2012 at 11:02:19AM -0500, Seth Forshee wrote:
> Some Apple hybrid graphics machines do not have the LVDS panel connected
> to the integrated GPU at boot and also do not supply a VBT. The LVDS
> connector is not registered as a result, making it impossible to support
> graphics switc
On Fri, Aug 03, 2012 at 05:14:16PM +0100, Matthew Garrett wrote:
> On Fri, Aug 03, 2012 at 11:02:19AM -0500, Seth Forshee wrote:
> > Some Apple hybrid graphics machines do not have the LVDS panel connected
> > to the integrated GPU at boot and also do not supply a VBT. The LVDS
> > connector is not
Some Apple hybrid graphics machines do not have the LVDS panel connected
to the integrated GPU at boot and also do not supply a VBT. The LVDS
connector is not registered as a result, making it impossible to support
graphics switching.
This patch changes intel_lvds_init() to register the connector
On Fri, Aug 03, 2012 at 11:02:19AM -0500, Seth Forshee wrote:
> Some Apple hybrid graphics machines do not have the LVDS panel connected
> to the integrated GPU at boot and also do not supply a VBT. The LVDS
> connector is not registered as a result, making it impossible to support
> graphics switc
On Fri, Aug 03, 2012 at 11:24:51AM -0500, Seth Forshee wrote:
> This is one of the things I wasn't so sure about. There are various
> checks in intel_lvds_init() that can cause it to bail out before we try
> to get the EDID, and I don't fully understand all of them. If non-laptop
> machines are ex
30 matches
Mail list logo
