On 13.05.2017 14:18, Lukas Wunner wrote:
>
> So to sum it up, the built-in panel on the iMac can be driven by a
> separate machine and we can switch between the two sources via the SMC.
>
> [...]
>
> I guess you could register a vga_switcheroo handler which controls
> switching via the SMC. You'd also have to register a vga_switcheroo
> client whenever you detect hotplug of an external source (and unregister
> on unplug). The client is normally a DRM driver but would in this case
> just be a pseudo device.
>
> Then you could switch back and forth via the vga_switcheroo interface.
Hm... since there's no power switching of any kind involved, would that still
make sense?
> On macOS I can't find the "dppt" string in any kernel extension, but
> it's present in this user space component:
> /System/Library/LoginPlugins/BezelServices.loginPlugin/Contents/MacOS/BezelServices
>
> Disassembling it reveals that it talks to a special Mach port to switch
> the display but it's not listening to the Notify() events. Perhaps this
> is only used with BootCamp?
>
> In any case the other end of the Mach port seems to be /usr/libexec/dpd.
I think the dpd binary is also somehow listening for ACPI events, or it is
triggered by some other component when the ACPI Notify happens (in
com.apple.dpd.plist, you can also find the "smc-dppt" string,).
>> As far as I could tell, it's just a stub
>> for receiving the Notify() calls; the actual source switching is handled by
>> writing to SMC keys.
>
> Yes, the Notify() calls are used to generate some kind of interrupt,
> perhaps one for hotplug and the other one for unplug?
Correct, I already verified this with EC debugging turned on - _Q31 is triggered
when an external source is plugged in, _Q30 when it is removed.
>>> Perhaps apple-gmux.c could serve as a template for an APP000C driver.
>>> The code should be easy to understand, if you have questions just ask away.
>>
>> Since I need to modify the applesmc.c driver anyway, it would probably make
>> sense to integrate the notify handler there?
>
> Sounds reasonable to me.
AFAICT, the alternative (which maybe would be more sensible, the more I think
about it) would be to export applesmc_{read,write}_key as public symbols and
just access them from a standalone driver for the APP000C ACPI device. Since
that should only be present on a Mac that actually supports TDM, there's also no
risk of writing to arbitrary SMC keys on unsupported devices.
> Which iMac model are you developing this on exactly, a 2009/2010 model
> (without Thunderbolt) or a newer one? The newer ones can only be driven
> via DP-over-Thunderbolt tunnels, so the HPD pin is coming from the
> Thunderbolt controller, not the socket. We don't have support for
> setting up DP-over-Thunderbolt tunnels in thunderbolt.ko yet, only
> PCIe-over-Thunderbolt is supported. If the external source is already
> present on boot, the tunnel may be established by the Thunderbolt EFI
> driver but will be gone after unplug.
I have a 2009/2010 model, so no Thunderbolt. If someone is feeling adventurous
with a Thunderbolt iMac, feel free to poke the SMC. I've written a short blog
post that should be sufficient as background information for some initial
experiments: http://floe.butterbrot.org/matrix/hacking/tdm/ and
https://github.com/floe/smc_util (in particular, look at tdm_{on,off}.sh).
Best, Florian
--
SENT FROM MY DEC VT50 TERMINAL
Attachment:
signature.asc
Description: OpenPGP digital signature
