Bug 1560481 - Some core applications in Gnome 3.28 are unresponsive and not working on AMD graphics cards
Summary: Some core applications in Gnome 3.28 are unresponsive and not working on AMD ...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: clutter
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jonas Ådahl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Keywords:
: 1563826 (view as bug list)
Depends On:
Blocks: F28FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2018-03-26 09:40 UTC by Lukas Ruzicka
Modified: 2018-04-25 00:04 UTC (History)
27 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-04-25 00:04:11 UTC


Attachments (Terms of Use)
Totem weird characters Screenshot (67.58 KB, image/png)
2018-03-26 14:58 UTC, Alessio
no flags Details
Patch to trick cogl to avoid rgb10 (4.83 KB, application/mbox)
2018-04-23 21:39 UTC, Jonas Ådahl
no flags Details
dnf update history (17.24 KB, text/plain)
2018-04-24 03:00 UTC, Mark Chandler
no flags Details

Description Lukas Ruzicka 2018-03-26 09:40:39 UTC
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.

Comment 1 Lukas Ruzicka 2018-03-26 09:48:10 UTC
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

Comment 2 Lukas Ruzicka 2018-03-26 10:21:30 UTC
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

Comment 3 sumantro 2018-03-26 13:01:58 UTC
I can reproduce this one. So +1.

Comment 4 Quentin Tayssier 2018-03-26 13:05:22 UTC
I can reproduce to, so +1

Comment 5 Alessio 2018-03-26 13:21:08 UTC
Same problem like Totem one, but with Rythmbox

Comment 6 sumantro 2018-03-26 13:51:04 UTC
@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?

Comment 7 Alessio 2018-03-26 14:21:20 UTC
(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.

Comment 8 Alessio 2018-03-26 14:58 UTC
Created attachment 1413202 [details]
Totem weird characters Screenshot

Comment 9 Alessio 2018-03-26 15:05:29 UTC
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).

Comment 10 Lukas Ruzicka 2018-04-09 13:46:01 UTC
*** Bug 1563826 has been marked as a duplicate of this bug. ***

Comment 11 Kamil Páral 2018-04-09 14:59:01 UTC
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

Comment 12 Alessio 2018-04-09 16:56:54 UTC
I don't know, but I have issues even on a macbook using nouveau module, so it should not be strictly related to AMD.

Comment 13 Adam Williamson 2018-04-09 17:38:44 UTC
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 .

Comment 14 Geoffrey Marr 2018-04-09 17:53:03 UTC
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

Comment 15 Kalev Lember 2018-04-14 10:50:32 UTC
Could someone affected retest this with 3.28.1 once it lands in updates-testing, please? https://bodhi.fedoraproject.org/updates/FEDORA-2018-e67e16187d

Comment 16 Mark Chandler 2018-04-16 04:57:37 UTC
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).

Comment 17 Mikhail 2018-04-16 05:47:53 UTC
Nothing changed for me gnome 3.28.1
Controls in Totem player still unavailable.
GPU Vega 56

Comment 18 František Zatloukal 2018-04-16 13:53:02 UTC
It's still broken with gnome 3.28.1.

GPU: AMD Radeon R7 / AMD A10-7870K

Comment 19 František Zatloukal 2018-04-16 13:59:43 UTC
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)

Comment 20 Adam Williamson 2018-04-17 22:44:51 UTC
Mikhail, Frantisek - have you tried with mesa-18.0.0-4.fc28 , per Mark's comment? Is it still broken for you? Thanks!

Comment 21 Mikhail 2018-04-18 02:57:46 UTC
(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

Comment 22 František Zatloukal 2018-04-18 07:39:33 UTC
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)

Comment 23 Kalev Lember 2018-04-18 12:50:51 UTC
František, do you have mesa-dri-drivers installed?

Comment 24 František Zatloukal 2018-04-18 13:11:12 UTC
Yes, mesa-dri-drivers-18.0.0-4.fc28.x86_64 .

Comment 25 Adam Jackson 2018-04-18 15:36:41 UTC
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.

Comment 26 Mikhail 2018-04-18 15:47:25 UTC
(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

Comment 27 Kalev Lember 2018-04-19 19:49:14 UTC
Added Jonas to CC who might be able to help with this.

Comment 28 Adam Jackson 2018-04-19 19:59:49 UTC
(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.

Comment 29 Jonas Ådahl 2018-04-19 20:04:42 UTC
(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?

Comment 30 Adam Williamson 2018-04-19 20:23:36 UTC
Jonas: the early comments on the bug state that Cheese and Maps also have problems.

Comment 31 Jonas Ådahl 2018-04-19 21:10:08 UTC
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.

Comment 32 František Zatloukal 2018-04-20 07:47:45 UTC
(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.

Comment 33 Jonas Ådahl 2018-04-20 17:19:51 UTC
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

Comment 34 Mikhail 2018-04-20 18:02:51 UTC
(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.

Comment 35 Mikhail 2018-04-20 18:04:54 UTC
(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?

Comment 36 Jonas Ådahl 2018-04-20 18:40:14 UTC
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

Comment 37 Mikhail 2018-04-20 19:25:45 UTC
(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.

Comment 38 Adam Williamson 2018-04-23 19:20:39 UTC
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.

Comment 39 Jonas Ådahl 2018-04-23 21:39 UTC
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.

Comment 40 Adam Williamson 2018-04-23 22:07:55 UTC
Mikhail: Frantisek: can you please test the scratch build ASAP? Thanks a lot!

Comment 41 Adam Williamson 2018-04-24 01:40:09 UTC
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.

Comment 42 Michael Catanzaro 2018-04-24 02:04:27 UTC
(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.

Comment 43 Adam Williamson 2018-04-24 02:23:34 UTC
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.

Comment 44 Mark Chandler 2018-04-24 03:00 UTC
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.

Comment 45 Adam Williamson 2018-04-24 03:22:08 UTC
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.

Comment 46 František Zatloukal 2018-04-24 07:36:40 UTC
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).

Comment 47 Jonas Ådahl 2018-04-24 08:08:46 UTC
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

Comment 48 Jonas Ådahl 2018-04-24 09:48:41 UTC
Seems that build had a bogus date. Should be fixed here: https://koji.fedoraproject.org/koji/taskinfo?taskID=26534491

Comment 49 Mikhail 2018-04-24 10:54:32 UTC
(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

Comment 50 Jonas Ådahl 2018-04-24 12:31:41 UTC
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

Comment 51 Michael Catanzaro 2018-04-24 12:49:13 UTC
(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.

Comment 52 František Zatloukal 2018-04-24 13:15:19 UTC
(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!

Comment 53 Kalev Lember 2018-04-24 13:46:47 UTC
jadahl's merge request: https://src.fedoraproject.org/rpms/mesa/pull-request/3 (I asked ajax on irc to review it)

Comment 54 Fedora Update System 2018-04-24 18:45:01 UTC
mesa-18.0.1-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-1655474f95

Comment 55 Fedora Update System 2018-04-25 00:04:11 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.