"The Wayland compositor is however under no obligation to disable
 all of its shortcuts, and may keep some special key combo for its own
 use, including but not limited to one allowing the user to forcibly
 restore normal keyboard events routing in the case of an unwilling
 client. The compositor may also use the same key combo to reactivate
 an existing shortcut inhibitor that was previously deactivated on
 user request."

Do we think it's important to have this when this lands or just deal with it if it becomes an issue?

I think it should be relatively easy, just an earlier filter that calls:
waylandServer()->keyboardShortcutsInhibitManager()->getShortcutsInhibitor(surface, seat)->setActive(false);

In D29272#659598, @davidedmundson wrote:

"The Wayland compositor is however under no obligation to disable
 all of its shortcuts, and may keep some special key combo for its own
 use, including but not limited to one allowing the user to forcibly
 restore normal keyboard events routing in the case of an unwilling
 client. The compositor may also use the same key combo to reactivate
 an existing shortcut inhibitor that was previously deactivated on
 user request."

Do we think it's important to have this when this lands or just deal with it if it becomes an issue?

I think it should be relatively easy, just an earlier filter that calls:
waylandServer()->keyboardShortcutsInhibitManager()->getShortcutsInhibitor(surface, seat)->setActive(false);

Yes harder part will be to find the shortcut

Are we ok to let Meta key opening menu even if inhibitor is active ?

Are we ok to let Meta key opening menu even if inhibitor is active ?

Wouldn't this do exactly what this patch is trying to prevent?

Are we ok to let Meta key opening menu even if inhibitor is active ?

I think we really do not want this to happen during e.g. gameplay

In D29272#659619, @apol wrote:

Are we ok to let Meta key opening menu even if inhibitor is active ?

Wouldn't this do exactly what this patch is trying to prevent?

Since shortcut inhibition is often used for VMs, nested sessions and alike: definitely. What poses the question how the compositor is supposed to override a client's request to inhibit shortcuts when its shortcuts got inhibited (and likely its pointer is constrained). And how it advertises that to the user.

There was in the past a mechanism to override client's pointer constraint when pressing ESC for few seconds. For pointer constraints that was a broken design but for shortcuts inhibition it could be just right. @bport: For the code check out D15234, where the mechanism was removed for pointer constraints.

I think we really do not want this to happen during e.g. gameplay

Games normally don't inhibit Alt+Tab and similar compositor shortcuts. At least I wouldn't want my games to do that by default.

I will fix that and allow meta inhibition

By the way I guess for now we can let client manage inhibition, advertising and delete it when not needed anymore. In the future if we have problem with that we can add a KDE shortcut that will allow to deactivate all inhibitors or current one and also advertise user with an OSD or something like that explaining keyboard input are captured by the client, and they can use a shortcut to uncapture it