Hi,
On Wed, Aug 03, 2022 at 06:31:39AM +0530, Rajat Khandelwal wrote:
> Current implementation doesn't allow user to go into system suspend
> and simultaneously project the screen on an external display connected
> to a TBT/USB4 device. This patch enables this feature.
>
> Let me know what you think about this.
Please prefix patches to follow the sybsystem style. For Thunderbolt it
should be "thunderbolt: ....".
This will cause any monitor plug to wake up the system and I'm not sure
we want that, at least to be default behaviour. If you have a regular
Type-C (non-USB4/TBT) dock and you plug in a monitor to that, does it
wake up?
IIRC I already suggested you to do this for the USB4 ports themselves
(struct usb4_port) so that userspace can make them wake up the system on
any event by writing "enabled > .../wakeup" which is the normal way.
Hi Mika,
On Tue, Aug 2, 2022 at 10:37 PM Mika Westerberg
<[email protected]> wrote:
>
> Hi,
>
> On Wed, Aug 03, 2022 at 06:31:39AM +0530, Rajat Khandelwal wrote:
> > Current implementation doesn't allow user to go into system suspend
> > and simultaneously project the screen on an external display connected
> > to a TBT/USB4 device. This patch enables this feature.
> >
> > Let me know what you think about this.
>
> Please prefix patches to follow the sybsystem style. For Thunderbolt it
> should be "thunderbolt: ....".
>
> This will cause any monitor plug to wake up the system and I'm not sure
> we want that, at least to be default behaviour. If you have a regular
> Type-C (non-USB4/TBT) dock and you plug in a monitor to that, does it
> wake up?
Speaking for Google and our ChromeOS USB-C policy, yes, if the host is
in S0iX or S3, an already attached USB-C docking station in DP Alt
Mode will respond to a display attach via HPD via an Alert message in
USB PD. We called this feature wake-on-dock.
We implemented wake-on-dock for DP Alt Mode in the EC, since our EC
handles USB PD anyway, and is handling the PD Alert message which
contains the HPD status.
However, when the dock supports USB4 or Thunderbolt, those modes don't
involve USB PD for device attach, so our EC doesn't have the role of
waking the system, so something else on the system must, which is this
feature being discussed.
>
> IIRC I already suggested you to do this for the USB4 ports themselves
> (struct usb4_port) so that userspace can make them wake up the system on
> any event by writing "enabled > .../wakeup" which is the normal way.
Yes, I would support making this toggle-able like other wakeup sources.
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
[email protected]
Chromium OS Project
[email protected]
Hi Benson,
On Wed, Aug 03, 2022 at 08:15:49AM -0700, Benson Leung wrote:
> Hi Mika,
>
> On Tue, Aug 2, 2022 at 10:37 PM Mika Westerberg
> <[email protected]> wrote:
> >
> > Hi,
> >
> > On Wed, Aug 03, 2022 at 06:31:39AM +0530, Rajat Khandelwal wrote:
> > > Current implementation doesn't allow user to go into system suspend
> > > and simultaneously project the screen on an external display connected
> > > to a TBT/USB4 device. This patch enables this feature.
> > >
> > > Let me know what you think about this.
> >
> > Please prefix patches to follow the sybsystem style. For Thunderbolt it
> > should be "thunderbolt: ....".
> >
> > This will cause any monitor plug to wake up the system and I'm not sure
> > we want that, at least to be default behaviour. If you have a regular
> > Type-C (non-USB4/TBT) dock and you plug in a monitor to that, does it
> > wake up?
>
> Speaking for Google and our ChromeOS USB-C policy, yes, if the host is
> in S0iX or S3, an already attached USB-C docking station in DP Alt
> Mode will respond to a display attach via HPD via an Alert message in
> USB PD. We called this feature wake-on-dock.
>
> We implemented wake-on-dock for DP Alt Mode in the EC, since our EC
> handles USB PD anyway, and is handling the PD Alert message which
> contains the HPD status.
>
> However, when the dock supports USB4 or Thunderbolt, those modes don't
> involve USB PD for device attach, so our EC doesn't have the role of
> waking the system, so something else on the system must, which is this
> feature being discussed.
Okay understood. Thanks for explaining!