On Tue, Jul 31, 2012 at 03:32:40PM -0700, Greg KH wrote:
> With this series, does the latest MacBook work properly for the Intel
> graphics driver? Or is this to resolve some other hardware issue?
Apple only seem to provide the ROM for the radeon. Intel normally
stands a much better chance of working without a ROM - the only thing it
really uses it for is the VBT, and I'm thinking about a couple of ways
of handlng that.
--
Matthew Garrett | [email protected]
On Wed, Aug 01, 2012 at 05:54:00PM +0100, Matthew Garrett wrote:
> On Tue, Jul 31, 2012 at 03:32:40PM -0700, Greg KH wrote:
>
> > With this series, does the latest MacBook work properly for the Intel
> > graphics driver? Or is this to resolve some other hardware issue?
>
> Apple only seem to provide the ROM for the radeon. Intel normally
> stands a much better chance of working without a ROM - the only thing it
> really uses it for is the VBT, and I'm thinking about a couple of ways
> of handlng that.
Ok, thanks for letting me know. For some reason, the gmux isn't working
on the latest MacBook Pro so I can't get the vga switched to the Intel
PCI device. Rumor has it the osx tool at
http://codykrieger.com/gfxCardStatus will switch into the Intel chip
until the laptop is hard powered off, so it is possible, just need to
figure out how to make the hardware do the switch...
greg k-h
On Wed, Aug 01, 2012 at 04:21:47PM -0700, Greg KH wrote:
> On Wed, Aug 01, 2012 at 05:54:00PM +0100, Matthew Garrett wrote:
> > On Tue, Jul 31, 2012 at 03:32:40PM -0700, Greg KH wrote:
> >
> > > With this series, does the latest MacBook work properly for the Intel
> > > graphics driver? Or is this to resolve some other hardware issue?
> >
> > Apple only seem to provide the ROM for the radeon. Intel normally
> > stands a much better chance of working without a ROM - the only thing it
> > really uses it for is the VBT, and I'm thinking about a couple of ways
> > of handlng that.
>
> Ok, thanks for letting me know. For some reason, the gmux isn't working
> on the latest MacBook Pro so I can't get the vga switched to the Intel
> PCI device. Rumor has it the osx tool at
> http://codykrieger.com/gfxCardStatus will switch into the Intel chip
> until the laptop is hard powered off, so it is possible, just need to
> figure out how to make the hardware do the switch...
There's a tool that enables some verbose logging which records all the
I/O to the gmux. It works for me with a Macbook Pro 8,2 running OS X
Lion, so you might give it a try.
All you need to do is clone https://github.com/ah-/switcher.git, build,
and run switcher. If it works you'll see messages prefixed with AGC in
dmesg. Then you can use gfxCardStatus to force some switches between the
integrated and discrete cards. After that you'll want to grab
/var/log/kern.log to get the full logs of everything that happened.
If you try this and it works, I'd appreciate it if you could send me a
copy of kern.log so I can apply the information towards getting graphics
switching into apple-gmux.
Seth
On Wed, Aug 01, 2012 at 11:02:42PM -0500, Seth Forshee wrote:
> On Wed, Aug 01, 2012 at 04:21:47PM -0700, Greg KH wrote:
> > On Wed, Aug 01, 2012 at 05:54:00PM +0100, Matthew Garrett wrote:
> > > On Tue, Jul 31, 2012 at 03:32:40PM -0700, Greg KH wrote:
> > >
> > > > With this series, does the latest MacBook work properly for the Intel
> > > > graphics driver? Or is this to resolve some other hardware issue?
> > >
> > > Apple only seem to provide the ROM for the radeon. Intel normally
> > > stands a much better chance of working without a ROM - the only thing it
> > > really uses it for is the VBT, and I'm thinking about a couple of ways
> > > of handlng that.
> >
> > Ok, thanks for letting me know. For some reason, the gmux isn't working
> > on the latest MacBook Pro so I can't get the vga switched to the Intel
> > PCI device. Rumor has it the osx tool at
> > http://codykrieger.com/gfxCardStatus will switch into the Intel chip
> > until the laptop is hard powered off, so it is possible, just need to
> > figure out how to make the hardware do the switch...
>
> There's a tool that enables some verbose logging which records all the
> I/O to the gmux. It works for me with a Macbook Pro 8,2 running OS X
> Lion, so you might give it a try.
>
> All you need to do is clone https://github.com/ah-/switcher.git, build,
> and run switcher. If it works you'll see messages prefixed with AGC in
> dmesg. Then you can use gfxCardStatus to force some switches between the
> integrated and discrete cards. After that you'll want to grab
> /var/log/kern.log to get the full logs of everything that happened.
>
> If you try this and it works, I'd appreciate it if you could send me a
> copy of kern.log so I can apply the information towards getting graphics
> switching into apple-gmux.
Francois, any chance you can ty this and let Seth know the results? I
don't have OSX on my machine anymore to do this myself.
thanks,
greg k-h
Greg, Seth,
Here is what the message.log shows:
switching to the HD4000 (integrated):
Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: CGXMuxAcknowledge: Posting glitchless acknowledge
Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 0x042803c0 device: 0x10c678320 isBackBuffered: 0 numComp: 1 numDisp: 3
Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003d
Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003e
Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003f
switching to the nvidia (discrete):
Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003d
Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003e
Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003f
Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: CGXMuxAcknowledge: Posting glitchless acknowledge
Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 0x042803c0 device: 0x10c678320 isBackBuffered: 0 numComp: 1 numDisp: 3
Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
Hope that helps.
Francois
On 02/08/12 20:34, Greg KH wrote:
> On Wed, Aug 01, 2012 at 11:02:42PM -0500, Seth Forshee wrote:
>> On Wed, Aug 01, 2012 at 04:21:47PM -0700, Greg KH wrote:
>>> On Wed, Aug 01, 2012 at 05:54:00PM +0100, Matthew Garrett wrote:
>>>> On Tue, Jul 31, 2012 at 03:32:40PM -0700, Greg KH wrote:
>>>>
>>>>> With this series, does the latest MacBook work properly for the Intel
>>>>> graphics driver? Or is this to resolve some other hardware issue?
>>>> Apple only seem to provide the ROM for the radeon. Intel normally
>>>> stands a much better chance of working without a ROM - the only thing it
>>>> really uses it for is the VBT, and I'm thinking about a couple of ways
>>>> of handlng that.
>>> Ok, thanks for letting me know. For some reason, the gmux isn't working
>>> on the latest MacBook Pro so I can't get the vga switched to the Intel
>>> PCI device. Rumor has it the osx tool at
>>> http://codykrieger.com/gfxCardStatus will switch into the Intel chip
>>> until the laptop is hard powered off, so it is possible, just need to
>>> figure out how to make the hardware do the switch...
>> There's a tool that enables some verbose logging which records all the
>> I/O to the gmux. It works for me with a Macbook Pro 8,2 running OS X
>> Lion, so you might give it a try.
>>
>> All you need to do is clone https://github.com/ah-/switcher.git, build,
>> and run switcher. If it works you'll see messages prefixed with AGC in
>> dmesg. Then you can use gfxCardStatus to force some switches between the
>> integrated and discrete cards. After that you'll want to grab
>> /var/log/kern.log to get the full logs of everything that happened.
>>
>> If you try this and it works, I'd appreciate it if you could send me a
>> copy of kern.log so I can apply the information towards getting graphics
>> switching into apple-gmux.
> Francois, any chance you can ty this and let Seth know the results? I
> don't have OSX on my machine anymore to do this myself.
>
> thanks,
>
> greg k-h
On Fri, Aug 03, 2012 at 12:57:33AM +1000, Francois Rigaut wrote:
> Greg, Seth,
>
> Here is what the message.log shows:
>
> switching to the HD4000 (integrated):
>
> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: CGXMuxAcknowledge: Posting glitchless acknowledge
> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 0x042803c0 device: 0x10c678320 isBackBuffered: 0 numComp: 1 numDisp: 3
> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003d
> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003e
> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003f
>
> switching to the nvidia (discrete):
>
> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003d
> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003e
> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003f
> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: CGXMuxAcknowledge: Posting glitchless acknowledge
> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 0x042803c0 device: 0x10c678320 isBackBuffered: 0 numComp: 1 numDisp: 3
> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
>
> Hope that helps.
Thanks for trying it out, but it's not really what I was hoping for. I
get a bunch of messages similar to these in /var/log/kernel.log, mixed
in with a lot of other stuff.
AGC:: setMuxRegister:1666 (728, 1, 1)
AGC:: setMuxRegister:1666 (710, 1, 4)
AGC:: getMuxRegister:1647 (716, 1) = 1
I don't even have message.log. You don't have a kernel.log? Do you see
any messages like those if you run dmesg?
Seth
Hi Seth,
Sorry for the belated response. On Oz time here.
I don't have a /var/log/kernel.log !
Let me make sure of something:
This switcher code is to be run on osx, no? That's where gfxcardstatus
lives and where I can effect the card switch. Just to make sure.
So I'm running osx mountain lion, and the only thing I see in the logs
when I switch cards (using gfxcardstatus) is what I pasted below. and
you're right, it was not in message.log, but system.log (it was late). I
just went through the whole thing again.
Am I missing something?
Cheers,
Francois
On 03/08/12 02:12, Seth Forshee wrote:
> On Fri, Aug 03, 2012 at 12:57:33AM +1000, Francois Rigaut wrote:
>> Greg, Seth,
>>
>> Here is what the message.log shows:
>>
>> switching to the HD4000 (integrated):
>>
>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: CGXMuxAcknowledge: Posting glitchless acknowledge
>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 0x042803c0 device: 0x10c678320 isBackBuffered: 0 numComp: 1 numDisp: 3
>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003d
>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003e
>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003f
>>
>> switching to the nvidia (discrete):
>>
>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003d
>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003e
>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x3f003f
>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: CGXMuxAcknowledge: Posting glitchless acknowledge
>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: MPAccessSurfaceForDisplayDevice: Set up page flip mode on display 0x042803c0 device: 0x10c678320 isBackBuffered: 0 numComp: 1 numDisp: 3
>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received display connect changed for display 0x42803c0
>>
>> Hope that helps.
> Thanks for trying it out, but it's not really what I was hoping for. I
> get a bunch of messages similar to these in /var/log/kernel.log, mixed
> in with a lot of other stuff.
>
> AGC:: setMuxRegister:1666 (728, 1, 1)
> AGC:: setMuxRegister:1666 (710, 1, 4)
> AGC:: getMuxRegister:1647 (716, 1) = 1
>
> I don't even have message.log. You don't have a kernel.log? Do you see
> any messages like those if you run dmesg?
>
> Seth
Seth,
I have put the osx system.log, which is the only file where I can see
mux and AGC related message, at http://maumae.net/retina/system.log
Thanks,
Francois
On 03/08/12 08:40, Francois Rigaut wrote:
> Hi Seth,
>
> Sorry for the belated response. On Oz time here.
> I don't have a /var/log/kernel.log !
> Let me make sure of something:
> This switcher code is to be run on osx, no? That's where gfxcardstatus
> lives and where I can effect the card switch. Just to make sure.
> So I'm running osx mountain lion, and the only thing I see in the logs
> when I switch cards (using gfxcardstatus) is what I pasted below. and
> you're right, it was not in message.log, but system.log (it was late).
> I just went through the whole thing again.
> Am I missing something?
> Cheers,
> Francois
>
> On 03/08/12 02:12, Seth Forshee wrote:
>> On Fri, Aug 03, 2012 at 12:57:33AM +1000, Francois Rigaut wrote:
>>> Greg, Seth,
>>>
>>> Here is what the message.log shows:
>>>
>>> switching to the HD4000 (integrated):
>>>
>>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received
>>> display connect changed for display 0x42803c0
>>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]:
>>> CGXMuxAcknowledge: Posting glitchless acknowledge
>>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]:
>>> MPAccessSurfaceForDisplayDevice: Set up page flip mode on display
>>> 0x042803c0 device: 0x10c678320 isBackBuffered: 0 numComp: 1 numDisp: 3
>>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received
>>> display connect changed for display 0x42803c0
>>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received
>>> display connect changed for display 0x3f003d
>>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received
>>> display connect changed for display 0x3f003e
>>> Aug 3 00:49:55 poliahu.ctio.noao.edu WindowServer[79]: Received
>>> display connect changed for display 0x3f003f
>>>
>>> switching to the nvidia (discrete):
>>>
>>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received
>>> display connect changed for display 0x42803c0
>>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received
>>> display connect changed for display 0x3f003d
>>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received
>>> display connect changed for display 0x3f003e
>>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received
>>> display connect changed for display 0x3f003f
>>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]:
>>> CGXMuxAcknowledge: Posting glitchless acknowledge
>>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]:
>>> MPAccessSurfaceForDisplayDevice: Set up page flip mode on display
>>> 0x042803c0 device: 0x10c678320 isBackBuffered: 0 numComp: 1 numDisp: 3
>>> Aug 3 00:50:35 poliahu.ctio.noao.edu WindowServer[79]: Received
>>> display connect changed for display 0x42803c0
>>>
>>> Hope that helps.
>> Thanks for trying it out, but it's not really what I was hoping for. I
>> get a bunch of messages similar to these in /var/log/kernel.log, mixed
>> in with a lot of other stuff.
>>
>> AGC:: setMuxRegister:1666 (728, 1, 1)
>> AGC:: setMuxRegister:1666 (710, 1, 4)
>> AGC:: getMuxRegister:1647 (716, 1) = 1
>>
>> I don't even have message.log. You don't have a kernel.log? Do you see
>> any messages like those if you run dmesg?
>>
>> Seth
On Fri, Aug 03, 2012 at 08:54:46AM +1000, Francois Rigaut wrote:
> Seth,
>
> I have put the osx system.log, which is the only file where I can
> see mux and AGC related message, at
> http://maumae.net/retina/system.log
That does seem to contain the kernel log messages, but unfortunately I'm
not seeing what I'm looking for there.
> Thanks,
> Francois
>
> On 03/08/12 08:40, Francois Rigaut wrote:
> >Hi Seth,
> >
> >Sorry for the belated response. On Oz time here.
> >I don't have a /var/log/kernel.log !
> >Let me make sure of something:
> >This switcher code is to be run on osx, no? That's where
> >gfxcardstatus lives and where I can effect the card switch. Just
> >to make sure.
> >So I'm running osx mountain lion, and the only thing I see in the
> >logs when I switch cards (using gfxcardstatus) is what I pasted
> >below. and you're right, it was not in message.log, but system.log
> >(it was late). I just went through the whole thing again.
> >Am I missing something?
Yes, it's to be run on OS X. So apparently something has changed and
this technique no longer works for getting a log of the gmux I/O.
We've got one of these machines on order, so I'll see if I can turn
anything up when I get a chance to play with it.
Thanks,
Seth