Abstraction over window input areas

Description

I'm working on a desktop toy of sorts with a no decoration window that should only be click interactable on the area that it's currently drawing to. On most desktop platforms you can just always have it be click transparent unless the global cursor position is over the area you want, but on Wayland this is problematic because Wayland (by design) presents no mechanism to get global cursor position, and stops sending cursor positions when you disable hittest.

This made me think that rather than having to "hand roll" this via manually controlling the hittest within your application maybe winit should instead expose some kind of common API for specifying what area of the window you want to successfully hit test.

The problematic part is that platforms have extremely different ways of handling windows with area that is input transparent. Windows has WM_NCHITTEST which is an API where you catch a hit test event and return whether the click should hit or not, X11 has XShape which supports a list of rectangles or a 1 bit pixmap, Wayland has input regions which are strictly a list of rectangles. I am unfamiliar with the situation on MacOS but I believe that it's simply the "default behavior" that undrawn areas are click transparent. I looked into it and it seems to be more like windows where you implement a function override, catching the test and then returning whether it should hit. Obviously these can be abstracted away, but the question becomes what abstraction models the concept closest.

Random idea throw out:

• Some kind of enum over it, which you can provide a mask or a list of rectangles or so on. Potentially a footgun, because choosing an "incorrect" option could result in suboptimal performance due to the conversion required.
• A simple boolean for "only hit area which you draw to" - limited, has performance implications on platforms which only support rectangles
• Just expose each relevant API on the platform level as extension traits

No files, tests, or entry points are named. Start by comparing the described Windows, X11, Wayland, and macOS input-area mechanisms and determine which common abstraction can represent them without unacceptable platform-specific behavior; done means a resolved API design with agreed platform semantics.