TeamViewer not working on Fedora 31
Comments
-
Same issue! I'm running:
- TeamViewer 14.7.1965
- Fedora release 31 (Thirty One)
- 5.3.8-300.fc31.x86_64
- GDM 3.34.1
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.
0 -
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?
1 -
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.
1 -
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
2 -
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.
2 -
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
2 -
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...
3 -
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.
0 -
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.
3 -
Having the same issue here.
Journalctl produces the following output:Feb 27 10:56:52 TeamViewer[]: QSGContext::initialize: depth buffer support missing, expect rendering errors
Feb 27 10:56:52 TeamViewer[]: QSGContext::initialize: stencil buffer support missing, expect rendering errors
Feb 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 parents
Feb 27 10:56:52 TeamViewer[]: QSGContext::initialize: depth buffer support missing, expect rendering errors
Feb 27 10:56:52 TeamViewer[]: QSGContext::initialize: stencil buffer support missing, expect rendering errors
Feb 27 10:56:52 TeamViewer[]: QSGContext::initialize: depth buffer support missing, expect rendering errors
Feb 27 10:56:52 TeamViewer[]: QSGContext::initialize: stencil buffer support missing, expect rendering errorsSteps to reproduce:
- Install official Teamviewer x86-64 rpm package
- Start Teamviewer
- Click on any entry in the menu bar
- Teamviewer freezes
System
- Fedora 31 64bit (5.5.5-200.fc31.x86_64)
- Gnome Version 3.34.4
- Display manager: Wayland
- Intel® HD Graphics 520 (Skylake GT2)
Any help would be greatly appreciated!
0 -
Having the same issue here.
Journalctl produces the following output:Feb 27 10:56:52 TeamViewer[]: QSGContext::initialize: depth buffer support missing, expect rendering errors
Feb 27 10:56:52 TeamViewer[]: QSGContext::initialize: stencil buffer support missing, expect rendering errors
Feb 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 parents
Feb 27 10:56:52 TeamViewer[]: QSGContext::initialize: depth buffer support missing, expect rendering errors
Feb 27 10:56:52 TeamViewer[]: QSGContext::initialize: stencil buffer support missing, expect rendering errors
Feb 27 10:56:52 TeamViewer[]: QSGContext::initialize: depth buffer support missing, expect rendering errors
Feb 27 10:56:52 TeamViewer[]: QSGContext::initialize: stencil buffer support missing, expect rendering errorsSteps to reproduce:
- Install official Teamviewer x86-64 rpm package
- Start Teamviewer
- Click on any entry in the menu bar
- Teamviewer freezes
System
- Fedora 31 64bit (5.5.5-200.fc31.x86_64)
- Gnome Version 3.34.4
- Display manager: Wayland
- Intel® HD Graphics 520 (Skylake GT2)
Any help would be greatly appreciated!
0 -
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 QThread
qrc:/ui/MainWindow/Meeting/MeetingJoinPanel.qml:79: TypeError: Cannot read property 'participantName' of null
qrc:/ui/MainWindow/Meeting/MeetingJoinPanel.qml:17: TypeError: Cannot read property 'joinEnabled' of null
qrc:/ui/MainWindow/Meeting/MeetingJoinPanel.qml:18: TypeError: Cannot read property 'joining' of null
qrc:/ui/MainWindow/Onboarding/OnboardingTab.qml:80: TypeError: Cannot read property 'headline' of null
qrc:/ui/MainWindow/Onboarding/OnboardingTab.qml:95: TypeError: Cannot read property 'image' of null
qrc:/ui/MainWindow/Onboarding/OnboardingTab.qml:101: TypeError: Cannot read property 'text' of null
QSGContext::initialize: depth buffer support missing, expect rendering errors
QSGContext::initialize: stencil buffer support missing, expect rendering errors
QSGContext::initialize: depth buffer support missing, expect rendering errors
QSGContext::initialize: stencil buffer support missing, expect rendering errors
qt.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 parents
QSGContext::initialize: depth buffer support missing, expect rendering errors
QSGContext::initialize: stencil buffer support missing, expect rendering errors0 -
I can confirm this bug in TeamViewer v15.5.3 at Fedora 32. Previously, at Fedora 31 I had also the same trouble.
2 -
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.
0 -
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.
0 -
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).
0 -
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.
0 -
@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).
Exactly. Using Xorg it works fine.
But why does Teamviever claim Wayland compatibility when its unusable in current state?
0 -
Running TeamViewer as
QT_QPA_PLATFORM=xcb teamviewer
works around the issue without requiring to use Xorg.
2 -
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.
0