Guide shortcuts not working on xbox ally x in gamemode

Describe the bug

When in gamemode, on an xbox ally x running bazzite, the controller setup that works the best, is mapping to “steamdeck”. However guide button shortcuts (holding the xbox button + another button, like x for keyboard, a for qam, right stick for cursor, etc) does not work. They do work like expected in desktop mode.
After debutfilm for 3-4 hours, I found the culprit: for desktop interceptor is set to none, and for gamemode it is set to either all or pass. If mannually changed to none, it fixes the issue, it reverts pretty quickly though. While set to none, the gamepadui overlay from xbox+b does not work.

To Reproduce

Steps to reproduce the behavior:

Install bazzite-deck on xbox ally x.
turn on device
try and hold the xbox button and move the cursor using the right stick.
do the same in desktop mode, and it works.
Alternative: check input test in steam in gamemode. Holding xbox button does nothing, not until another button is clicked, or it is released. (Same test in desktop mode works like normal)

Hardware Information:

xbox ally x:

Software Information:

OS Name
Bazzite

OS Codename
Kinoite

OS Variant
bazzite-deck

OS Version
44

OS Build
Stable (FA44.20260915)

Kernel Version
7.2.4-rog3.1.fc44.x86_64

BIOS Version
RC73XA.312

OpenGamepadUI Version
0.46.1-5

OS Architecture
x86_64

Desktop Environment
Gamescope Session

Additional context

Some games are pretty unplayable without the cursor. (In hhd xbox button would open hhd overlay, and armory crate would work as guide button, with the option of switching the 2. Maybe add something similar, so armory crate just opens ogui overlay, instead og xbox+b, and remove the need for an interceptor?)

You Can get the cursor active, by Holding Xbox, clicking another button (which makes the button actually click) and then moving the right stick.

I have been looking a little bit at this issue, together with an ai, to brainstorm ideas.
We have 3 ideas for solutions:

