PulseAudio + qemu-kvm VNC gives no sound
Hi there, Could you folks please help me understand how PulseAudio + VNC should work? I followed the Audio support (via PulseAudio) guide [0], and I'm able to make Guacd connect to the PulseAudio server running on my laptop. But I hear no sound coming from the remote machine. What I've done so far: === I'm running everything on my laptop. The "remote machine" is a RHEL 8.4 VM, running on top of qemu-kvm. I access it through the qemu-kvm built-in VNC server. The Guacamole and Guacd services are running as separate Podman containers. >From my browser, I can access my remote machine's graphical interface through the Guacamole containers. Now I want to hear the sound coming from the remote machine. I added the following line to my local machine's `/etc/pulse/default.pa`: load-module module-native-protocol-tcp auth-anonymous=1 ... and added the following parameters to the request to Guacamole: 'guac.enable-audio': "true", 'guac.audio-servername': "192.168.122.10", `192.168.122.10` is my laptop's virbr0 interface IP address. When I connect to the remote machine, Guacd logs show the following lines: guacd[105]: INFO: Connecting to PulseAudio... guacd[105]: INFO: Authorizing PulseAudio connection... guacd[105]: INFO: Sending client name... guacd[105]: INFO: PulseAudio now ready guacd[105]: INFO: Will use default sink: "alsa_output.usb-Dell_DELL_Slim_Soundbar_SB521A_SB521A-00.analog-stereo" guacd[105]: INFO: Starting streaming from "DELL Slim Soundbar SB521A Analog Stereo" guacd[105]: INFO: PulseAudio stream being created... guacd[105]: INFO: PulseAudio stream now ready `DELL Slim Soundbar ...` is the speaker attached to my laptop. What I was expecting: === I thought I could hear the sounds coming from the remote machine, by simply running `speaker-test` there. What I'm getting: === I hear no sound at all. My speaker is working fine, as I can hear sounds from my local machine. What am I doing wrong? [0] https://guacamole.apache.org/doc/gug/configuring-guacamole.html#audio-support-via-pulseaudio -- Lucio Seki He / Him / His Senior Systems Administrator, RH Training - Learning Platforms Red Hat <https://www.redhat.com/> lu...@redhat.com <https://www.redhat.com/>
Re: Clipboard bugs
Thanks Mike, I created the following issues in Guacamole JIRA: https://issues.apache.org/jira/browse/GUACAMOLE-1281 [Bug] Ctrl+V keyboard shortcut opens Open File dialog https://issues.apache.org/jira/browse/GUACAMOLE-1282 [New Feature] Add option to send key events instead of accessing the remote clipboard Regards, -- Lucio On Thu, Feb 4, 2021 at 6:07 PM Mike Jumper wrote: > On Wed, Feb 3, 2021 at 1:58 PM Lucio Seki wrote: > >> Thanks for the quick reply, Mike. >> >> On Wed, Feb 3, 2021 at 4:06 PM Mike Jumper >> wrote: >> >>> On Wed, Feb 3, 2021 at 3:52 AM Lucio Seki wrote: >>> >>>> ... >>>> >>> >>> In summary, following are the main issues I found: >>> 1. On RHEL8 and Fedora 33 locals, if you're using Firefox, pressing >>> Ctrl+V opens "Print" and/or "Open" window instead of pasting. >>> >>> This sounds like the clipboard contents are (somehow) being turned into >>> key events when a paste attempt is made, possibly by the >>> "Guacamole.InputSink" object recently added to allow dead keys to work. >>> >>> >> Should I report a bug for this? >> > > Yes, please. > > ... >> As I'm using KVM's VNC server, I don't have VNC servers running on the >> remote machines at all. >> It seems that KVM's VNC server doesn't have access to the VM's clipboard. >> > > Right - the clipboard isn't exposed at all via KVM's VNC server. > > In this case, would it be possible to make Google Chrome send key events >> instead, as in Firefox? >> > > Perhaps. Intentionally supporting paste via the browser's "Edit" menu and > sending the text as hopefully-equivalent keystrokes is an interesting idea. > Providing a similar option via the Ctrl+Alt+Shift menu could also be > interesting. When you pop over to our JIRA to report the issue with Firefox > paste behavior, I suggest also opening a feature request for this. > > Can you clarify what this means vs. what was mentioned earlier with >>> respect to Firefox? Inconsistent how? >>> >> >> Depending on the browser and the remote OS combination (the local OS >> doesn't matter), the behavior is different: >> - Firefox with remote RHEL8/Fedora 33: pastes the local clipboard content >> but replaces special characters with non-special characters. >> - Firefox with remote Windows 10: pastes the remote clipboard content. >> - Google Chrome with any local/remote OS combination: nothing happens. >> >> >>> The browser "Edit -> Paste" operation really should not be available. >>> >> >> So Google Chrome is behaving correctly by doing nothing, and Firefox is >> behaving unexpectedly by sending key events when it shouldn't. >> > > Yes. > > - Mike > >
Re: Clipboard bugs
Thanks for the quick reply, Mike. On Wed, Feb 3, 2021 at 4:06 PM Mike Jumper wrote: > On Wed, Feb 3, 2021 at 3:52 AM Lucio Seki wrote: > >> ... >> > > In summary, following are the main issues I found: > 1. On RHEL8 and Fedora 33 locals, if you're using Firefox, pressing > Ctrl+V opens "Print" and/or "Open" window instead of pasting. > > This sounds like the clipboard contents are (somehow) being turned into > key events when a paste attempt is made, possibly by the > "Guacamole.InputSink" object recently added to allow dead keys to work. > > Should I report a bug for this? 2. On RHEL8 and Fedora 33 remotes, if you're using Firefox, using browser >> Edit menu -> Paste will paste the local clipboard content, but special >> characters will be replaced by non-special ones (e.g. '#' becomes '3'). >> > > This sounds like a secondary manifestation of the above (clipboard > contents becoming key events under Firefox). The browser's own "Edit -> > Paste" option should not be available, and if used I wouldn't expect it to > have any effect. Local clipboard contents are forwarded to the remote end > through the clipboard functionality of the underlying protocol, with any > subsequent paste then happening only remotely. > > 3. On Windows 10 local, if you're using Google Chrome, you can't paste >> local clipboard content to the remote. >> > > Clipboard is definitely not fundamentally broken on Chrome. You should be > able to copy/paste directly using the local clipboard if you have granted > access when prompted. If you refused to grant access, you can edit the > contents of the clipboard using the clipboard interface in the Guacamole > menu (Ctrl+Alt+Shift). Beware that Chrome will refuse to prompt for access > if not operating over SSL. > > I'm not using SSL, so I added the Guacamole URL to the "Insecure origins treated as secure" setting (chrome://flags/#unsafely-treat-insecure-origin-as-secure) in order to grant access to the clipboard. Guacamole is able to read my local clipboard, as the Guacamole menu clipboard is updated with my local clipboard contents [0]. I think I'm facing the same issue as #5 and #6, as I'm always trying to connect to KVM instances, and KVM's VNC server running on the hypervisor doesn't have access to the VM's clipboard. I'll try a local Win 10 to remote Win 10 connection, and give an update on this. 4. On Windows 10 local, if you're using Firefox, you can't paste local >> clipboard content to the remote except if you use browser's Edit menu -> >> Paste, but you'll face issue #2. >> > > This also sounds the same as #1 - clipboard contents are being turned into > key events under Firefox, with further unexpected behavior due to Ctrl > being held if the paste occurs through Ctrl+V. > > 5. On RHEL8 and Fedora 33 remotes, the remote clipboard is not updated >> with the Guacamole clipboard content. >> 6. On RHEL8 and Fedora 33 remotes, the Guacamole clipboard won't be >> updated with the remote clipboard content. >> > > There are no known issues where clipboard would simply not work at all, > and it is unlikely that so fundamental a bug exists on the Guacamole side > (it would be easily noticed during testing and in regular use). Assuming > these are VNC machines, be sure to verify that the "vncconfig" tool is > running on the remote side, as Linux VNC servers normally require this for > clipboard to be forwarded back and forth. > > As I'm using KVM's VNC server, I don't have VNC servers running on the remote machines at all. It seems that KVM's VNC server doesn't have access to the VM's clipboard. In this case, would it be possible to make Google Chrome send key events instead, as in Firefox? > 7. Browser Edit menu -> Paste operation behavior is inconsistent among >> browsers/locals/remotes. >> > > Can you clarify what this means vs. what was mentioned earlier with > respect to Firefox? Inconsistent how? > Depending on the browser and the remote OS combination (the local OS doesn't matter), the behavior is different: - Firefox with remote RHEL8/Fedora 33: pastes the local clipboard content but replaces special characters with non-special characters. - Firefox with remote Windows 10: pastes the remote clipboard content. - Google Chrome with any local/remote OS combination: nothing happens. > The browser "Edit -> Paste" operation really should not be available. > So Google Chrome is behaving correctly by doing nothing, and Firefox is behaving unexpectedly by sending key events when it shouldn't. > If you're seeing this with Firefox, and the inconsistency is that the > option exists with Firefox but not other browsers, thi
Clipboard bugs
Hello folks, I found several clipboard issues using Guacamole 1.3.0, but couldn't find any related discussions in JIRA nor in the mailing list archive. Should I create bug reports for them? Following is the description of what I'm facing. --- # Overview I have 2 physical machines: - A laptop running RHEL8 - A laptop running Windows 10 On the RHEL8 laptop, I have 2 KVM instances: - Fedora 33 - RHEL8 Local/remote combinations I tested: - RHEL8/RHEL8 - RHEL8/Fedora 33 - RHEL8/Windows 10 - Fedora 33/RHEL8 - Fedora 33/Windows 10 - Windows 10/RHEL8 - Windows 10/Fedora 33 For RHEL8 and Fedora 33 remotes, I used the following environments: - Wayland (GNOME) - X11 (Gnome Classic) Web browsers I used for testing: - Google Chrome - Mozilla Firefox I executed the test in the 24 combinations from the above items. # Guacamole installation On the RHEL8 laptop, I created 2 Podman containers: - guacamole/guacd - guacamole/guacamole First, I defined the following user-mapping.xml: ``` vnc 10.88.0.1 5900 guacamole rdp 192.168.15.10 true ``` I started the containers running the following commands: ``` $ sudo podman run --name lseki-guacd \ -p 4822:4822 \ -e GUACD_LOG_LEVEL=debug \ -d guacamole/guacd $ sudo podman run --name lseki-guacamole \ -v `pwd`:/etc/guacamole --privileged \ -e GUACAMOLE_HOME=/etc/guacamole \ -e GUACD_HOSTNAME=10.88.0.1 \ -e GUACD_PORT=4822 \ -d -p 8080:8080 guacamole/guacamole ``` # Test scenario I executed the following steps to test the clipboard behavior: 1. open guacamole home in a private browser window 2. allow access to the clipboard if asked 3. login to the remote machine 4. open gedit/notepad and type: ``` L1#1234567890 L2#1234567890 L3#1234567890 L4#1234567890 L5#1234567890 #copied from remote clipboard#" ``` 5. on local machine, select and copy: ``` #copied from local clipboard# ``` 6. on remote machine, position the cursor after "L1#1234" and press Ctrl+V 7. close any window that might open 8. select "#copied from remote clipboard#" in the gedit/notepad and press Ctrl+C 9. position the cursor after "L2#1234" and press Ctrl+V 10. close any window that might open 11. position the cursor after "L3#1234", right click and Paste 12. press Ctrl+Shift+Alt to show Guacamole clipboard textarea, erase any text written there, and write "#copied from guacamole clipboard#" 13. Press Ctrl+Shift+Alt to hide Guacamole clipboard textarea 14. position the cursor after "L4#1234" and press Ctrl+V 15. close any window that might open 16. position the cursor after "L5#1234" and use the browser Paste option 17. close any window that might open 18. select all and press Ctrl+C 19. press Ctrl+Alt+Shift to show Guacamole clipboard textarea and copy what's written there 20. close gedit/notepad and logout I recorded the screen while running these tests and uploaded to YouTube [0]. I compiled the test results in CSV [1]. Please open it with some spreadsheet software, as GitHub doesn't render the linebreaks. # Test results In summary, following are the main issues I found: 1. On RHEL8 and Fedora 33 locals, if you're using Firefox, pressing Ctrl+V opens "Print" and/or "Open" window instead of pasting. 2. On RHEL8 and Fedora 33 remotes, if you're using Firefox, using browser Edit menu -> Paste will paste the local clipboard content, but special characters will be replaced by non-special ones (e.g. '#' becomes '3'). 3. On Windows 10 local, if you're using Google Chrome, you can't paste local clipboard content to the remote. 4. On Windows 10 local, if you're using Firefox, you can't paste local clipboard content to the remote except if you use browser's Edit menu -> Paste, but you'll face issue #2. 5. On RHEL8 and Fedora 33 remotes, the remote clipboard is not updated with the Guacamole clipboard content. 6. On RHEL8 and Fedora 33 remotes, the Guacamole clipboard won't be updated with the remote clipboard content. 7. Browser Edit menu -> Paste operation behavior is inconsistent among browsers/locals/remotes. --- Please let me know if I should create bug reports for the issues above. Regards, [0] https://www.youtube.com/playlist?list=PL-zQ6cGNR-toZKpJPbA3LE06eszyJOx_7 [1] https://gist.github.com/lucioseki/287f30fbtbd022fe0ff084667e25243da <https://gist.github.com/lucioseki/287f30fbbd022fe0ff084667e25243da> -- Lucio Seki He / Him / His Senior Systems Administrator, RH Training - Learning Platforms Red Hat <https://www.redhat.com/> lu...@redhat.com <https://www.redhat.com/>
