Try completely removing the policy file at ‘/etc/qubes/policy.d/50-sys-audio.policy’ (don’t forget to copy it somewhere beforehand to restore later) and reboot the system to see if the layout switching works as it should.
In my case shutting down sys-audio does the trick, but sometimes it requires some time after it shut down. No idea what’s wrong about it.
inconcistend behavior cant reproduce. sorry
I was using a debian based sys-audio qube for a while (Qubes version 4.2.1)
If anyone wants one based on fedora, this guide works for me (listening to audio on a bluetooth headset currently):
https://github.com/GammaSQ/qubes-doc/blob/sys-audio-setup/user/advanced-topics/audio-isolation.md
Added an optional package, nice to configure noise cancellation etc…
For the keyboard layout issue, just tested with
“setxkbmap fr” → “setxkbmap us” → “setxkbmap fr” … No issue
But
“setxkbmap -layout fr,us -option grp:win_space_toggle” then using the keymap to switch layout, and that way it seems I have the issue described by nokke / qubinator.
But since I never use keyboard layout switch, didn’t motivated myself to investigate it yet
Same here. After having the policy in place keyboard switching becomes barely usable. Removing policy (sometime it requires reboot on top) helps to get the switching back to normal.
Some observations:
Any ideas on how to troubleshoot it? Ready to try and test.
I don’t know how to fix the issue, but you can at least stop the layout change from breaking by patching the /usr/lib/python3.11/site-packages/qubesadmin/tools/qvm_start_daemon.py in dom0.
Create patch file in dom0 with this content:
296,297c296,297
< if new_property != current_property:
< self.current_vm.keyboard_layout = new_property
---
> # if new_property != current_property:
> self.current_vm.keyboard_layout = new_property
And apply the patch with the name patchfile:
sudo patch /usr/lib/python3.11/site-packages/qubesadmin/tools/qvm_start_daemon.py patchfile
The layout switch delay will remain but it won’t break the layout switching.
At least now there is an easy way to reproduce the problem. There must be some issue with the policies file, perhaps the problem with the layout is just a symptom of a larger issue that is not so noticeable. There are mentions of keyboard layout issues in this thread from May 2, so it has been around for some time.
Perhaps it is difficult for people for whom English is a second or third language to draw attention to the problem on the English forum.
Same for me. Delay seems to be different every time.
@neowutran thanks for the guide. I have a Salt formula based on the same policy.
Audio qube is debian based. Audio clients can be Debian or Fedora based, depends on specific package names to include other distributions such as Archlinux, Gentoo etc.
It works with Bluetooth, advanced audio processing (Easyeffects), USB, Jack and built-in audio of course.
(
Some log for the delay for the keyboard layout change
qvm_start_daemon.py(305): self.current_vm.keyboard_layout = new_property
--- modulename: base, funcname: __setattr__
base.py(358): if key.startswith('_') or key in self._local_properties():
--- modulename: base, funcname: _local_properties
base.py(348): if "_local_properties_set" not in cls.__dict__:
base.py(355): return cls._local_properties_set
base.py(360): if value is qubesadmin.DEFAULT:
base.py(371): if isinstance(value, qubesadmin.vm.QubesVM):
base.py(373): if value is None:
base.py(375): try:
base.py(376): self.qubesd_call(
base.py(377): self._method_dest,
base.py(378): self._method_prefix + 'Set',
base.py(379): key,
base.py(380): str(value).encode('utf-8'))
base.py(376): self.qubesd_call(
--- modulename: base, funcname: qubesd_call
base.py(72): if dest is None:
base.py(75): if self.app:
base.py(76): return self.app.qubesd_call(dest, method, arg, payload,
base.py(77): payload_stream)
base.py(76): return self.app.qubesd_call(dest, method, arg, payload,
--- modulename: app, funcname: qubesd_call
app.py(753): if payload_stream:
app.py(771): try:
app.py(772): client_socket = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
--- modulename: socket, funcname: __init__
socket.py(225): if fileno is None:
socket.py(226): if family == -1:
socket.py(228): if type == -1:
socket.py(230): if proto == -1:
socket.py(231): proto = 0
socket.py(232): _socket.socket.__init__(self, family, type, proto, fileno)
socket.py(233): self._io_refs = 0
socket.py(234): self._closed = False
app.py(773): client_socket.connect(qubesadmin.config.QUBESD_SOCKET)
app.py(778): call_header = '{}+{} dom0 name {}\0'.format(method, arg or '', dest)
app.py(779): client_socket.sendall(call_header.encode('ascii'))
app.py(780): if payload is not None:
app.py(781): client_socket.sendall(payload)
app.py(783): client_socket.shutdown(socket.SHUT_WR)
app.py(785): return_data = client_socket.makefile('rb').read()
it take a lot of time here
return_data = client_socket.makefile('rb').read()
for the api call
call_header = '{}+{} dom0 name {}\0'.format(method, arg or '', dest)
→
admin.vm.property.Set+keyboard_layout dom0 name dom0
Need to check what does the API do when it receive this event, probably the file “qubes/api/admin.py”
)
Thank you, if you need anything to apply and test, please let me know. The guide is awesome and I’d like to continue using sys-audio, but keyboard switching is another everyday necessity…
I am using Thinkpad T16, how to identify bluetooth controller.
Check the output of the lsusb command in your sys-usb and lspci command in your dom0.
I don’t want to have a dozen templates, is there any issue when installing these packages:
sudo dnf install -y pipewire-qubes qubes-audio-daemon pavucontrol qubes-core-admin-client qubes-usb-proxy alsa-utils
in your default template that you use for web browsing, you vpn qube etc…?
Also how can I activate pipewire in my qubes?
Currently I have to start it manually
systemctl --user restart pipewire
I am not sure how the service tab in qubes settings work, but can I add pipewire there?
If you install packages in to your default template then you increase
the attack surface of all qubes using that template.
Some of these packages should already be installed in a vanilla template.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
The only reason I am against having a dozen templates, is that there is no update cache.
Can I still set this up? The linked files are all removed from github
I have salt in GitHub - unman/shaker, and packaged from here
That’s an rpm that installs the state files and then runs an install,
setting up a caching proxy. Read the notes as it will make changes to
your templates.
If you need help with the install, let me know in a separate thread.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I have a USB bluetooth adapter that I want to use to attach my headphones/earbuds.
However, blueman can only connect to my bluetooth devices when it is run from my sys-usb qube. When I run blueman in the sys-audio qube it cannot connect.
Does this mean that the USB devices section of the troubleshooting applies?
If yes, how do I make an audio qube that is also a USB qube? I guess look up how to make a USB qube and then follow the above instructions?
you should passthrough the usb device corresponding to the bluetooth system.
You can do that with the GUI, or by command line something like that
qvm-usb attach --persistent sys-audio sys-usb:X-Y
is it normal behavior that I have to execute:
systemctl --user restart pipewire
In every VM in order for sys-audio to work?
It should work without restarting the service manually.
Maybe you have both pulseaudio and pipewire installed in your templates and it’s causing this issue?
What’s the output of this command in the qube with this issue?
dnf list installed | grep -e pipewire -e pulse