Opt-in, non-blocking chord recogniser in InputPlumber (suggesting moving it to guide+y as that one doesn't seem to have an action set by steam, could be kept on b though):

Forward Guide immediately while tracking it.
Consume the matching Y press/release natively.
Avoid UI round trips for ordinary gameplay input.
Handle releases and interception transitions consistently.

When testing, all button clicks, also activate the xbox/guide button, except for triggers, and stick movement. These could possibly be added, so they also activate it. (maybe it would make sense to just have all xbox/guide+ combos except b, to just forward their presses to the os, and let it handle it, instead of redoing the mapping again, like it is today?)
The last option is making something that specifically targets xbox ally x devices (I think everyone could benefit from this working better, but those devices have an extra available button, that the open menu action could be mapped to, instead of guide+b):

It would work something like this.

It detects the built-in Xbox Ally controller by its device name, board ID (RC73XA), and vendor, and applies the special handling only in overlay mode.
The Armoury Crate button reports as Keyboard; the new profile mapping turns it into OpenGamepadUI’s Quick Access button. On this device, Guide is no longer used to open OGUI, so Steam can still use it. Other controllers keep the
existing Guide/East shortcuts.
The policy is layered onto profiles at runtime and saved separately, preserving users’ global and per-game profiles.

Flow change: Previously, overlay setup returned early when launched without arguments, skipping UI cleanup and controller setup. Now it configures the overlay and input first, then starts Steam or another underlay only when
arguments are provided. This supports overlays started by another service, without launcher arguments; it also configures existing as well as newly connected controllers.

Comment:
There might be other solutions to this problem, not sure. I would like anyone more actively maintaining, to provide feedback for the suggestions.
I can help with implementation, but that would be AI assisted, not sure if that is a problem?

Special device handling isn't really a path forward. That would get complex quickly as many devices have need of such a quirk. There isn't really a way to decouple guide from chording generally and when OpenGamepadUI is running we always want to check it first to see if the events are needed by OpenGamepadUI.

The OpenGamepadUI chord forwarding in overlay could be improved. Something that forwards back all chords that aren't guide+b or qam2 would complete it. Currently we're only doing a subset.

That sounds like my option 2 suggestion. What is qam2? If you don’t mind me asking?

Made a pr into input plumber, to add analogue buttons as consumers, so guide is chord is fired when clicked.
ShadowBlip/InputPlumber#747

#564 then added this pr for cleanup of opengamepadUI. (can't for the love of me, figure out how to connect issues to prs)

PS, would be awesome to be able to remap how the menu opens, from guide+b. The xbox ally devices has extra buttons, and the armoury crate button would be perfect for this

PS, would be awesome to be able to remap how the menu opens, from guide+b. The xbox ally devices has extra buttons, and the armoury crate button would be perfect for this

Long press Library button will open OpenGamepadUI (QAM2), same button as QAM.

@ShadowApex

Copying reply from closed PR:
This is distinctly an OpenGamepadUI problem, not an InputPlumber problem, with a small caveat that in order to fix OpenGamepadUI properly there is another change that is needed. Namely, dbus events currently trigger bools only for joystick actions instead of the denormalized value.

The correct fix is to pass back al unused events from the client if they don't need the input. The entire purpose of PASS is to forward all input to the dbus client. Having a workaround that is baked in to how the Steam client operates as a workaround is antithetical to the design structure of the PASS mode.

The correct sequence should be:
Enter pass mode -> forward all input to dbus client -> dbus client looks at events -> consumes event or returns it if not consumed.

A good start on fixing that pattern would be to add a new class of dbus event for vec2 and vec 3 to pass the denormalized values to the client. @ShadowApex may have some thoughts on that though as clients will also need an update. Presumably they could be done at the same time as the full event pass back, but this would need to be coordinated as it is a breaking change.

In any case, this PR is not the direction forward for this issue.

Draft plan (that I brainstormed with AI)

What needs fixing today

The current code has three obstacles:

Lossy events: src/input/target/dbus.rs thresholds stick and trigger values into 0/1 events. src/input/event/dbus.rs drops vec3 values and does not represent every capability.
Incomplete return path: CompositeDevice.SendEvent accepts vec2/vec3 arrays, but ultimately calls write_event(), which still applies interception routing. It is not a reliable “return this event directly to virtual
devices” operation.
Client serialization: OpenGamepadUI’s extensions/core/src/dbus.rs cannot serialize Vector2, Vector3, or arrays, so receiving vectors alone would not enable round-trip forwarding.

Suggested implementation

1. Add a lossless D-Bus event stream

Keep the existing ui_* signals for compatibility, and introduce typed events carrying the capability and complete value, rather than only a derived UI action.

For example—names and signatures to agree with maintainers:

  ScalarEvent(event_id, capability, value)
  Vec2Event(event_id, capability, present_mask, x, y)
  Vec3Event(event_id, capability, present_mask, x, y, z)

Include equivalent button and touch representations.

Important details:

Preserve left/right stick identity, trigger magnitude, sensor identity, and unmapped buttons.
Emit analog changes without the UI navigation thresholds.
Preserve missing vector components. NativeEvent supports x: None; replacing that with zero would incorrectly reset an axis.
Keep UI navigation/deadzone processing separate from this transport.

Clarify “denormalized values” first: InputPlumber’s native stick/trigger values are already normalized. I would propose transmitting those values unchanged. Device-specific raw integers would require additional range/unit
metadata; sensor units also need documenting.

Primary files:

src/dbus/interface/target/dbus.rs
src/input/event/dbus.rs
src/input/target/dbus.rs

2. Add an explicit consume-or-return protocol

For the full pattern, I recommend retaining the original NativeEvent in InputPlumber and letting the client resolve it by ID:

  ResolveEvent(event_id, consumed)

consumed = true: discard it.
consumed = false: write the retained event directly to non-D-Bus targets.

This is safer than making the client reconstruct the event: it preserves the exact value, capability, and translation metadata.

The return path must:

Bypass interception, activation-chord detection, and D-Bus re-emission.
Avoid applying profiles twice.
Reject duplicate or stale resolutions.
Preserve per-device ordering, even if responses arrive out of order.
Define cleanup on mode changes, suspend, device removal, and client disconnect.

Use a single controlling client/session per device; other subscribers can remain observers. For high-rate stick/IMU input, support batched resolutions and bounded queues rather than an unlimited backlog.

3. Move input ownership into OpenGamepadUI

Extend its D-Bus proxy and Godot bindings to receive the typed events, then centralize the decision:

  receive event
      → UI/shortcut handling claims it
          → consume
      → otherwise
          → return

OpenGamepadUI should retain the original event alongside any derived Godot/UI action.

For chords:

Buffer possible chord-prefix events in OpenGamepadUI.
Consume them when an OpenGamepadUI shortcut matches.
Otherwise return the buffered events in order.
Return events only to the originating composite device.
Keep press/release ownership consistent across menu transitions.

That replaces the current capability whitelist and synthetic chord replay as the general forwarding mechanism. Steam-specific shortcut translations can remain client-side.

##Open contract question:
On current main, Pass is documented as “pass everything to targets except the guide button”, with activation-chord handling inside InputPlumber. That differs from the pastaq's comment about sending everything to the client, then return
unused events.

Should the new behavior replaces that contract or is negotiated through a new protocol/session. Adding vector signals can be backward-compatible; silently changing Pass cannot.

Incomplete return path: CompositeDevice.SendEvent accepts vec2/vec3 arrays, but ultimately calls write_event(), which still applies interception routing. It is not a reliable “return this event directly to virtual

Sort of. write_event is after the determination to change from pass to all/gamepad. Otherwise sending guide back would loop indefinitely already. The thinking was responsible clients should set this back to pass before returning events that way.

We could bypass write_event entirely in send_event and do a self.targets.write_event so that chains of events work that way as well.

Suggested implementation

1. Add a lossless D-Bus event stream

Keep the existing ui_* signals for compatibility, and introduce typed events carrying the capability and complete value, rather than only a derived UI action.

For example—names and signatures to agree with maintainers:
  ScalarEvent(event_id, capability, value)
  Vec2Event(event_id, capability, present_mask, x, y)
  Vec3Event(event_id, capability, present_mask, x, y, z)
Include equivalent button and touch representations.

Important details:
* Preserve left/right stick identity, trigger magnitude, sensor identity, and unmapped buttons.

This can be done by passing the full Capability string we already have

* Emit analog changes without the UI navigation thresholds.

* Preserve missing vector components. NativeEvent supports x: None; replacing that with zero would incorrectly reset an axis.

* Keep UI navigation/deadzone processing separate from this transport.
Clarify “denormalized values” first: InputPlumber’s native stick/trigger values are already normalized. I would propose transmitting those values unchanged. Device-specific raw integers would require additional range/unit metadata; sensor units also need documenting.

Agreed. That is what I intended to state.

Primary files:
* src/dbus/interface/target/dbus.rs

* src/input/event/dbus.rs

* src/input/target/dbus.rs
2. Add an explicit consume-or-return protocol

For the full pattern, I recommend retaining the original NativeEvent in InputPlumber and letting the client resolve it by ID:
  ResolveEvent(event_id, consumed)
* consumed = true: discard it.

* consumed = false: write the retained event directly to non-D-Bus targets.

This is an interesting idea but I'll need to consider the implications.

With the current SendEvent you could have a client apply additional translation, deadzones, amplitude scale vectoring before passing it back. That wouldn't be possible with the ResolveEvent model. You're also adding a dbus interface that way which has client side implications. I don't think latency would be different between the two.

This is safer than making the client reconstruct the event: it preserves the exact value, capability, and translation metadata.

The return path must:
* Bypass interception, activation-chord detection, and D-Bus re-emission.

* Avoid applying profiles twice.

* Reject duplicate or stale resolutions.

* Preserve per-device ordering, even if responses arrive out of order.

* Define cleanup on mode changes, suspend, device removal, and client disconnect.
Use a single controlling client/session per device; other subscribers can remain observers. For high-rate stick/IMU input, support batched resolutions and bounded queues rather than an unlimited backlog.

3. Move input ownership into OpenGamepadUI

Extend its D-Bus proxy and Godot bindings to receive the typed events, then centralize the decision:
  receive event
      → UI/shortcut handling claims it
          → consume
      → otherwise
          → return
OpenGamepadUI should retain the original event alongside any derived Godot/UI action.

For chords:
* Buffer possible chord-prefix events in OpenGamepadUI.

* Consume them when an OpenGamepadUI shortcut matches.

* Otherwise return the buffered events in order.

This is the key sticking point for doing things like returning guide. if unbounded it will only ever work on release. if bounded it will either be delays or make the real chord challenging.

* Return events only to the originating composite device.

* Keep press/release ownership consistent across menu transitions.
That replaces the current capability whitelist and synthetic chord replay as the general forwarding mechanism. Steam-specific shortcut translations can remain client-side.

##Open contract question: On current main, Pass is documented as “pass everything to targets except the guide button”, with activation-chord handling inside InputPlumber. That differs from the pastaq's comment about sending everything to the client, then return unused events.

I oversimplified. Pass exists as a state change trigger to switch from passing events to games, to instead passing events to dbus so they can be intercepted. When Guide is pressed the intercept mode becomes all. Then only the client can return to pass mode.

If we are going to pass an event back to InputPlumber the correct behavior is to set it back to pass. The client can have some logic about this too. I.e. on guide release set back to pass and forward other events. with guide down if it isn't something we consume.

Should the new behavior replaces that contract or is negotiated through a new protocol/session. Adding vector signals can be backward-compatible; silently changing Pass cannot.

Backwards compatibility is essential.

Some clarifying questions, from your comments and suggestions:

1. When should Guide-down reach the underlying application?

Some possible approaches are:

A. Forward Guide immediately

  Physical Guide-down
      → interception begins
      → OGUI records Guide as physically held
      → Guide-down is immediately forwarded to Steam

  While Guide remains held
      → eligible stick, trigger, and other input is returned
      → if continued shortcut recognition is supported:
          → OGUI keeps inspecting input
          → B can be consumed to open OGUI

  Physical Guide-up
      → outstanding releases are handled
      → Steam receives Guide-up if it received Guide-down
      → normal passthrough resumes when the OGUI menu is closed

Steam would see a continuous Guide hold. Holding it long enough without another button press might show Steam’s shortcut-help menu; that could be a useful consequence.

If OGUI subsequently consumes B, however, Steam has already received Guide-down and may still react to the hold or release. Continuing to recognize B also depends on whether
OGUI can return events while retaining access to subsequent input.

B. Withhold Guide until another eligible input occurs

  Physical Guide-down
      → interception begins
      → OGUI records and withholds Guide-down

  B arrives before Guide has been forwarded
      → OGUI consumes Guide+B
      → OGUI opens its menu
      → neither Guide nor B needs to reach Steam

  Stick movement, trigger input, or another eligible input arrives first
      → OGUI returns the withheld Guide-down
      → returns that input after it, preserving order and values
      → subsequent input continues to be inspected if that behavior is supported

  Physical Guide-up
      → if Guide was forwarded, return its release
      → otherwise, handle the standalone Guide press

This allows an initial Guide+B combination to remain invisible to Steam. Holding Guide alone would remain withheld, so Steam would not recognize that hold during the withheld
period.

What should count as an eligible follow-up input? Background sensor activity, stick drift, and trigger noise could otherwise cause Guide to be forwarded without an intentional
action. Any recognition rule should remain separate from transporting the actual analog values.

C. Withhold Guide for a fixed timeout

  Physical Guide-down
      → interception begins
      → OGUI records and withholds Guide-down
      → starts a timer

  B arrives before the timeout
      → OGUI consumes Guide+B
      → OGUI opens its menu without forwarding Guide

  Timeout expires without an OGUI shortcut
      → Guide-down is forwarded
      → eligible input is returned
      → subsequent input continues to be inspected if that behavior is supported

  Physical Guide-up
      → complete the appropriate release handling
      → normal passthrough resumes when the OGUI menu is closed

This provides an initial window in which Guide+B can remain invisible to Steam, while eventually allowing standalone Guide holds.

Details to clarify include:

What happens if stick or trigger input arrives before the timeout? Does it cause Guide-down to be returned first, wait behind the timer, or follow another rule?
How is a Guide press released before the timeout returned, including its duration?
What happens when B arrives after Guide has been forwarded?
What timeout behavior is acceptable?

The current API offers no established way to tell Steam that a newly delivered Guide-down has already been held for the withheld duration. The timeout may therefore add to
Steam’s own hold delay. Steam’s standalone hold-Guide shortcut help is not a requirement for this fix.

Which behavior should be supported, or is there another approach that fits the intended interaction?

2. If Guide has already been forwarded, what should happen when OGUI subsequently consumes B?

This question applies only to designs that allow OGUI to recognize Guide+B after Guide-down has reached Steam.

  Guide-down reaches Steam
      → B is subsequently pressed
      → OGUI consumes B and opens its menu
      → Steam eventually receives Guide-up

Steam has seen Guide but not B.

What is Steam’s actual behavior in this sequence for the relevant controller targets?
Is there a supported way to prevent Steam’s standalone Guide action after Guide-down has already been delivered?
If not, what behavior should be supported—for example, allowing both applications to react, limiting when OGUI can claim the chord, or another approach?

Sending Guide-up or clearing target state cannot simply be assumed to cancel an action; those operations may themselves look like a release to Steam.

This question would not apply when OGUI consumes the whole chord before forwarding Guide, or when later B presses are no longer recognized as OGUI shortcuts.

3. Where should Guide+B recognition happen?

The current overlay setup configures Guide+East as InputPlumber’s activation chord. A partial Guide press can be withheld while analog input continues without reaching OGUI’s
decision path.

Can updated OGUI configure Guide alone as the interception trigger and recognize Guide+B client-side, while retaining the existing interception contract for other clients?
Is another mechanism intended to make partial-chord stick and trigger events available to the client?

Adding vector signals alone would not resolve the missing Guide-down in the current partial-chord configuration.

4. Should OGUI optionally continue looking for B after Guide has been forwarded?

One possible behavior is for OGUI to remember that Guide remains physically held, return eligible input, and continue looking for B until Guide is released. Another possibility
is to end OGUI shortcut recognition once forwarding begins.

Should continued recognition be supported?
If so, can OGUI remain in ALL and return unused events directly to virtual targets, or would another mechanism be needed?
If continued recognition is not required, should returning input involve switching back to PASS?
How should the chosen behavior apply to SendEvent, delayed sends, and SendButtonChord?
Which existing bookkeeping, timing rules, and target-compatibility conversions must remain in the return path?

The return path also needs to avoid re-emitting returned input over D-Bus or applying the profile again.

5. What event and return API should represent full-fidelity input?

Some possible transport designs include:

Additive typed signals, alongside the existing UI signals. Illustrative shapes could be:

  ButtonEvent(capability, value)
  ScalarEvent(capability, value)
  Vec2Event(capability, present_mask, x, y)
  Vec3Event(capability, present_mask, x, y, z)
  TouchEvent(capability, index, is_touching, present_mask, pressure, x, y)

A presence mask could distinguish an absent component from an explicit zero. Common fields could carry translation-source metadata and any ordering information required.

A unified native-event signal, carrying a capability, a typed variant payload, and metadata. This could put different value types into one stream rather than separate signals.

Other representations may also fit the existing D-Bus API.

For returning input, possible approaches include:

Extending the values accepted by SendEvent to represent partial vectors, touch values, and translation metadata.
Adding a native-event send/return method while leaving the existing method unchanged.
Retaining the original event in InputPlumber and returning it by ID, potentially allowing an optional replacement or modification.
Another mechanism that preserves the required information and client-side transformations.

Questions to clarify:

Which event/value types must the initial implementation cover?
Which transport and return shapes fit the intended API?
How should absent fields, numeric precision, and translation-source metadata be preserved?
How should a client apply translations, deadzones, or scaling before returning input?
Which metadata needs to cross D-Bus, and which can remain inside InputPlumber?

Translation metadata can affect target behavior—for example, distinguishing profile-translated mouse movement from ordinary relative mouse movement—so preserving capability and
value alone may not cover every case.

The names and shapes above are examples, not proposed final signatures.

6. How should profile mappings interact with shortcuts?

For example, if a per-game profile swaps physical A and B:

Should Guide+B use the original physical B/East control, whichever control produces logical B/East after translation, a separate UI mapping, or another rule?
Should remapping Guide or B affect whether the OGUI shortcut remains available?
Which profile applies during shortcut recognition and menu navigation?
How are game-profile mappings preserved when unused input is returned?

7. What device ownership should client-side shortcut recognition use?

InputPlumber currently evaluates activation chords per composite device. OGUI’s client-side input-action state is global rather than inherently scoped to the originating
device.

If shortcut recognition moves into OGUI, should it retain per-composite ownership, allow combinations across controllers, or follow another rule?

For example, could Guide held on controller A combine with B pressed on controller B?

Existing menu-wide input blocking and navigation would remain unchanged.

8. Does existing device-removal cleanup cover client-side pending input?

InputPlumber already schedules virtual-target state clearing when a source device is removed. If no sources remain, it either stops the composite device and its targets or
clears target state for a persistent composite. OGUI also tracks composite-device removal.

Is that sufficient for any Guide holds or buffered events introduced by client-side recognition, or is additional cleanup required?

9. What ordering and duplicate-processing guarantees are needed?

What ordering is required across button, stick, trigger, touch, and sensor events?
How should events queued across interception-mode or profile changes be handled?
Are event IDs, sequence numbers, timestamps, or another mechanism needed?
How should legacy UI signals, full-fidelity signals, and multiple subscribers coexist without duplicate handling or returns?

One required observable behavior is that Guide-down reaches the underlying application before stick or trigger input that depends on it.

10. What are the end-to-end latency and throughput requirements?

InputPlumber handles source processing, profile translation, input routing, and virtual-device output. Client-side consume/return decisions introduce an OGUI round trip:

  InputPlumber
      → D-Bus
      → OGUI decides whether to consume or return
      → D-Bus
      → InputPlumber writes to virtual targets

OGUI currently receives D-Bus messages in its Rust backend and dispatches them into Godot through a frame-driven process() call. Using that path for forwarding decisions would
make its timing relevant to the round trip.

Which processing needs to happen in InputPlumber, OGUI’s backend, or the UI?
Can forwarding use the existing frame-dispatched client path, or must it operate independently?
What latency and throughput should the complete path support?
Is batching or analog-event coalescing permissible, and under what conditions?

11. Must independently upgraded installations be supported?

Do we need to support both:

New OGUI with older InputPlumber.
Older OGUI with new InputPlumber.

Or can the new functionality require a coordinated version pairing while existing APIs remain compatible?

12. Is client-failure handling part of this change?

Should handling OGUI crashes, D-Bus disconnections, or a connected-but-unresponsive client be in scope?

The detailed recovery policy can be discussed separately if this is in scope.

Okay dude, look, using AI as a tool certainly has its place and each individual is going to have to determine if/how/when they use it. For me, that is using local models in targeted ways and quadruple checking every step of their thinking and solutions. I frankly find it pretty disrespectful to be greeted with a huge wall of text that was quite obviously LLM generated which I can't even be sure you read it yourself. Minimum etiquette requires that you should at least have spent as much time writing your questions as I would need to spend reading it, which doesn't even account for the additional time I would need to spend considering each question and responding. I have no interest in being made a proxy for your AI prompts. If you can't just talk to me human to human then I have no interest in pursuing this issue with you further.

No disrespect meant, as I stated in my original ticket, I would be using llm's if I were to contribute.

And as you say, everyone is using it differently, for me, my workday has graduated into me ping-ponging with the llm, over a plan, going into every nitty gritty detail, which is also what I did here.
Both because that's what im used to now, and also because, tbh, this level in the software stack, is not something I have a lot of experience with, and going over things, asking for details about thing I don't understand, helps me learn.

If I had to learn the entire codebase, how it works and why, before I did anything, I would not have to time to contribute.

As you state, the questions were generated by AI, and I understand that you must get a tons of AI generated prs, issues, etc. what you can't see is that I spend several hours refining this list with the LLM, trying to understand the issues, answer them myself, rewording, etc. (English is also not my native language, so it helps with understandability)

There are things that I feel neither qualified for, nor the right person to decide/answer the direction of.

I don't want to contribute to your enjoyment working on this project, as im guessing its a passion, side project, then I will leave it here, for someone else to pick up at some point, if you are not interested in helping my progress this way.

Thank you for the effort in maintaining this project, and helping me avoid using windows.

Navigation Menu

Repository navigation

Guide shortcuts not working on xbox ally x in gamemode #549

Describe the bug

To Reproduce

Hardware Information:

Software Information:

Additional context

Draft plan (that I brainstormed with AI)

1. Add a lossless D-Bus event stream

2. Add an explicit consume-or-return protocol

3. Move input ownership into OpenGamepadUI

1. Add a lossless D-Bus event stream

2. Add an explicit consume-or-return protocol

3. Move input ownership into OpenGamepadUI

1. When should Guide-down reach the underlying application?

A. Forward Guide immediately

B. Withhold Guide until another eligible input occurs

C. Withhold Guide for a fixed timeout

2. If Guide has already been forwarded, what should happen when OGUI subsequently consumes B?

3. Where should Guide+B recognition happen?

4. Should OGUI optionally continue looking for B after Guide has been forwarded?

5. What event and return API should represent full-fidelity input?

6. How should profile mappings interact with shortcuts?

7. What device ownership should client-side shortcut recognition use?

8. Does existing device-removal cleanup cover client-side pending input?

9. What ordering and duplicate-processing guarantees are needed?

10. What are the end-to-end latency and throughput requirements?

11. Must independently upgraded installations be supported?

12. Is client-failure handling part of this change?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Guide shortcuts not working on xbox ally x in gamemode #549

Description

Describe the bug

To Reproduce

Hardware Information:

Software Information:

Additional context

Activity

morheddsb commented on Sep 15, 2026

morheddsb commented on Oct 2, 2026

pastaq commented on Oct 4, 2026

morheddsb commented on Oct 4, 2026

morheddsb commented on Oct 6, 2026

morheddsb commented on Oct 6, 2026

morheddsb commented on Oct 6, 2026

pastaq commented on Oct 7, 2026

morheddsb commented on Oct 7, 2026

Draft plan (that I brainstormed with AI)

1. Add a lossless D-Bus event stream

2. Add an explicit consume-or-return protocol

3. Move input ownership into OpenGamepadUI

pastaq commented on Oct 7, 2026

1. Add a lossless D-Bus event stream

2. Add an explicit consume-or-return protocol

3. Move input ownership into OpenGamepadUI

morheddsb commented on Oct 8, 2026

1. When should Guide-down reach the underlying application?

A. Forward Guide immediately

B. Withhold Guide until another eligible input occurs

C. Withhold Guide for a fixed timeout

2. If Guide has already been forwarded, what should happen when OGUI subsequently consumes B?

3. Where should Guide+B recognition happen?

4. Should OGUI optionally continue looking for B after Guide has been forwarded?

5. What event and return API should represent full-fidelity input?

6. How should profile mappings interact with shortcuts?

7. What device ownership should client-side shortcut recognition use?

8. Does existing device-removal cleanup cover client-side pending input?

9. What ordering and duplicate-processing guarantees are needed?

10. What are the end-to-end latency and throughput requirements?

11. Must independently upgraded installations be supported?

12. Is client-failure handling part of this change?

pastaq commented on Oct 9, 2026

morheddsb commented on Oct 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions