Description of problem: When I want to play an ogg video via totem (does not matter if that is a remote or local file), totem only play sounds without picture. During the file being played, you cannot navigate in the video and when the video finishes, totem stays unresponsive and must be killed hard. After that, totem is started but does not create an application window, so it must be killed again. Sometimes, not always, this error is shown when trying to run totem from the terminal: (totem:1299): Gdk-WARNING **: 11:32:31.887: Native Windows taller than 65535 pixels are not supported It helps when I delete all totem configuration files from: ~/.config/totem ~/.cache/totem Then it starts with the app window again, but is not able to play videos properly. Version-Release number of selected component (if applicable): gnome-session-3.28.0-1.fc28.x86_64 totem-3.26.0-7.fc28.x86_64 How reproducible: Always Steps to Reproduce: 1. Install fresh system 2. Download an ogg video. 3. Run totem and open the video in it. Expected results: Totem should be able to play pictures, too, should enable navigation in the video, without freezes or hangs.
journalctl /usr/bin/totem produces: -- Logs begin at Mon 2018-03-26 10:30:13 CEST, end at Mon 2018-03-26 11:46:53 CEST. -- Mar 26 10:56:33 localhost.localdomain totem[2993]: Native Windows taller than 65535 pixels are not supported -- Reboot -- Mar 26 11:00:59 localhost.localdomain totem[2715]: Native Windows taller than 65535 pixels are not supported
Cheese and Maps behave the same way. The start, but do not produce any application window. Maps do not produce anything, but Cheese does: (cheese:4723): Gtk-WARNING **: 12:19:34.629: Theme parsing error: cheese.css:7:35: The style property GtkScrollbar:min-slider-length is deprecated and shouldn't be used anymore. It will be removed in a future version ** Message: 12:19:34.856: cheese-application.vala:211: Error during camera setup: No device found (cheese:4723): cheese-CRITICAL **: 12:19:34.867: cheese_camera_device_get_name: assertion 'CHEESE_IS_CAMERA_DEVICE (device)' failed (cheese:4723): GLib-CRITICAL **: 12:19:34.867: g_variant_new_string: assertion 'string != NULL' failed (cheese:4723): GLib-CRITICAL **: 12:19:34.867: g_variant_ref_sink: assertion 'value != NULL' failed (cheese:4723): GLib-GIO-CRITICAL **: 12:19:34.867: g_settings_schema_key_type_check: assertion 'value != NULL' failed (cheese:4723): GLib-CRITICAL **: 12:19:34.867: g_variant_get_type_string: assertion 'value != NULL' failed (cheese:4723): GLib-GIO-CRITICAL **: 12:19:34.868: g_settings_set_value: key 'camera' in 'org.gnome.Cheese' expects type 's', but a GVariant of type '(null)' was given (cheese:4723): GLib-CRITICAL **: 12:19:34.868: g_variant_unref: assertion 'value != NULL' failed ** (cheese:4723): CRITICAL **: 12:19:34.868: cheese_preferences_dialog_setup_resolutions_for_device: assertion 'device != NULL' failed
I can reproduce this one. So +1.
I can reproduce to, so +1
Same problem like Totem one, but with Rythmbox
@ales(In reply to Alessio from comment #5) > Same problem like Totem one, but with Rythmbox This is a supposed to be a different bug, can you please report a separate bug for this?
(In reply to sumantro from comment #6) > @ales(In reply to Alessio from comment #5) > > Same problem like Totem one, but with Rythmbox > > This is a supposed to be a different bug, can you please report a separate > bug for this? Never mind, please.
Created attachment 1413202 [details] Totem weird characters Screenshot
Same issue here with totem. In addition please look at the screenshot attachment 1413202 [details] strange characters. (Running on bare metal in basic video mode + XOrg, however in Wayland it looks ok).
*** Bug 1563826 has been marked as a duplicate of this bug. ***
Since bug 1563826 was merged here, I'm going to add that this bug seems to be exclusive to AMD graphics cards and there's an upstream report here: https://gitlab.gnome.org/GNOME/mutter/issues/2
I don't know, but I have issues even on a macbook using nouveau module, so it should not be strictly related to AMD.
Alessio: that's likely https://bugzilla.redhat.com/show_bug.cgi?id=1564210 . See if it works if you update to the brand-new mesa build linked in that bug. As a general note, if you're having issues with GNOME apps after recent F28 updates and you *don't* have an AMD card, you may well be hitting https://bugzilla.redhat.com/show_bug.cgi?id=1564210 .
Discussed during the 2018-04-09 blocker review meeting: [1] The decision to classify this bug as an AcceptedBlocker was made as it violates the following blocker criteria: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test" [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-04-09/f28-blocker-review.2018-04-09-16.01.txt
Could someone affected retest this with 3.28.1 once it lands in updates-testing, please? https://bodhi.fedoraproject.org/updates/FEDORA-2018-e67e16187d
This started working for me when I updated the mesa packages to 18.0.0-4. I've since retested after upgrading to gnome 3.28.1 packages and everything still seems fine. I've tested totem, cheese, and maps. I'm using an AMD graphics card (R9 370).
Nothing changed for me gnome 3.28.1 Controls in Totem player still unavailable. GPU Vega 56
It's still broken with gnome 3.28.1. GPU: AMD Radeon R7 / AMD A10-7870K
Adding lspci output, sorry for the noise: 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] [1002:130f] (rev d4)
Mikhail, Frantisek - have you tried with mesa-18.0.0-4.fc28 , per Mark's comment? Is it still broken for you? Thanks!
(In reply to Adam Williamson from comment #20) > Mikhail, Frantisek - have you tried with mesa-18.0.0-4.fc28 , per Mark's > comment? Is it still broken for you? Thanks! yes of course, mesa updated early and return hardware acceleration, but when come gnome update nothing changed for me. # rpm -qa | grep mesa mesa-dri-drivers-18.0.0-4.fc28.i686 mesa-filesystem-18.0.0-4.fc28.i686 mesa-libgbm-18.0.0-4.fc28.x86_64 mesa-libglapi-18.0.0-4.fc28.i686 mesa-libxatracker-18.0.0-4.fc28.x86_64 mesa-dri-drivers-18.0.0-4.fc28.x86_64 mesa-libGL-18.0.0-4.fc28.x86_64 mesa-libGL-18.0.0-4.fc28.i686 mesa-libglapi-18.0.0-4.fc28.x86_64 mesa-libEGL-18.0.0-4.fc28.x86_64 mesa-filesystem-18.0.0-4.fc28.x86_64 mesa-vulkan-drivers-18.0.0-4.fc28.x86_64 # rpm -qa | grep gnome qgnomeplatform-0.3-9.fc28.x86_64 fros-gnome-1.1-15.fc28.noarch gnome-documents-libs-3.28.0-1.fc28.x86_64 gnome-boxes-3.28.2-1.fc28.x86_64 gnome-screenshot-3.26.0-3.fc28.x86_64 gnome-terminal-3.28.1-1.fc28.x86_64 gnome-menus-3.13.3-9.fc28.x86_64 NetworkManager-openvpn-gnome-1.8.2-1.fc28.x86_64 gnome-initial-setup-3.28.0-6.fc28.x86_64 gnome-shell-extension-alternate-tab-3.28.1-1.fc28.noarch gnome-software-3.28.1-1.fc28.x86_64 NetworkManager-openconnect-gnome-1.2.4-9.fc28.x86_64 gnome-color-manager-3.28.0-1.fc28.x86_64 NetworkManager-pptp-gnome-1.2.6-1.fc28.x86_64 gnome-video-effects-0.4.3-3.fc28.noarch gnome-shell-extension-places-menu-3.28.1-1.fc28.noarch gnome-maps-3.28.1-1.fc28.x86_64 gnome-clocks-3.28.0-1.fc28.x86_64 gnome-disk-utility-3.28.1-1.fc28.x86_64 gnome-documents-3.28.0-1.fc28.x86_64 libgnome-keyring-3.12.0-14.fc28.x86_64 gnome-settings-daemon-3.28.1-1.fc28.x86_64 gnome-shell-extension-launch-new-instance-3.28.1-1.fc28.noarch gnome-classic-session-3.28.1-1.fc28.noarch gnome-photos-3.28.0-1.fc28.x86_64 gnome-online-miners-3.26.0-2.fc28.x86_64 gnome-logs-3.28.0-1.fc28.x86_64 gnome-online-accounts-3.28.0-1.fc28.x86_64 gnome-autoar-0.2.3-1.fc28.x86_64 gnome-themes-extra-3.28-1.fc28.x86_64 gnome-session-wayland-session-3.28.1-1.fc28.x86_64 gnome-user-share-3.28.0-1.fc28.x86_64 gnome-bluetooth-3.28.0-1.fc28.x86_64 gnome-shell-debugsource-3.28.0-1.fc28.x86_64 NetworkManager-vpnc-gnome-1.2.4-7.fc28.x86_64 f28-backgrounds-gnome-28.1.2-1.fc28.noarch gnome-weather-3.26.0-4.fc28.noarch gnome-bluetooth-libs-3.28.0-1.fc28.x86_64 libgnomekbd-3.26.0-4.fc28.x86_64 NetworkManager-ssh-gnome-1.2.7-3.fc28.x86_64 gnome-session-xsession-3.28.1-1.fc28.x86_64 gnome-control-center-3.28.1-2.fc28.x86_64 gnome-shell-extension-window-list-3.28.1-1.fc28.noarch gnome-font-viewer-3.28.0-1.fc28.x86_64 gnome-control-center-filesystem-3.28.1-2.fc28.noarch gnome-abrt-1.2.6-3.fc28.x86_64 gnome-shell-extension-common-3.28.1-1.fc28.noarch gnome-user-docs-3.28.1-1.fc28.noarch gnome-calculator-3.28.1-1.fc28.x86_64 gnome-keyring-pam-3.28.0.2-1.fc28.x86_64 gnome-contacts-3.28.1-1.fc28.x86_64 gnome-backgrounds-3.28.0-1.fc28.noarch gnome-usage-3.28.0-1.fc28.x86_64 gnome-desktop3-3.28.1-1.fc28.x86_64 gnome-keyring-3.28.0.2-1.fc28.x86_64 gnome-shell-3.28.1-1.fc28.x86_64 gnome-system-monitor-3.28.1-1.fc28.x86_64 gnome-session-3.28.1-1.fc28.x86_64 gnome-shell-extension-apps-menu-3.28.1-1.fc28.noarch gnome-shell-extension-background-logo-3.24.0-5.fc28.noarch pinentry-gnome3-1.1.0-2.fc28.x86_64 gnome-getting-started-docs-3.28.1-1.fc28.noarch gnome-shell-debuginfo-3.28.0-1.fc28.x86_64 gnome-characters-3.28.0-1.fc28.x86_64 desktop-backgrounds-gnome-28.0.0-1.fc28.noarch gnome-calendar-3.28.1-1.fc28.x86_64
Yeah, I have mesa-18.0.0-4.fc28 Apart from that, I was able to confirm this same issue on another generation of AMD GPUs: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/580] [1002:67df] (rev e7)
František, do you have mesa-dri-drivers installed?
Yes, mesa-dri-drivers-18.0.0-4.fc28.x86_64 .
Having trouble reproducing this locally. It would be helpful to see what totem is stuck doing when it fails to create a window. If you can reproduce this, please 'dnf debuginfo-install totem' and then, when it hangs creating a window, 'pstack $(pidof totem)' and attach the resulting output.
(In reply to Adam Jackson from comment #25) > Having trouble reproducing this locally. It would be helpful to see what > totem is stuck doing when it fails to create a window. If you can reproduce > this, please 'dnf debuginfo-install totem' and then, when it hangs creating > a window, 'pstack $(pidof totem)' and attach the resulting output. You misunderstand me. Totem not hang. Root of problem in impossible interacting with GUI by mouse pointer, but possible stop/play and rewind videos by keyboard. And it only affected AMD GPU because they implemented 10 bits per component colour formats. All about this issue already described here: https://gitlab.gnome.org/GNOME/mutter/issues/2
Added Jonas to CC who might be able to help with this.
(In reply to Mikhail from comment #26) > (In reply to Adam Jackson from comment #25) > > Having trouble reproducing this locally. It would be helpful to see what > > totem is stuck doing when it fails to create a window. If you can reproduce > > this, please 'dnf debuginfo-install totem' and then, when it hangs creating > > a window, 'pstack $(pidof totem)' and attach the resulting output. > > You misunderstand me. Totem not hang. Root of problem in impossible > interacting with GUI by mouse pointer, but possible stop/play and rewind > videos by keyboard. And it only affected AMD GPU because they implemented 10 > bits per component colour formats. Intel supports 10bpc formats too. What I was trying to say by "having trouble reproducing this" is that this doesn't happen on my radeon setup. The upstream bug report you link to is about gnome-shell, which has a forked copy of cogl internally. Presumably the upstream bug you linked to is about that copy of cogl, and not the system copy that totem will use.
(In reply to Mikhail from comment #26) > (In reply to Adam Jackson from comment #25) > > Having trouble reproducing this locally. It would be helpful to see what > > totem is stuck doing when it fails to create a window. If you can reproduce > > this, please 'dnf debuginfo-install totem' and then, when it hangs creating > > a window, 'pstack $(pidof totem)' and attach the resulting output. > > You misunderstand me. Totem not hang. Root of problem in impossible > interacting with GUI by mouse pointer, but possible stop/play and rewind > videos by keyboard. And it only affected AMD GPU because they implemented 10 > bits per component colour formats. > > All about this issue already described here: > https://gitlab.gnome.org/GNOME/mutter/issues/2 Is it possible to interact with other user interface other than totem?
Jonas: the early comments on the bug state that Cheese and Maps also have problems.
If it's just cheese, maps and totem, but not most of the others, then it's not gnome-shell issue. It's more likely a clutter (the client side application library, not the mutter fork) issue, and not probably not a cogl issue. Sadly we can't just port over the fix in mutter since mutter itself has its own cogl backend where the issue is fixed. I'm not sure the issue can be fixed without adding cogl API so that clutter can enforce a pixel format it already assumes when picking.
(In reply to Jonas Ådahl from comment #29) > Is it possible to interact with other user interface other than totem? Yes, I can interact other UIs just fine (also with buttons in Totem/Maps Titlebar). I didn't test Cheese; Totem and Maps are affected and I didn't see any issues in anything else. Just noting that updating to mesa-18.0.1-1.fc28 didn't solve this issue.
So, as far as I can tell (given the logs provided in the upstream mutter bug) it's not a gnome-shell or mutter issue; input events are provided as intended. Some things to try to narrow things down: Does disabling rgb10 make any difference? I think this might work doing that (correct me if I'm wrong): allow_rgb10_configs=false totem Does it reproduce with just clutter? Build clutter and run CLUTTER_BACKEND=wayland ./examples/basic-actor Does it reproduce with just clutter-gtk? Build clutter-gtk and run ./examples/gtk-clutter-events
(In reply to Jonas Ådahl from comment #33) > Does disabling rgb10 make any difference? I think this might work doing that > (correct me if I'm wrong): > > allow_rgb10_configs=false totem > yes. with allow_rgb10_configs=false totem work as expected.
(In reply to Jonas Ådahl from comment #33) > Does it reproduce with just clutter? Build clutter and run > > CLUTTER_BACKEND=wayland ./examples/basic-actor > > Does it reproduce with just clutter-gtk? Build clutter-gtk and run > > ./examples/gtk-clutter-events where I can get basic-actor and gtk-clutter-events binaries or source code for compilation?
basic-actor is an example bundled with clutter. clutter is available either via git at https://git.gnome.org/browse/clutter or as a tarball at https://download.gnome.org/sources/clutter/1.26/clutter-1.26.2.tar.xz gtk-clutter-events is an example bundled with clutter-gtk. clutter-gtk is available ither via git at https://git.gnome.org/browse/clutter-gtk or as a tarball at https://download.gnome.org/sources/clutter-gtk/1.8/clutter-gtk-1.8.4.tar.xz
(In reply to Jonas Ådahl from comment #33) > Does it reproduce with just clutter? Build clutter and run > > CLUTTER_BACKEND=wayland ./examples/basic-actor > Yes. All squares not reacting on mouse pointer and does not clickable. Mouse events start capturing after adding allow_rgb10_configs=false before launch command. > Does it reproduce with just clutter-gtk? Build clutter-gtk and run > > ./examples/gtk-clutter-events No. All mouse event was captured without `allow_rgb10_configs=false` hack.
So, just to make sure folks know about the timeframe here - this is a Fedora 28 Final blocker, and go/no-go is on Thursday, which means we *really* need this fixed/bodged up ASAP, ideally by tomorrow morning North American time or sooner, to avoid slipping the release. Since it seems that disabling rgb10 support in clutter avoids the problem, if we can't do a better fix yet, would it be plausible to just do a build of clutter with rgb10 support entirely removed/disabled as a short-term fix for this, then we could ship a better fix as a post-release update? Thanks a lot! I'm gonna take the liberty of assigning this to Jonas since he seems to be working on it most actively.
Created attachment 1425751 [details] Patch to trick cogl to avoid rgb10 I can't reproduce this locally using intel (force-enabling rgb10 configs just makes mesa complain about unsupported formats), so I'm not able to debug this. Here, however, is a scratch build with an untested work-around: https://koji.fedoraproject.org/koji/taskinfo?taskID=26523115 It contains the attached patch, which should simply skip any fbconfig (for Wayland or GLX) that has a red bit size larger than 8. Trying this locally doesn't make cogl on intel work (it'll instead complain about GL framebuffer commands failing), but as far as I can tell, it'll select the same framebuffer config as it would if rgb10 configs were not enabled. If this doesn't work, we can also consider disabling rgb10 globally.
Mikhail: Frantisek: can you please test the scratch build ASAP? Thanks a lot!
Hah, it just so happens my test box actually has a GPU affected by this problem, so I can test it. Unfortunately it makes things worse. The entire 'map' pane in Maps is empty (just blank light grey), and it crashes on exit with "_cairo_hash_table_destroy: Assertion 'hash_table->live_entries == 0' failed." While it's running, many errors "Cogl-WARNING **: 21:37:37.472: driver/gl/cogl-framebuffer-gl.c:1253: GL error (1286): Invalid framebuffer operation" are shown. Totem behaves very similarly - the whole pane where the video should be is grey (dark grey as it's a dark themed app), and similar "Invalid framebuffer operation" errors appear on the console while it's running.
(In reply to Mark Chandler from comment #16) > This started working for me when I updated the mesa packages to 18.0.0-4. If we're going to avoid slipping, we'll might need to downgrade mesa. Would be good to have that update prepared as a backup plan, if nothing else.
mcatanzaro: not quite sure what you're proposing, but not mesa 18.0.0-4 does *not* fix the remaining problems that Mikhail, Frantisek and I are seeing. Not sure what it fixed for Mark, but it definitely didn't fix anything for us.
Created attachment 1425776 [details] dnf update history Just in case what I've written about updating mesa is a red herring, I went back and found what I'm pretty sure is the update that fixed this problem for me. I've added the output of "dnf history info" for it as an attachment. I noticed that clutter and the kernel were also updated as part of the update.
Mark: we're testing with everything updated to current F28. I don't think this is a case of you and us testing different packages. It's a case, I think, of different hardware.
Okay, this is interesting. That scratch build ( https://koji.fedoraproject.org/koji/taskinfo?taskID=26523115 ) fixed all the issues in Xorg session (Totem/Maps are working just fine now), but made it worse in Wayland session (the same symptoms like Adam mentioned). Adam, can you confirm this? If it happens to be true, we can use fix included in scratch build and force X session on AMD cards for GA (this can be changed later with an update).
Here is a scratch build that should disable rgb10 configs by default for all gallium based drivers in mesa: https://koji.fedoraproject.org/koji/taskinfo?taskID=26532590
Seems that build had a bogus date. Should be fixed here: https://koji.fedoraproject.org/koji/taskinfo?taskID=26534491
(In reply to Jonas Ådahl from comment #48) > Seems that build had a bogus date. Should be fixed here: > https://koji.fedoraproject.org/koji/taskinfo?taskID=26534491 This is normal? Result BuildError: error building package (arch x86_64), mock exited with status 1; see build.log for more information
There was some issue with the build root. Here is a build that seems to have succeeded: https://koji.fedoraproject.org/koji/taskinfo?taskID=26537264
(In reply to Adam Williamson from comment #43) > mcatanzaro: not quite sure what you're proposing, but not mesa 18.0.0-4 does > *not* fix the remaining problems that Mikhail, Frantisek and I are seeing. > Not sure what it fixed for Mark, but it definitely didn't fix anything for > us. He said that was the build that introduced the problem, so you'd have to test something older... since we need to have an update submitted within the next couple of hours, I would recommend preparing a downgrade to mesa 17 to use as backup in case Jonas's scratch build doesn't fix the problem.
(In reply to Jonas Ådahl from comment #50) > There was some issue with the build root. Here is a build that seems to have > succeeded: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=26537264 It's fixed in this build. Both on Wayland and Xorg sessions. Yay!
jadahl's merge request: https://src.fedoraproject.org/rpms/mesa/pull-request/3 (I asked ajax on irc to review it)
mesa-18.0.1-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1655474f95
mesa-18.0.1-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.