IOFramebuffer's Software And Hardware Cursors

28 views
Skip to first unread message

Mike Crawford

unread,
Nov 6, 2017, 4:15:55 PM11/6/17
to darwin-drivers
I'm working on a virtual frame buffer driver for use by a USB video
chip. It uses the open source IOProxyVideoFamily:

https://code.google.com/archive/p/ioproxyvideofamily/

There are many bugs in IOProxyVideoFamily, but I have fixed at least
some of them.

IOFramebuffer has support for both software and hardware cursors.
When I use a software cursor, mouse tracks are left in window title
bars after clicking once then moving the mouse. That is, no tracks if
one has not clicked.

I'm trying hardware cursor support, but I'm concerned that I
misunderstood it, and that use of a hardware cursor requires my USB
gadget to draw the cursor. That is, I suspect that selecting the
hardware cursor relieves the macOS of the burden of displaying the
cursor.

I am uncertain about this, so I'm studying the IOGraphicsFamily that I
got from http://opensource.apple.com/. That code is both lengthy and
complex; I do not yet fully understand it.

One chooses hardware or software cursors in the frame buffer subclass.
The IOFramebuffer parent class calls getAttribute() in the subclass,
with an attribute pointer to return the value of the attribute.
Passing back 1 selects the hardware cursor and obligates the child
class to provide setCursorImage and setCursorState.

However setCursorImage() doesn't create the bitmap directly, rather it
calls the base class' convertCursorImage(). What actually happens is
that the cursorImage opaque pointer isn't really a pointer, it's an
integer index into a table that's maintained by the base class. I do
not yet see any way for my subclass to obtain the bitmap.

That leads me to also suspect that my concern may be unfounded, that
the drawing of the cursor is handled by the macOS, perhaps in the
Window Manager, which is not open source.

I eagerly await your insights,

Mike

Mike Crawford mdcra...@gmail.com

I'm busted flat until my driver reaches beta.
https://www.gofundme.com/help-mike-survive-for-a-month
_______________________________________________
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

Mike Crawford

unread,
Nov 6, 2017, 4:53:59 PM11/6/17
to darwin-drivers
convertCursorImage sends the cursor's pixels back to the frame buffer
child class in convertCursorImage(). The output buffer is supplied
by:

IOHardwareCursorInfo * hwCursorInfo

The actual pixels go into:

UInt8 * dataOut = hwCursorInfo->hardwareCursorData;

I speculate that I can use those pixels to draw the cursor into the
frame buffer memory that IOProxyFramebuffer maintains, or I could pass
the pixels over to the USB driver, to draw after it copies the
framebuffer while converting RGBA into RGB.

So I answered my own question, however it was very helpful to have
asked it. :-D

Mike

Phil Dennis-Jordan

unread,
Nov 7, 2017, 10:56:21 AM11/7/17
to Mike Crawford, darwin-drivers
On Mon, Nov 6, 2017 at 10:53 PM, Mike Crawford <mdcra...@gmail.com> wrote:
> convertCursorImage sends the cursor's pixels back to the frame buffer
> child class in convertCursorImage(). The output buffer is supplied
> by:
>
> IOHardwareCursorInfo * hwCursorInfo
>
> The actual pixels go into:
>
> UInt8 * dataOut = hwCursorInfo->hardwareCursorData;
>
> I speculate that I can use those pixels to draw the cursor into the
> frame buffer memory that IOProxyFramebuffer maintains,

You'll most likely end up fighting WindowServer if you do that,
producing ugly image artifacts. At minimum you'd have to revert your
blit when the cursor moves, but by that time WindowServer might
already have overwritten that part of the image with new data. In
general, avoid writing to the framebuffer that's mapped into
WindowServer unless there's a good reason to do so.

> or I could pass
> the pixels over to the USB driver, to draw after it copies the
> framebuffer while converting RGBA into RGB.

Yes, if the hardware does not support any blitting or overlay in
hardware, you'll want to combine the base framebuffer image with the
cursor image at the point of encoding/submitting it to the hardware.

Hope that helps!

Phil
Reply all
Reply to author
Forward
0 new messages