Just made an upgrade from Fedora 30 to Fedora 31. Using the latest TeamViewer 14.7.
It starts normally, but GUI freezes after a couple of seconds. Tried to uninstall and then install it again. No success.
Any ideas?
As posted on the Fedora forums here:
Quote:
"I was poking around different executables in `/opt/teamviewer/tv_bin/` landed on `/opt/teamviewer/tv_bin/TeamViewer`and received the message: "/opt/teamviewer/tv_bin/TeamViewer: error while loading shared libraries: libQt5Sensors.so.5: cannot open shared object file: No such file or directory"
I installed the qt5-qtsensors package via dnf, and voila."
And another important reply (quote):
"Their rpm is packaged wrong then, I don't see qt5-qtsensors in the Required package list on the teamviewer rpm".
Please, check if installing qt5-qtsensors fixes the problem. And if this is the case, the TeamViewer team should fix the required packages.
thanks, @pp3345
you are my hero. Edit the .desktop shortcut like this:
Exec=env QT_QPA_PLATFORM=xcb /opt/teamviewer/tv_bin/script/teamviewer
now teamviewer works in wayland too!! Can you belive it?
Running TeamViewer as
QT_QPA_PLATFORM=xcb teamviewer
works around the issue without requiring to use Xorg.
@absurd wrote: This is a wayland issue. Teamviewer does not work with wayland (yet). Teamviewer works with X11 though: Choose "gnome xorg" at login screen (little pref icon below username/password).
This is a wayland issue. Teamviewer does not work with wayland (yet). Teamviewer works with X11 though: Choose "gnome xorg" at login screen (little pref icon below username/password).
Exactly. Using Xorg it works fine.
But why does Teamviever claim Wayland compatibility when its unusable in current state?
This is absurd, @absurd, because it should work, too, at least for outgoing connections, see https://community.teamviewer.com/t5/Linux/State-of-Wayland-amp-TeamViewer/td-p/26340.
But after clicking on a menu Item, TV get's stuck at this point and you have to force close it.
For me the same applies, but as long as i dont use the top menu i can at least use the client.
As soon as i use the menu, for example to show a black screen on host when i work remotely, the complete client gets stuck.
Thats true for fedora 31 and 32 now.
Yes, development seems to have stalled as it pertains to Fedora. They seem not to be testing it on Fedora or giving it much attention at all. Works OK on CentOS, though.
I can confirm this bug in TeamViewer v15.5.3 at Fedora 32. Previously, at Fedora 31 I had also the same trouble.
Even with the newest version "teamviewer-15.4.4445-0.x86_64" of today (25 march 2020), this is still an issue.
When starting from the command line, I get the following errors when the actual issue happens:
QSocketNotifier: Can only be used with threads started with QThreadqrc:/ui/MainWindow/Meeting/MeetingJoinPanel.qml:79: TypeError: Cannot read property 'participantName' of nullqrc:/ui/MainWindow/Meeting/MeetingJoinPanel.qml:17: TypeError: Cannot read property 'joinEnabled' of nullqrc:/ui/MainWindow/Meeting/MeetingJoinPanel.qml:18: TypeError: Cannot read property 'joining' of nullqrc:/ui/MainWindow/Onboarding/OnboardingTab.qml:80: TypeError: Cannot read property 'headline' of nullqrc:/ui/MainWindow/Onboarding/OnboardingTab.qml:95: TypeError: Cannot read property 'image' of nullqrc:/ui/MainWindow/Onboarding/OnboardingTab.qml:101: TypeError: Cannot read property 'text' of nullQSGContext::initialize: depth buffer support missing, expect rendering errorsQSGContext::initialize: stencil buffer support missing, expect rendering errorsQSGContext::initialize: depth buffer support missing, expect rendering errorsQSGContext::initialize: stencil buffer support missing, expect rendering errorsqt.qpa.wayland: setGrabPopup called with a parent, QtWaylandClient::QWaylandXdgSurface(0x3171d90) which does not match the current topmost grabbing popup, QtWaylandClient::QWaylandXdgSurface(0x38ed5f0) According to the xdg-shell protocol, this is not allowed. The wayland QPA plugin is currently handling it by setting the parent to the topmost grabbing popup. Note, however, that this may cause positioning errors and popups closing unxpectedly because xdg-shell mandate that child popups close before parentsQSGContext::initialize: depth buffer support missing, expect rendering errorsQSGContext::initialize: stencil buffer support missing, expect rendering errors
Having the same issue here. Journalctl produces the following output:
Feb 27 10:56:52 TeamViewer[]: QSGContext::initialize: depth buffer support missing, expect rendering errorsFeb 27 10:56:52 TeamViewer[]: QSGContext::initialize: stencil buffer support missing, expect rendering errorsFeb 27 10:56:52 TeamViewer[]: qt.qpa.wayland: setGrabPopup called with a parent, QtWaylandClient::QWaylandXdgSurface(0x3ee1b10) which does not match the current topmost grabbing popup, QtWaylandClient::QWaylandXdgSurface(0x3211500) According to the xdg-shell protocol, this is not allowed. The wayland QPA plugin is currently handling it by setting the parent to the topmost grabbing popup. Note, however, that this may cause positioning errors and popups closing unxpectedly because xdg-shell mandate that child popups close before parentsFeb 27 10:56:52 TeamViewer[]: QSGContext::initialize: depth buffer support missing, expect rendering errorsFeb 27 10:56:52 TeamViewer[]: QSGContext::initialize: stencil buffer support missing, expect rendering errorsFeb 27 10:56:52 TeamViewer[]: QSGContext::initialize: depth buffer support missing, expect rendering errorsFeb 27 10:56:52 TeamViewer[]: QSGContext::initialize: stencil buffer support missing, expect rendering errors
Steps to reproduce:
System
Any help would be greatly appreciated!
What's going on here? Fedora 31 is a major distribution, and TeamViewer freezes up upon hitting "Options." I understand fixes can't be instant, but it would be nice if the devs could at least acknowledge that they can replicate these issues and can work on them.
I've been running into this issue when trying to hit `Extras` > `Options` on Fedora Workstation 31, on a totally clean installation.
I just saw that `teamviewer_15.0.8397.x86_64.rpm` has been released though--I will try to see if that works when I return back to my Fedora Workstation 31 machine later this evening.
Well it is maybe a Wayland related, but TeamViewer was working fine before Fedora 31 was released. Maybe the devs should update the packages to be compatible with latest Wayland or something?
@Esther, @DanielStm, please help us about this...
Facing similar problem on Fedora 31. Main or remote window will freezed after click its menu bar. It is happend on wayland session.
My temporary workaround. Login to xOrg session when need to use it
Yep... Totally useless on latest Fedora 31. It seems noone from the dev team is reading here. So no idea when (and if) this will be fixed at all.
Yes even I am facing same problem. I tried both 64 bit rpm and Other systems (not officially supported) 64 bit tar package but in both cases faced same issue. As soon as teamviewer generates user ID & password, immediately it gets strucked.
Please resolve issue
Again replying to myself... still the same issue with latest TeamViewer 15.
The GUI just freezes after a couple of seconds. Using the 64 bit rpm package.
Sorry for replying to myself, but Fedora is one of the major distributions out there and there is no official reply yet.
I've got some kudos from other members about this topic which maybe means that they have a similar problem.
There is another topic about problems with Fedora 31 here:
https://community.teamviewer.com/t5/TeamViewer-14/Fedora-31-WaitforConnectFailed/m-p/75457
And the problem there was solved this way:
"Problem solved by installing the "Other systems (not officially supported)" version. Something is wrong with the package version."
@Esther, can you please be so kind and give us some info?
Same issue! I'm running:
I imported the .asc and then used dnf to install teamviewer_14.7.1965.x86_64.rpm.
I notice that it all freezes if I try to select menu items in the GUI.
I tried poking around by running teamviewer from the command line to see if there might be any clues, but didn't see anything obvious. Also logged in with sudo su, and made sure the daemon was enabled and running, but still nothing.
Happy to send the zip of all the teamviewer logs from teamviewer ziplog to support if it's helpful.
Please advise.
