Have you a clue about DisplayPipe?

[Mike Crawford]

It's apparently a macOS port of iOS graphics technology.

My IOFramebuffer subclass doesn't work in High Sierra. It's for a USB
video adapter. The USB monitor is black but with a working cursor,
which would indicate that The Window Manager is sending 0-pixels to
our frame buffer.

High Sierra 10.12 uses IOGraphics-517.17. There are very few mentions
of DisplayPipe in that tarball; it appears to be something related to
accelleration, which has long been mostly undocumented and
closed-source.

Apple deprecated IOFramebuffer, but the code and headers are still in
the IOGraphicsFamily kernel extension. I feel that deprecation is
ill-advised, as it is required for USB video, and USB video adapters
are quite popular.

The kprintf log has many repetitions of:

Currently unsupported feature requested
DisplayPipe Capabilities Extended are not supported on offline Fbs

I do not yet know what in my code is stimulating those messages. All
of my functions contain entry/exit kprintfs but I don't see any
interspersed with the above message.

I expect I can fix this somehow as DisplayLink's new driver works with
High Sierra. However I'm not impolite enough to ask them how as they
are our direct competitor.

I may file a support incident.

Thank You For Enlightening Me,

Mike

Mike Crawford mdcra...@gmail.com

The Global Computer Employer Index: http://soggy.jobs/computer
(It's not very global yet.)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (Darwin-...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/darwin-drivers/darwin-drivers-garchive-96018%40googlegroups.com

This email sent to darwin-drivers...@googlegroups.com

[Phil Dennis-Jordan]

Hi Mike,

On Wed, Nov 22, 2017 at 12:37 AM, Mike Crawford <mdcra...@gmail.com> wrote:
> It's apparently a macOS port of iOS graphics technology.
>
> My IOFramebuffer subclass doesn't work in High Sierra. It's for a USB
> video adapter. The USB monitor is black but with a working cursor,
> which would indicate that The Window Manager is sending 0-pixels to
> our frame buffer.

Yes, this regression has been around since the betas. I reported it as
issue 33472378; no feedback thus far. Note that it only affects
systems running in Metal compositing mode. Older Macs, whose GPUs only
support OpenGL work as before.

The only way to access the display contents seems to be through the
Core Graphics API, which you'd normally use for taking screenshots.
This has all sorts of downsides, but it does work, just about. (I
haven't figured out how you use the CG APIs from a pre-login daemon;
it's clearly possible, the screen sharing server must do it, but the
magic incantation doesn't seem to be documented anywhere. It's also
difficult to catch display reconfigurations from a daemon at any
time.)

> High Sierra 10.12 uses IOGraphics-517.17. There are very few mentions
> of DisplayPipe in that tarball; it appears to be something related to
> accelleration, which has long been mostly undocumented and
> closed-source.

I suspect the only realistic way to learn about DisplayPipe is to work
for Apple, Intel, nVidia, or AMD on the Mac graphics driver teams. I'd
be happy to be proven wrong though!

> Apple deprecated IOFramebuffer, but the code and headers are still in
> the IOGraphicsFamily kernel extension. I feel that deprecation is
> ill-advised, as it is required for USB video, and USB video adapters
> are quite popular.
>
> The kprintf log has many repetitions of:
>
> Currently unsupported feature requested
> DisplayPipe Capabilities Extended are not supported on offline Fbs
>
> I do not yet know what in my code is stimulating those messages. All
> of my functions contain entry/exit kprintfs but I don't see any
> interspersed with the above message.

The system logs have become very spammy since 10.12. They're full of
even worse sounding error messages, but macOS keeps going so I guess
they're not as bad as they sound.

> I expect I can fix this somehow as DisplayLink's new driver works with
> High Sierra. However I'm not impolite enough to ask them how as they
> are our direct competitor.

They're using a hack to get the Intel GPU driver's accelerator to
render the image; the advantage is it's faster, CGDisplayStream works,
and you don't get the graphical corruption that's been plagueing the
software renderer since Yosemite. The downside is that enabling
mirroring mode instantly crashes WindowServer (The failed assertion is
also about displaypipes; 35647924: "Assertion failed: (pPipe),
function GetActiveDisplayPipes, file
/BuildRoot/Library/Caches/com.apple.xbs/Sources/CoreDisplay/CoreDisplay-81.7/CoreDisplay/Display/Display.cpp,
line 2607.").

Crashing WindowServer is, er, suboptimal, so I haven't enabled this
hack in the driver I (try to) maintain for a client.

Unfortunately, since 10.13.2 Beta 4, WindowServer crashes (35647698)
if you trigger a hotplug event on an IOFramebuffer if you don't use
this hack. I do hope that gets fixed before 10.13.2 ships, or it
becomes a choice of a rock or a hard place.

> I may file a support incident.

Good luck! The whole IOFramebuffer situation has been bad for years,
High Sierra just escalates the level of brokenness. Last time I asked
DTS something about IOFramebuffer, the only reply I received was that
it's not officially supported by Apple. This was a few years ago
though, maybe you'll have more luck. The recent API deprecation
without replacement I inquired about (various MAC framework APIs;
KAUTH is laughably easy to circumvent) fell on deaf ears too, so I'd
be surprised.

There is of course a fully functional, non-buggy virtual framebuffer
mechanism in WindowServer that allows 3D acceleration as well.
Unfortunately, only AirPlay gets to use it.

Hope my pointers help cobble together something at least vaguely functional. :-)

Phil