Enable GUI event buffering for new Whonix-Workstation qubes#20
Conversation
|
Discussed the approach taken here with Patrick, we'd like for this change to be effective for existing Whonix VMs as well. If this isn't merged before I get to it (probably later today), I'll likely force-push a new commit that achieves this. |
78c195f to
8dd5fdc
Compare
|
Fixed, now works for existing Whonix-Workstation VMs as well. |
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2025040403-4.3&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2025031804-4.3&flavor=update
Failed tests45 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/132953#dependencies 12 fixed
Unstable testsDetailsPerformance TestsPerformance degradation:11 performance degradations
Remaining performance tests:61 tests
|
|
PipelineRetry |
|
PipelineRetry |
|
I think you want to handle also domain-add event, otherwise new qubes will get the event buffering enabled only after qubesd restart (usually system restart). |
|
@marmarek Oof, didn't realize that. Thanks for pointing that out, will fix. |
8dd5fdc to
24e5c7a
Compare
|
Fixed now. |
Pretty much as straightforward as it gets. Tested by installing in dom0 on Qubes R4.3, then rebooting, then creating a new qube based on the whonix-workstation-17 template.
gui-events-max-delayfeature was set to100as expected and keyboard input into apps within the qube had noticeable jitter as desired.Fixes QubesOS/qubes-issues#9771