<div dir="ltr"><div>Thanks for all the information and links. I had a look at the linux driver apple-gmux.c, and tried to write a simple DragonFly kernel module that switches off the gmux. However, I'm stuck with the attachment of the gmux device: probing via acpi works fine, but I'm not able to allocate IO ports. The gmux controller is at the LPC bus:</div><div><br></div><div>---</div><div>LPC</div><div>---</div><div>pciconf -lv: </div><div><br></div><div>isab0@pci0:0:31:0: . . . </div><div> vendor = 'Intel Corporation'</div><div> device = 'HM55 Chipset LPC Interface Controller'</div><div> class = bridge</div><div> subclass = PCI-ISA</div><div>---</div><div><br></div><div>----</div><div>GMUX</div><div>----</div><div>devinfo -rv | grep GMUX:</div><div><br></div><div>unknown pnpinfo _HID=APP000B _UID=0 at handle=\_SB_.PCI0.LPCB.GMUX</div><div>---</div><div><br></div><div>It seems devices attached to LPC bus can be treated as isa devices: </div><div><br></div><div><a href="https://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008733.html">https://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008733.html</a></div><div><br></div><div>I tried to follow the logic of similar drivers, e.g. acpi_ec, which seems to sit at the same bus (if I understand it correctly that the handle says it's located at the LPC bus?): </div><div><br></div><div>acpi_ec0 pnpinfo . . . handle=\_SB_.PCI0.LPCB.EC__</div><div><br></div><div>The acpi_ec probe part is done with roughly: </div><div><br></div><div>---</div><div>sys/dev/acpica/acpi_ec.c:</div><div>---</div><div><br></div><div>acpi_ec_probe(. . .)</div><div>{</div><div> . . .</div><div><br></div><div> ACPI_ID_PROBE(device_get_parent(dev), dev, ec_ids)</div><div><br></div><div> . . . </div><div>}</div><div>---</div><div><br></div><div>and that works fine for gmux too. Then attach() calls bus_alloc_resource(): </div><div><br></div><div>---</div><div>sys/dev/acpica/acpi_ec.c:</div><div>---</div><div><br></div><div>acpi_ec_attach(. . .)</div><div>{</div><div><br></div><div> . . .</div><div><br></div><div> res = bus_alloc_resource_any(sc->ec_dev, SYS_RES_IOPORT,</div><div><span class="" style="white-space:pre"> </span>&sc->ec_data_rid, RF_ACTIVE);</div><div><br></div><div> . . .</div><div>}</div><div>---</div><div><br></div><div>But that same call returns a NULL pointer for gmux. Where have I gone wrong? </div><div><br></div><div><br></div><div>Cheers</div><div><br></div><div>Peeter</div><div><br></div><div>--</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 4, 2016 at 5:28 PM, Pedro Andrés Aranda Gutiérrez <span dir="ltr"><<a href="mailto:paaguti@gmail.com" target="_blank">paaguti@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">BTW, there was some code around in the switcher and in mackintosh lists on this. File was something like gmux.c<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 28 Jul 2016, at 11:45, Francois Tigeot <<a href="mailto:ftigeot@wolfpond.org">ftigeot@wolfpond.org</a>> wrote:<br>
<br>
> On Thu, Jul 28, 2016 at 10:49:26AM +0200, Pedro Andres Aranda Gutierrez wrote:<br>
>> Similar problem here with an ASUS with nVidia Optimus... So it's not Mac<br>
>> specific...<br>
><br>
> Well, in a way it is.<br>
><br>
> If I'm not mistaken, most Optimus devices have their video outputs directly<br>
> connected to the Intel GPU so it's just a matter of disabling the NVidia one.<br>
><br>
> On at least some Macbook models, the video output are connected to a third<br>
> chip, and this chip must also be told to talk exclusively to the Intel GPU at<br>
> boot time first.<br>
><br>
> --<br>
> Francois Tigeot<br>
<br>
</div></div></blockquote></div><br></div>