Touchbar does not awaken after resume
roadrunner2 opened this issue · comments
After suspending and resuming, the touchbar stays off and inactive; however, at the USB level everything looks fine (the responses to the various commands all indicate success). My best guess right now is that some additional command/initialization is needed at suspend and/or resume time.
MacOS uses a much more elaborate protocol to handle the touchbar, whereas this driver is based off of the simpler one used by the Windows driver. So if somebody could run Windows and capture the usb traffic during suspend and resume that would be great.
@Dunedan I took a look at your traces from cb22#30 and played around a bit. Unfortunately those DRLC bulk requests are not relevant for us currently, because the endpoint they are sent to doesn't even exist. I.e. we would have to switch into the full MacOS mode to even be able to send those requests.
Ok, fair enough, as the Touch Bar of course runs in "full mode" under MacOS. Unfortunately when running Windows in a VM suspend is disabled there (probably a driver issue). But let me have another look if I can get that to work somehow.
So. While I was not able to get suspend working in a Windows VM running under Virtualbox (as that doesn't seem to be possible at all), I thought that the driver probably sends the correct commands when the operating system is being shut down as well.
So here are traces from Windows shutting down/restarting: touchbar-restart-and-shutdown.zip
@Dunedan Thanks. That's an interesting idea. I just took a quick look at the traces, and there appear to be a few candidates there - I'll try things out in a few days.
As a random mention here, having switched back to OSX, if my laptop is kept in sleep mode long enough, it will switch into hibernation mode. This requires a reboot to restart the system, where upon… the touchbar is black and entirely unresponsive.
I just thought it might be interesting to note that apparently even OSX cannot get it to work just right all the time either.
Just catching up on things, to see where things are at, because the “Smarch” Bug (“Month 13 is out of bounds”) hit my OSX… and it’s causing me a lot of headaches.
Interesting tidbit, thanks.
As an update, I did look into the traces, and tried a few things, but couldn't find anything that helped/worked. The full mode that MacOS uses seems to work differently enough from the simple mode that this driver (and the Windows driver) users that there must be some other mechanism when using it.
So, an appeal for help: can somebody who can also boot Windows get a usb trace of the touchbar while suspending and resuming? Apparently something called Logman can be used to capture such traces.
I also get the dead touch bar often in MacOS. It's usually when I run my battery to the percent where it will shut off by itself. When it unhybernates, I get something similar with a dead touchid, but working touchbar. So there are obviously levels of breakage...
Here are two USB traffic dumps, that was taken while closing the laptop.
There are
usb_dump_tcpdump_4.zip
usb_dump_tcpdump_5.zip
There is an interesting CLEAR FEATURE request among other traffic, called right before MacOS go into suspend. Hope it helps.
Since it was late at night, I'd totally forgotten to mention the source of data.
The dumps was taken using MBP14.3 with MacOS High Sierra. tcpdump collected the data, whilst I closed the laptop's lid.
@drrtuy Thanks for those traces. But something is odd with them: they appear to contain packets for only a single direction, namely from iBridge to host, and no packets in the reverse direction.
According to the traces, the CLEAR FEATURE is a command sent by the iBridge to the host, so I don't think that's useful here.
Also, the thing is this: the touchbar can run in one of two modes, which I call "simple" and "full" - the former is used by Windows and my appletb driver here, and just allows for showing either a fixed list of special keys or the function keys (or turning the touchbar off); the "full" mode is what MacOS uses, where (apparently) arbitrary keys can be defined etc. The traces from the "full" mode aren't really useful in figuring out issues in the "simple" mode, as the protocol is quite different (and indeed there are even additional usb interfaces/endpoints that don't exist in the "simple" mode). Hence what I really need are traces from Windows.
Lastly, a general update here. Playing around with suspend/resume and the xhci driver, I'm starting to think that this might actually be an xhci driver issue: if the driver is not touched during suspend/resume, then upon resume no iBridge devices are visible! The xhci driver has to be unbound from all USB controllers on suspend, and on resume (re)bound to them, for the iBridge devices to appear after resume. One thing I have yet to try is building the xhci driver as a module and removing and re-adding the module across suspend/resume.
@roadrunner2 Thanks for the explanation.
I wonder which drivers must I install to get TB work under windows? Should I use bootcamp drivers pack?
@drrtuy I presume yes, you need to install the bootcamp drivers.
Another small update: did try with the xhci drivers built as modules, and removing and re-adding them on suspend/resume, but that didn't help. So back to the assumption that there's a special command we need to send to the touchbar to reset/re-awaken it.
Dumps collected in bootcamped win10 whilst suspending and hibernating the laptop
Files.zip
@drrtuy Thank you very much for those traces! From a quick look it looks like there are several new requests in there I haven't seen before. I'll need to play with this some more.
A question, though: in the suspend trace, where did the suspend end and the resume start? Looking at the timestamps, there's a 20 second gap between 11:17:14 and 11:17:34 - was that when the laptop was suspended? So no control messages were sent upon suspend, only upon resume? In the hibernate case I see a gap from 11:20:43 to 11:21:55, so assume that's when it was hibernating?
Any updates with the issue?
Sorry, I haven't been able to spend much time on this recently. Furthermore, for some reason the USB traces are not correct: they show data being sent to the device as coming from the device... Anyway, after further digging into the USB specs I'm fairly confident I have extracted the correct info from the traces. Unfortunately, even with these new control messages I haven't been able to get the touchbar to turn on 😞 Still looking at things, though.
Thanks to everyone who helped here, in particular @drrtuy - in the end the trigger to wake up the device was an ACPI method, not any USB operation, hence why the traces didn't reveal anything useful.
@drrtuy The code is pushed - just (re)pull and rebuild.