Notifications about ACPI events in userspace?

Notifications about ACPI events in userspace?

[Florian Echtler]

[-- Attachment #1.1: Type: text/plain, Size: 1133 bytes --]

Hi everyone,

I'm currently adding support for the iMac's target display mode (TDM) to Linux.
When an external DisplayPort source is added/removed, the following ACPI code is
invoked:

    Scope (\_SB.PCI0.LPCB.SMC)
    {
        Device (DPPT)
        {
            Name (_HID, EisaId ("APP000C"))  // _HID: Hardware ID
            Name (_CID, "smc-dppt")  // _CID: Compatible ID
        }
    }

   Scope (\_SB.PCI0.LPCB.EC)
    {
        Method (_Q30, 0, NotSerialized)  // _Qxx: EC Query
        {
            Notify (\_SB.PCI0.LPCB.SMC.DPPT, 0x80) // Status Change
        }

        Method (_Q31, 0, NotSerialized)  // _Qxx: EC Query
        {
            Notify (\_SB.PCI0.LPCB.SMC.DPPT, 0x81) // Information Change
        }
    }


I've already verified that the method calls do indeed take place, by turning on
EC debugging. The APP000C device does also exist in /sys.

However, I'm not seeing anything happening with either acpi_listen or kacpimon.
Does this require any kernel changes, or could I subscribe to these events somehow?

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Notifications about ACPI events in userspace?

[Lukas Wunner]

On Fri, May 12, 2017 at 10:37:47AM +0200, Florian Echtler wrote:
> I'm currently adding support for the iMac's target display mode (TDM) to
> Linux.

Cool!


> When an external DisplayPort source is added/removed, the following ACPI
> code is invoked:
> 
>     Scope (\_SB.PCI0.LPCB.SMC)
>     {
>         Device (DPPT)
>         {
>             Name (_HID, EisaId ("APP000C"))  // _HID: Hardware ID
>             Name (_CID, "smc-dppt")  // _CID: Compatible ID
>         }
>     }
> 
>    Scope (\_SB.PCI0.LPCB.EC)
>     {
>         Method (_Q30, 0, NotSerialized)  // _Qxx: EC Query
>         {
>             Notify (\_SB.PCI0.LPCB.SMC.DPPT, 0x80) // Status Change
>         }
> 
>         Method (_Q31, 0, NotSerialized)  // _Qxx: EC Query
>         {
>             Notify (\_SB.PCI0.LPCB.SMC.DPPT, 0x81) // Information Change
>         }
>     }
> 
> 
> I've already verified that the method calls do indeed take place, by
> turning on EC debugging. The APP000C device does also exist in /sys.
> 
> However, I'm not seeing anything happening with either acpi_listen or
> kacpimon.
> Does this require any kernel changes, or could I subscribe to these
> events somehow?

You can subscribe to these events by calling acpi_install_notify_handler().
See drivers/platform/x86/apple-gmux.c for an example.  That's a driver for
APP000B, a custom chip found on dual-GPU MacBook Pros dubbed GMUX which is
responsible for multiplexing the panel between the GPUs.

I'm not sure what APP000C is, could be a similar custom controller, I'd have
to do some research first to know what it does.  Surely "DP" stands for
DisplayPort, but what does "PT" stand for?

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.

Thanks,

Lukas

Re: Notifications about ACPI events in userspace?

[Florian Echtler]

[-- Attachment #1.1: Type: text/plain, Size: 1630 bytes --]

On 12.05.2017 12:06, Lukas Wunner wrote:
> On Fri, May 12, 2017 at 10:37:47AM +0200, Florian Echtler wrote:
>> I'm currently adding support for the iMac's target display mode (TDM) to
>> Linux.
> 
> Cool!

:-)

>> However, I'm not seeing anything happening with either acpi_listen or
>> kacpimon.
>> Does this require any kernel changes, or could I subscribe to these
>> events somehow?
> 
> You can subscribe to these events by calling acpi_install_notify_handler().
> See drivers/platform/x86/apple-gmux.c for an example.  That's a driver for
> APP000B, a custom chip found on dual-GPU MacBook Pros dubbed GMUX which is
> responsible for multiplexing the panel between the GPUs.

OK, but this has to happen in a kernel context, correct? No way to see these
from userspace?

> I'm not sure what APP000C is, could be a similar custom controller, I'd have
> to do some research first to know what it does.  Surely "DP" stands for
> DisplayPort, but what does "PT" stand for?

I'm guessing DPPT is for "DisPlayPorT". 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.

> 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?

The other approach would be to write a dedicated TDM module, but I'm not sure
how to access the SMC, then...

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Notifications about ACPI events in userspace?

[Lukas Wunner]

[cc += dri-devel]

On Fri, May 12, 2017 at 01:05:21PM +0200, Florian Echtler wrote:
> On 12.05.2017 12:06, Lukas Wunner wrote:
> > On Fri, May 12, 2017 at 10:37:47AM +0200, Florian Echtler wrote:
> >> I'm currently adding support for the iMac's target display mode (TDM) to
> >> Linux.
> >> However, I'm not seeing anything happening with either acpi_listen or
> >> kacpimon.
> >> Does this require any kernel changes, or could I subscribe to these
> >> events somehow?
> > 
> > You can subscribe to these events by calling acpi_install_notify_handler().
> > See drivers/platform/x86/apple-gmux.c for an example.  That's a driver for
> > APP000B, a custom chip found on dual-GPU MacBook Pros dubbed GMUX which is
> > responsible for multiplexing the panel between the GPUs.
> 
> OK, but this has to happen in a kernel context, correct? No way to see these
> from userspace?

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.

Essentially this is the same setup as on dual GPU MacBook Pros which
(unlike muxless solutions such as Nvidia Optimus) can fully switch the
panel between GPUs.

I believe we don't have a proper abstraction yet in the DRM subsystem
to control a display which can be driven by multiple sources.  All we
have is the somewhat kludgy vga_switcheroo interface:  It allows manual
switching by writing commands to /sys/kernel/debug/vgaswitcheroo/switch
(see https://www.kernel.org/doc/html/latest/gpu/vga-switcheroo.html
and drivers/gpu/vga/vga_switcheroo.c).

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.

As to your question, yes, acpi_install_notify_handler() is called from
kernel space and you could pass through the event to user space e.g.
via udev.  Then the desktop environment could display an icon that an
additional source is present.

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'm not sure what APP000C is, could be a similar custom controller, I'd
> > have to do some research first to know what it does.  Surely "DP" stands
> > for DisplayPort, but what does "PT" stand for?
> 
> I'm guessing DPPT is for "DisPlayPorT".

More like DisplayPort Pass-Through.


> 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?


> > 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.

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.

Thanks,

Lukas

Re: Notifications about ACPI events in userspace?

[Florian Echtler]

[-- Attachment #1.1: Type: text/plain, Size: 3505 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Notifications about ACPI events in userspace?

[Lukas Wunner]

On Sat, May 13, 2017 at 06:47:16PM +0200, Florian Echtler wrote:
> 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?

The handler's ->power_state hook would be a no-op.  Obviously not pretty,
but we just don't have a better abstraction yet.  We represent an egress
connector on a graphics card as a drm_connector in sysfs.  What we might
need is a representation of a sink (display) in sysfs with symlinks to the
sources.  Such a source could be a drm_connector or something else
entirely (a GPU on another machine in your case).


> > > 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.

That might make sense if you feel the driver will grow large enough to
make applesmc.c look messy, or if you feel it just doesn't fit there.

I guess the only reason why Apple integrated the functionality into the
SMC is because they wanted to support TDM when the machine is powered off.
The SMC is powered even in S5 (if the iMac is connected to AC), it just
needs to monitor HPD on the external port and turn on the backlight if
something is plugged in.  (I'm not sure if TDM is actually supported
during poweroff but technically it would seem to be supported.)

Otherwise I've got no opinion on that, adding Nicolas Boichat and Henrik
Rydberg to cc in case they have one.


> > 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.

Good!  Makes everything a lot simpler.

Thanks,

Lukas

> 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
> 

Re: Notifications about ACPI events in userspace?

[Florian Echtler]

[-- Attachment #1.1: Type: text/plain, Size: 2600 bytes --]

On 14.05.2017 10:11, Lukas Wunner wrote:
> On Sat, May 13, 2017 at 06:47:16PM +0200, Florian Echtler wrote:
>> On 13.05.2017 14:18, Lukas Wunner wrote:
>>>
>>> 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?
> 
> The handler's ->power_state hook would be a no-op.  Obviously not pretty,
> but we just don't have a better abstraction yet.  We represent an egress
> connector on a graphics card as a drm_connector in sysfs.  What we might
> need is a representation of a sink (display) in sysfs with symlinks to the
> sources.  Such a source could be a drm_connector or something else
> entirely (a GPU on another machine in your case).

OK, I think it's the closest thing that's already in the kernel, and before I
add yet another custom sysfs node, vga_switcheroo is probably the easiest route
to get things up and running.

>> 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.
> 
> That might make sense if you feel the driver will grow large enough to
> make applesmc.c look messy, or if you feel it just doesn't fit there.

Everything else in applesmc.c is hwmon-related, IMHO it would be a kludge. So
for applesmc, I'd just need a tiny patch to export the main key access
functions, and everything else can (hopefully) be encapsulated in an "apple-tdm"
driver.

> I guess the only reason why Apple integrated the functionality into the
> SMC is because they wanted to support TDM when the machine is powered off.
> The SMC is powered even in S5 (if the iMac is connected to AC), it just
> needs to monitor HPD on the external port and turn on the backlight if
> something is plugged in.  (I'm not sure if TDM is actually supported
> during poweroff but technically it would seem to be supported.)

Hm, interesting, I hadn't yet thought of that. This would of course be
excellent, because right now it looks like a waste of power to run the whole
machine just because of the display.

Does the SMC have control over the backlight? Do you know which keys are
responsible? IIRC the apple_bl.c driver didn't work on my iMac anyway...

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Notifications about ACPI events in userspace?

[Lukas Wunner]

On Sun, May 14, 2017 at 11:25:48AM +0200, Florian Echtler wrote:
> On 14.05.2017 10:11, Lukas Wunner wrote:
> > On Sat, May 13, 2017 at 06:47:16PM +0200, Florian Echtler wrote:
> >> On 13.05.2017 14:18, Lukas Wunner wrote:
> >>> 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?
> > 
> > The handler's ->power_state hook would be a no-op.  Obviously not pretty,
> > but we just don't have a better abstraction yet.  We represent an egress
> > connector on a graphics card as a drm_connector in sysfs.  What we might
> > need is a representation of a sink (display) in sysfs with symlinks to the
> > sources.  Such a source could be a drm_connector or something else
> > entirely (a GPU on another machine in your case).
> 
> OK, I think it's the closest thing that's already in the kernel, and before
> I add yet another custom sysfs node, vga_switcheroo is probably the easiest
> route to get things up and running.

Okay.  I'm only just now starting to get a vague idea how all this
may be represented properly.  On pre-Thunderbolt MacBook Pros it's
possible to switch the external DP port between GPUs independently
from the panel.  Right now we're switching both in unison, but if
we had a proper "sink with multiple sources" abstraction, we would
be able to support switching them separately.


> >> 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.
> > 
> > That might make sense if you feel the driver will grow large enough to
> > make applesmc.c look messy, or if you feel it just doesn't fit there.
> 
> Everything else in applesmc.c is hwmon-related, IMHO it would be a kludge.
> So for applesmc, I'd just need a tiny patch to export the main key access
> functions, and everything else can (hopefully) be encapsulated in an
> "apple-tdm" driver.

Sounds reasonable.  You can probably copy/paste a lot of boilerplate
from apple-gmux.c and just bind to APP000C instead of APP000B.

You may need to add APP000C to acpi_pnp_device_ids[] in
drivers/acpi/acpi_pnp.c for the driver to bind to the device.

The vga_switcheroo "switch" file will appear in sysfs as soon as a
handler and 2 clients have registered.  The handler only needs to
implement the ->switchto and ->get_client_id hooks, all others are
optional.  The ->get_client_id hook should probably return
VGA_SWITCHEROO_IGD for the Nvidia GPU built into the iMac and
VGA_SWITCHEROO_DIS for the external port.

The vga_switcheroo_client is normally a PCI device, I guess you
could use the LPC bridge as a placeholder (the grandparent of the
APP000C device).  The ->set_gpu_state hook would be a no-op and
->can_switch could always return true.  If you register that client
whenever something is plugged in and unregister it on unplug, the
"switch" file in sysfs appears only as long as something is plugged in.


> > I guess the only reason why Apple integrated the functionality into the
> > SMC is because they wanted to support TDM when the machine is powered off.
> > The SMC is powered even in S5 (if the iMac is connected to AC), it just
> > needs to monitor HPD on the external port and turn on the backlight if
> > something is plugged in.  (I'm not sure if TDM is actually supported
> > during poweroff but technically it would seem to be supported.)
> 
> Hm, interesting, I hadn't yet thought of that. This would of course be
> excellent, because right now it looks like a waste of power to run the
> whole machine just because of the display.
> 
> Does the SMC have control over the backlight? Do you know which keys are
> responsible? IIRC the apple_bl.c driver didn't work on my iMac anyway...

The panel is attached to power rails which are only active in S0
(PP12V_S0_LCD and PP3V3_S0_VIDEO).

Conceivably, the SMC could sense HPD and bring up those power rails.
However various other things are hanging off of the same rails,
e.g. fan, memory, optical disk drive, and they would be powered up
as well.  Essentially the whole machine would boot, but perhaps
the EFI firmware senses if powerup was only triggered by DP hotplug
and not boot an OS.  Have you tested what happens if you plug
something in while the iMac is off?

Thanks,

Lukas