Bug 1413579 - Make libglvnd the default libGL.so.1 (and friends) provider
Summary: Make libglvnd the default libGL.so.1 (and friends) provider
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libglvnd
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nicolas Chauvet (kwizart)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-16 12:42 UTC by Hans de Goede
Modified: 2017-03-15 22:07 UTC (History)
14 users (show)

Fixed In Version: libglvnd-0.2.999-10.gitdc16f8c.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-26 01:35:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
PATCH: proposed packaging changes for this. (19.25 KB, patch)
2017-01-16 12:42 UTC, Hans de Goede
no flags Details | Diff
Updated patch with the proposed packaging changes (20.17 KB, patch)
2017-01-16 18:50 UTC, Hans de Goede
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1415687 0 unspecified CLOSED [RFE] ability to specify multiple actions in a single transaction 2021-02-22 00:41:40 UTC

Internal Links: 1415687

Description Hans de Goede 2017-01-16 12:42:33 UTC
Created attachment 1241217 [details]
PATCH: proposed packaging changes for this.

As discussed on the mailinglist, here is a bug for tracking making  libglvnd the default libGL.so.1 (and friends) provider.

Comment 1 Hans de Goede 2017-01-16 12:43:46 UTC
srpm with matching mesa changes can be found here:
https://fedorapeople.org/~jwrdegoede/mesa-13.0.3-2.fc26.src.rpm

Comment 2 Hans de Goede 2017-01-16 16:23:28 UTC
Hi,

(In reply to Hans de Goede from comment #1)
> srpm with matching mesa changes can be found here:
> https://fedorapeople.org/~jwrdegoede/mesa-13.0.3-2.fc26.src.rpm

Note I've just replaced this with a newer version which includes the fix for:

https://bugs.freedesktop.org/show_bug.cgi?id=98428

Regards,

Hans

Comment 3 Nicolas Chauvet (kwizart) 2017-01-16 16:31:15 UTC
Okay, this is a WIP review.

1/ This patch doesn't apply cleanly on the master branch. (you probably took origin/private-ajax over the master branch).

Also you removed a EGL patch that is now upstream, so I wonder how your testing was even done. ;)
This bug was reproducible with plasma desktop.

Please rebase on master. (or even refresh the snapshot from upstream. if needed).

2/ Some patches are from a known PR (Rob's armhfp ones), but others are not known. Can you please point to an upstream Bug or PR ? 

3/ Once libGL.so.1 is migrated from mesa to glvnd it will become the "natural" libGL provider. So the libGL%{_isa} virtual provide needs to be moved from mesa to glvnd. There is also a need to check for apps using a mesa-libGL requires (or BR). instead of libGL (not mesa-libGL-devel yet, but that would  be a separate step).

4/ You cannot revert the from mesa change you made. Please consider moving to _with_glvnd with this patch instead:
https://bugzilla.redhat.com/show_bug.cgi?id=1388810

5/ Have you tested pure mesa drivers with Intel/AMD dual gpu devices ?
As reported by jdieter, this was needed in his case:
https://bugs.freedesktop.org/show_bug.cgi?id=98428#c12


6/ The sub-packaging change you are suggesting is un-trivial and requires more work. I have theses patches from ajax under my radar. So I have a good understanding.


I also find some miss-design. Further I don't consider them as acceptable for f25, specially as it will break the f25 update policy contract (moving to libGL from mesa to glvnd can still be considered as an internal implementation, by design is compatible). Moving the packaging scheme where applications expect the GL backend to be found in libGL is a contract breaker.

The other point against this change in f25 is that it's basically unneeded (at least in the short term).
Many core (cairo/qt5/gnome-session) system libraries are using both libGL and libEGL and even GLESv2, so the result is that most sub-packages will ends in a desktop installed system rendering the split pointless.
The cost for adding gles,opengl by default (hence also mesa-libGLES)  would be minimal, even if uneeded by others dependencies.

I agree that this split might be good for the long term, but that can be f26 only IMO. Specially as I don't expect a Xorg less spin anytime soon.

The other point against is that it would be unreliable as there would be two(or more) backend provider for each gl,egl,gles split (mesa been the default).
It would be a similar situation than if we would split libdrm,mesa-dri-drivers,mesa-vdpau-drivers and DDX into each hardware vendor sub-packages.
Users would end in a situation where they have the each components from vendors that doesn't match.
The current situation is to have all drivers packed together. And that's a safer bet.

FYI, that's why our RPM Fusion repository has chosen to have the nvidia driver libEGL,GL,GLES into the same -libs sub-package, so that the right nvidia "backend" library is already installed when used.
I think that can be solved, but "again" can wait until f26.


Until then, here are critical bugs the would need to be fixed for the split:

-a/ Some ISA requires are missing. (from devel to sub-packages, also from sub-package to main in some cases). So I don't believe this change was even tested on new installation with multilibs context.

-b/ You can install libglvnd egl,gl,es,opengl without any related backend provider (mesa/nvidia/amdgpu), so this will leave a broken system on a new installation. (Best is to have mesa as a default provider, that's not much a question on my side).

-c/ You are adding some requires for mesa to "attempt" to workaround b/ (so mesa-{egl,gl,gles} requires the matching glvnd frontend). This will only work on upgrade installations where mesa is already installed (bringing glvnd). But as soon as mesa doesn't hold libGL.so.1 it will not be included from dependency computation from libGL.so users.

-d/ probably -opengl sub-package can be merged into the libglvnd (main), or the main merged into -opengl because thoses two packages aims at be here for the long run.

still need to read about your updated mesa package...


Further, there is probably a need to have a f26 feature for more advertising the needed changes wrt others packages. (having glvnd enabled mesa would be outside of the scope of this feature).

Comment 4 Nicolas Chauvet (kwizart) 2017-01-16 16:52:47 UTC
Also I would like to keep the _with_mesa_glvnd_default: so It would be possible to allow fast forward for el6 and el7 branches until we know how things will settle in el distro wrt this library.

Comment 5 Hans de Goede 2017-01-16 16:54:04 UTC
Hi,

(In reply to Nicolas Chauvet (kwizart) from comment #3)
> Okay, this is a WIP review.
> 
> 1/ This patch doesn't apply cleanly on the master branch. (you probably took
> origin/private-ajax over the master branch).

Yes it does, I just double checked.

> Also you removed a EGL patch that is now upstream, so I wonder how your
> testing was even done. ;)
> This bug was reproducible with plasma desktop.

I've rebased the snapshot to the latest upstream master, so the fix is included in the tarbal now.

> Please rebase on master. (or even refresh the snapshot from upstream. if
> needed).

Both are already done.

> 2/ Some patches are from a known PR (Rob's armhfp ones), but others are not
> known. Can you please point to an upstream Bug or PR ? 

Ok I will add links where available.

> 3/ Once libGL.so.1 is migrated from mesa to glvnd it will become the
> "natural" libGL provider. So the libGL%{_isa} virtual provide needs to be
> moved from mesa to glvnd.

Ok.

> There is also a need to check for apps using a
> mesa-libGL requires (or BR). instead of libGL (not mesa-libGL-devel yet, but
> that would  be a separate step).
> 
> 4/ You cannot revert the from mesa change you made. Please consider moving
> to _with_glvnd with this patch instead:
> https://bugzilla.redhat.com/show_bug.cgi?id=1388810

I don't see any value in this change, we've no plans to go back.

> 5/ Have you tested pure mesa drivers with Intel/AMD dual gpu devices ?
> As reported by jdieter, this was needed in his case:
> https://bugs.freedesktop.org/show_bug.cgi?id=98428#c12

cdieter has been testing my patches successfully with a mix of various cards, see bug 1411292.


> 6/ The sub-packaging change you are suggesting is un-trivial and requires
> more work. I have theses patches from ajax under my radar. So I have a good
> understanding.
> 
> 
> I also find some miss-design. Further I don't consider them as acceptable
> for f25, specially as it will break the f25 update policy contract (moving
> to libGL from mesa to glvnd can still be considered as an internal
> implementation, by design is compatible). Moving the packaging scheme where
> applications expect the GL backend to be found in libGL is a contract
> breaker.

This split is the same split as the current mesa pkg has, so I don't see how this is an issue, if an app requires libEGL.so then libglvnd-egl will get installed, libGL.so.1 -> -glx, exactly as what we've with mesa now I do not see how this is an issue.

> The other point against this change in f25 is that it's basically unneeded
> (at least in the short term).
> Many core (cairo/qt5/gnome-session) system libraries are using both libGL
> and libEGL and even GLESv2, so the result is that most sub-packages will
> ends in a desktop installed system rendering the split pointless.
> The cost for adding gles,opengl by default (hence also mesa-libGLES)  would
> be minimal, even if uneeded by others dependencies.
> 
> I agree that this split might be good for the long term, but that can be f26
> only IMO. Specially as I don't expect a Xorg less spin anytime soon.
> 
> The other point against is that it would be unreliable as there would be
> two(or more) backend provider for each gl,egl,gles split (mesa been the
> default).
> It would be a similar situation than if we would split
> libdrm,mesa-dri-drivers,mesa-vdpau-drivers and DDX into each hardware vendor
> sub-packages.
> Users would end in a situation where they have the each components from
> vendors that doesn't match.
> The current situation is to have all drivers packed together. And that's a
> safer bet.
> 
> FYI, that's why our RPM Fusion repository has chosen to have the nvidia
> driver libEGL,GL,GLES into the same -libs sub-package, so that the right
> nvidia "backend" library is already installed when used.
> I think that can be solved, but "again" can wait until f26.
> 
> 
> Until then, here are critical bugs the would need to be fixed for the split:
> 
> -a/ Some ISA requires are missing. (from devel to sub-packages, also from
> sub-package to main in some cases). So I don't believe this change was even
> tested on new installation with multilibs context.

Good catch, I will fix this.

> -b/ You can install libglvnd egl,gl,es,opengl without any related backend
> provider (mesa/nvidia/amdgpu), so this will leave a broken system on a new
> installation. (Best is to have mesa as a default provider, that's not much a
> question on my side).

Ack, I noticed that to I will make the various sub-pkg require the matching mesa-foo subpkg.

> -c/ You are adding some requires for mesa to "attempt" to workaround b/ (so
> mesa-{egl,gl,gles} requires the matching glvnd frontend). This will only
> work on upgrade installations where mesa is already installed (bringing
> glvnd). But as soon as mesa doesn't hold libGL.so.1 it will not be included
> from dependency computation from libGL.so users.

You mean requires to mesa, yes these are there to make sure the matching glvnd bits get installed for pkgs which directly require mesa, I agree we also need to add the Requires the other way.

> -d/ probably -opengl sub-package can be merged into the libglvnd (main), or
> the main merged into -opengl because thoses two packages aims at be here for
> the long run.
> 
> still need to read about your updated mesa package...
> 
> 
> Further, there is probably a need to have a f26 feature for more advertising
> the needed changes wrt others packages. (having glvnd enabled mesa would be
> outside of the scope of this feature).

There shouldn't be a need for changes outside of libglvnd + mesa.

Comment 6 leigh scott 2017-01-16 17:52:25 UTC
I'm +1 for the change to be applied to F26 branch, once we are happy it works I don't see any issue back porting it to f25.

Comment 7 Hans de Goede 2017-01-16 18:50:25 UTC
Created attachment 1241364 [details]
Updated patch with the proposed packaging changes

Here is a new version addressing all comments.

Comment 8 Nicolas Chauvet (kwizart) 2017-01-16 18:57:20 UTC
(In reply to Hans de Goede from comment #5)
[...]
> > 4/ You cannot revert the from mesa change you made. Please consider moving
> > to _with_glvnd with this patch instead:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1388810
> 
> I don't see any value in this change, we've no plans to go back.

Well, at least one compelling reason is to solve any bootstrapping issue.
Once mesa is glvnd enabled, it will requires glvnd and glvnd will requires mesa leading to a circle dependency.
Breaking the circle means build mesa without glvnd support first, then glvnd and mesa again with glvnd. It's better done with a build conditional.

Maybe it can be solved the other way. Switching off glvnd requires on mesa. But then I don't know how apps will handle libGL without any runtime provider.

I understand that you don't want to go back, but will you go forward for all current releases ? I'm pretty sure some will attempt to use newer mesa on older systems where glvnd isn't "yet" relevant to them. Also I'm not sure what's the plan for el6 and el7 based distro... I Imagine none can comment, but until it may be done, there is a need to have this feature switchable IMO.

It might also be needed for bug reproductive, under a non-glvnd enabled mesa.
(such as the one with https://bugs.freedesktop.org/98428 )

> > 6/ The sub-packaging change you are suggesting is un-trivial and requires
> > more work. I have theses patches from ajax under my radar. So I have a good
> > understanding.
> > 
> > 
> > I also find some miss-design. Further I don't consider them as acceptable
> > for f25, specially as it will break the f25 update policy contract (moving
> > to libGL from mesa to glvnd can still be considered as an internal
> > implementation, by design is compatible). Moving the packaging scheme where
> > applications expect the GL backend to be found in libGL is a contract
> > breaker.
> 
> This split is the same split as the current mesa pkg has, so I don't see how
> this is an issue, if an app requires libEGL.so then libglvnd-egl will get
> installed, libGL.so.1 -> -glx, exactly as what we've with mesa now I do not
> see how this is an issue.

Well, first this is an issue in stable because we will have two providers for lib*GL.so.* And most packages are using libGL.so.1 without more indication.
mesa-libGL from GA release
libglvnd-gl from updates.
The Upgrade path is clean from the main arch perspective, but if one has the wrong version of a given library (such as when trying from updates-testing) it will try to fetch it from the other package name, leading to dependency break.

Any users testing 64bit mesa from updates-testing, then installing 32bit packages from stable will be broken. This is reproducible, and so far cannot be fixed.

Anyhow with mesa/glvnd interlocking in place we will be on a safer side.

I'm only worried that everyone agree with that. One could consider that nvidia -libs can be a full replacement of mesa-*gl* and have a mesa free'd system.
I don't think that cannot be fixed. I think it's quite complex setup and I don't have yet a fully working solution. So if such request arise, I would request this to be a rawhide only solution.


> > Further, there is probably a need to have a f26 feature for more advertising
> > the needed changes wrt others packages. (having glvnd enabled mesa would be
> > outside of the scope of this feature).
> 
> There shouldn't be a need for changes outside of libglvnd + mesa.
Well, there are few packages with a bogus runtime requires on mesa-libGL
Also I think there is a plan to have the Khronos *gl* headers provided by the related libglvnd *-devel, so the bogus BR on mesa-libGL-devel might need to be fixed also.

Comment 9 Hans de Goede 2017-01-17 08:46:36 UTC
Hi,

(In reply to Nicolas Chauvet (kwizart) from comment #8)
> (In reply to Hans de Goede from comment #5)
> [...]
> > > 4/ You cannot revert the from mesa change you made. Please consider moving
> > > to _with_glvnd with this patch instead:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1388810
> > 
> > I don't see any value in this change, we've no plans to go back.
> 
> Well, at least one compelling reason is to solve any bootstrapping issue.
> Once mesa is glvnd enabled, it will requires glvnd and glvnd will requires
> mesa leading to a circle dependency.
> Breaking the circle means build mesa without glvnd support first, then glvnd
> and mesa again with glvnd. It's better done with a build conditional.

There is no circle, the glvnd packages only have a runtime dependency on mesa, not a buildtime one. And the one glvnd pkg mesa BuildRequires, libglvnd-core-devel does not have such a dependency.

> Maybe it can be solved the other way. Switching off glvnd requires on mesa.
> But then I don't know how apps will handle libGL without any runtime
> provider.
> 
> I understand that you don't want to go back, but will you go forward for all
> current releases ? I'm pretty sure some will attempt to use newer mesa on
> older systems where glvnd isn't "yet" relevant to them. Also I'm not sure
> what's the plan for el6 and el7 based distro... I Imagine none can comment,
> but until it may be done, there is a need to have this feature switchable
> IMO.
> 
> It might also be needed for bug reproductive, under a non-glvnd enabled mesa.
> (such as the one with https://bugs.freedesktop.org/98428 )
> 
> > > 6/ The sub-packaging change you are suggesting is un-trivial and requires
> > > more work. I have theses patches from ajax under my radar. So I have a good
> > > understanding.
> > > 
> > > 
> > > I also find some miss-design. Further I don't consider them as acceptable
> > > for f25, specially as it will break the f25 update policy contract (moving
> > > to libGL from mesa to glvnd can still be considered as an internal
> > > implementation, by design is compatible). Moving the packaging scheme where
> > > applications expect the GL backend to be found in libGL is a contract
> > > breaker.
> > 
> > This split is the same split as the current mesa pkg has, so I don't see how
> > this is an issue, if an app requires libEGL.so then libglvnd-egl will get
> > installed, libGL.so.1 -> -glx, exactly as what we've with mesa now I do not
> > see how this is an issue.
> 
> Well, first this is an issue in stable because we will have two providers
> for lib*GL.so.* And most packages are using libGL.so.1 without more
> indication.
> mesa-libGL from GA release
> libglvnd-gl from updates.
> The Upgrade path is clean from the main arch perspective, but if one has the
> wrong version of a given library (such as when trying from updates-testing)
> it will try to fetch it from the other package name, leading to dependency
> break.
> 
> Any users testing 64bit mesa from updates-testing, then installing 32bit
> packages from stable will be broken. This is reproducible, and so far cannot
> be fixed.

Mixing 64 bit stable updates with 32 bit unstable updates or the other way around has never worked, this is simply how multi-lib works, shared files must be identical. So you're worrying about an unsupported setup breaking.

> 
> Anyhow with mesa/glvnd interlocking in place we will be on a safer side.
> 
> I'm only worried that everyone agree with that. One could consider that
> nvidia -libs can be a full replacement of mesa-*gl* and have a mesa free'd
> system.
> I don't think that cannot be fixed. I think it's quite complex setup and I
> don't have yet a fully working solution. So if such request arise, I would
> request this to be a rawhide only solution.

I don't really see a valid use-case for a mesa-free system, I plan to add a systemd unit to the nvidia pkgs (at least the negativo17.org ones, but feel free to copy it)  which will automatically load nouveau.ko if nvidia.ko failed to load or bind to the gpu (e.g. gpu to old for the chosen nvidia driver), despite nouveau being blacklisted, to at least give people a working system / GUI in such cases instead of a black blinking screen as gdm keeps restarting. This fallback path requires mesa.

> > > Further, there is probably a need to have a f26 feature for more advertising
> > > the needed changes wrt others packages. (having glvnd enabled mesa would be
> > > outside of the scope of this feature).
> > 
> > There shouldn't be a need for changes outside of libglvnd + mesa.
> Well, there are few packages with a bogus runtime requires on mesa-libGL

Which will bring in libglvnd-glx through the Requires in mesa-libGL, so not an issue, not pretty, but it never was.

> Also I think there is a plan to have the Khronos *gl* headers provided by
> the related libglvnd *-devel, so the bogus BR on mesa-libGL-devel might need
> to be fixed also.

We will probably fix this the same way, or make the libglvnd-devel pkg obsolete + provide mesa-libGL-devel, but we will see about that when we get there.

Comment 10 Hans de Goede 2017-01-17 09:03:13 UTC
I've just started a rawhide build of an updated libglvnd implementing the changes from the latest patch I've attached here.

I will start a matching mesa build as soon as the new libglvnd build becomes available in the buildroot.

Comment 11 Nicolas Chauvet (kwizart) 2017-01-17 11:11:59 UTC
Good. 
Seems like you have missed some _isa requires from mesa to some libglvnd runtime or devel packages.

Comment 12 Hans de Goede 2017-01-17 11:30:52 UTC
Hi,

(In reply to Nicolas Chauvet (kwizart) from comment #11)
> Good. 
> Seems like you have missed some _isa requires from mesa to some libglvnd
> runtime or devel packages.

Good catch, thank you. The mesa build had not finished yet so I've cancelled it, added the _isa to all the libglvnd-foo requires and started a new build.

Regards,

Hans

Comment 13 leigh scott 2017-01-17 12:08:48 UTC
I have done a quick test of the new packages and they work ok with cinnamon.

$ rpm -qa mesa\* libglvnd\* *\nvidia\* |sort
akmod-nvidia-375.26-1.fc26.x86_64
kmod-nvidia-4.10.0-0.rc3.git0.1.fc26.x86_64-375.26-2.fc26.x86_64
kmod-nvidia-4.10.0-0.rc3.git1.2.fc26.x86_64-375.26-2.fc26.x86_64
kmod-nvidia-4.10.0-0.rc3.git4.2.fc26.x86_64-375.26-2.fc26.x86_64
libglvnd-0.2.999-7.gitdc16f8c.fc26.i686
libglvnd-0.2.999-7.gitdc16f8c.fc26.x86_64
libglvnd-core-devel-0.2.999-7.gitdc16f8c.fc26.x86_64
libglvnd-devel-0.2.999-7.gitdc16f8c.fc26.x86_64
libglvnd-egl-0.2.999-7.gitdc16f8c.fc26.i686
libglvnd-egl-0.2.999-7.gitdc16f8c.fc26.x86_64
libglvnd-gles-0.2.999-7.gitdc16f8c.fc26.i686
libglvnd-gles-0.2.999-7.gitdc16f8c.fc26.x86_64
libglvnd-glx-0.2.999-7.gitdc16f8c.fc26.i686
libglvnd-glx-0.2.999-7.gitdc16f8c.fc26.x86_64
libglvnd-opengl-0.2.999-7.gitdc16f8c.fc26.i686
libglvnd-opengl-0.2.999-7.gitdc16f8c.fc26.x86_64
mesa-dri-drivers-13.0.3-3.fc26.x86_64
mesa-filesystem-13.0.3-3.fc26.x86_64
mesa-libEGL-13.0.3-3.fc26.i686
mesa-libEGL-13.0.3-3.fc26.x86_64
mesa-libEGL-devel-13.0.3-3.fc26.x86_64
mesa-libgbm-13.0.3-3.fc26.i686
mesa-libgbm-13.0.3-3.fc26.x86_64
mesa-libgbm-devel-13.0.3-3.fc26.x86_64
mesa-libGL-13.0.3-3.fc26.i686
mesa-libGL-13.0.3-3.fc26.x86_64
mesa-libglapi-13.0.3-3.fc26.i686
mesa-libglapi-13.0.3-3.fc26.x86_64
mesa-libGL-devel-13.0.3-3.fc26.x86_64
mesa-libGLES-13.0.3-3.fc26.x86_64
mesa-libGLU-9.0.0-10.fc24.x86_64
mesa-libGLU-devel-9.0.0-10.fc24.x86_64
mesa-libwayland-egl-13.0.3-3.fc26.x86_64
mesa-libwayland-egl-devel-13.0.3-3.fc26.x86_64
mesa-libxatracker-13.0.3-3.fc26.x86_64
mesa-vulkan-drivers-13.0.3-3.fc26.x86_64
xorg-x11-drv-nvidia-375.26-7.fc26.x86_64
xorg-x11-drv-nvidia-cuda-375.26-7.fc26.x86_64
xorg-x11-drv-nvidia-kmodsrc-375.26-7.fc26.x86_64
xorg-x11-drv-nvidia-libs-375.26-7.fc26.i686
xorg-x11-drv-nvidia-libs-375.26-7.fc26.x86_64

$ ldd /usr/bin/cinnamon |grep GL
	libGL.so.1 => /lib64/libGL.so.1 (0x00007f587b327000)
	libEGL.so.1 => /lib64/libEGL.so.1 (0x00007f587857f000)
	libGLX.so.0 => /lib64/libGLX.so.0 (0x00007f5871047000)
	libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f5870d8f000)

Comment 14 Jan Pokorný [poki] 2017-01-20 13:49:29 UTC
After I had received mesa 13.0.3-3 update today in rawhide, sway WM
(it uses Wayland via wlc library) as packaged in Fedora stopped being
launchable as simply as "sway" on command line from virtual terminal
(I don't use any graphical login manager).

From then, "exec sway" in ~/.xinitrc exercised through "startx" is
required for sway to start because following message is printed
instead otherwise:

> cannot open display
> ERROR: swaybg requires the compositor to support the desktop-shell extension.

Not sure if it is expected. definitely running just sway was pretty
convenient.

Comment 15 Hans de Goede 2017-01-22 14:20:37 UTC
Hi, 

(In reply to Jan Pokorný from comment #14)
> After I had received mesa 13.0.3-3 update today in rawhide, sway WM
> (it uses Wayland via wlc library) as packaged in Fedora stopped being
> launchable as simply as "sway" on command line from virtual terminal
> (I don't use any graphical login manager).

Are you sure this is the cause ? Have you tried downgrading just mesa to the previous release, downloadable here:

https://koji.fedoraproject.org/koji/buildinfo?buildID=833542

(first remove libglvnd-* with rpm -e --nodeps) and leaving the rest as is?

> From then, "exec sway" in ~/.xinitrc exercised through "startx" is
> required for sway to start

You said sway uses wayland, of you use startx you are using X11 not wayland.

> because following message is printed instead otherwise:
> 
> > cannot open display
> > ERROR: swaybg requires the compositor to support the desktop-shell extension.

That does not sound (directly) libGL related ...

Regards,

Hans

Comment 16 Fabio Alessandro Locati 2017-01-23 10:19:39 UTC
sway is wayland based, but Fedora version is compiled with X11 support, if this could be the cause of the problem.

In fact, on an F25:

$ ldd /usr/bin/sway
	linux-vdso.so.1 (0x00007ffd9eddc000)
	libwlc.so.0 => /lib64/libwlc.so.0 (0x00007f497e903000)
	libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f497e6c3000)
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f497e450000)
	libjson-c.so.2 => /lib64/libjson-c.so.2 (0x00007f497e245000)
	libwayland-server.so.0 => /lib64/libwayland-server.so.0 (0x00007f497e032000)
	libinput.so.10 => /lib64/libinput.so.10 (0x00007f497ddff000)
	libpangocairo-1.0.so.0 => /lib64/libpangocairo-1.0.so.0 (0x00007f497dbf2000)
	libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x00007f497d9a7000)
	libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f497d755000)
	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f497d442000)
	libcairo.so.2 => /lib64/libcairo.so.2 (0x00007f497d119000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f497ce0e000)
	libcap.so.2 => /lib64/libcap.so.2 (0x00007f497cc09000)
	libgdk_pixbuf-2.0.so.0 => /lib64/libgdk_pixbuf-2.0.so.0 (0x00007f497c9e3000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f497c61d000)
	libchck-atlas.so.0 => /lib64/libchck-atlas.so.0 (0x00007f497c41a000)
	libchck-buffer.so.0 => /lib64/libchck-buffer.so.0 (0x00007f497c216000)
	libchck-dl.so.0 => /lib64/libchck-dl.so.0 (0x00007f497c012000)
	libchck-fs.so.0 => /lib64/libchck-fs.so.0 (0x00007f497be10000)
	libchck-lut.so.0 => /lib64/libchck-lut.so.0 (0x00007f497bc0c000)
	libchck-pool.so.0 => /lib64/libchck-pool.so.0 (0x00007f497ba07000)
	libchck-sjis.so.0 => /lib64/libchck-sjis.so.0 (0x00007f497b77f000)
	libchck-string.so.0 => /lib64/libchck-string.so.0 (0x00007f497b57c000)
	libchck-tqueue.so.0 => /lib64/libchck-tqueue.so.0 (0x00007f497b376000)
	libchck-unicode.so.0 => /lib64/libchck-unicode.so.0 (0x00007f497b173000)
	libchck-xdg.so.0 => /lib64/libchck-xdg.so.0 (0x00007f497af70000)
	libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f497acc7000)
	libudev.so.1 => /lib64/libudev.so.1 (0x00007f497aca6000)
	libGLESv2.so.2 => /lib64/libGLESv2.so.2 (0x00007f497aa9c000)
	libEGL.so.1 => /lib64/libEGL.so.1 (0x00007f497a865000)
	libdrm.so.2 => /lib64/libdrm.so.2 (0x00007f497a656000)
	libgbm.so.1 => /lib64/libgbm.so.1 (0x00007f497a449000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f497a245000)
	libX11.so.6 => /lib64/libX11.so.6 (0x00007f4979f06000)
	libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007f4979d04000)
	libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f4979afc000)
	libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f49798d4000)
	libxcb-ewmh.so.2 => /lib64/libxcb-ewmh.so.2 (0x00007f49796c7000)
	libxcb-composite.so.0 => /lib64/libxcb-composite.so.0 (0x00007f49794c4000)
	libxcb-xkb.so.1 => /lib64/libxcb-xkb.so.1 (0x00007f49792a8000)
	libxcb-image.so.0 => /lib64/libxcb-image.so.0 (0x00007f49790a3000)
	libxcb-xfixes.so.0 => /lib64/libxcb-xfixes.so.0 (0x00007f4978e99000)
	libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f4978c49000)
	libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f4978bbe000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f49789a0000)
	libffi.so.6 => /lib64/libffi.so.6 (0x00007f4978798000)
	librt.so.1 => /lib64/librt.so.1 (0x00007f4978590000)
	libmtdev.so.1 => /lib64/libmtdev.so.1 (0x00007f4978388000)
	libevdev.so.2 => /lib64/libevdev.so.2 (0x00007f497816e000)
	libwacom.so.2 => /lib64/libwacom.so.2 (0x00007f4977f64000)
	libpangoft2-1.0.so.0 => /lib64/libpangoft2-1.0.so.0 (0x00007f4977d4f000)
	libthai.so.0 => /lib64/libthai.so.0 (0x00007f4977b45000)
	libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007f4977943000)
	libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007f49776dd000)
	libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f4977499000)
	libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f49771ee000)
	libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f4976fbb000)
	libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x00007f4976db7000)
	libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007f4976ba9000)
	libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f497699d000)
	libXext.so.6 => /lib64/libXext.so.6 (0x00007f497678b000)
	libz.so.1 => /lib64/libz.so.1 (0x00007f4976575000)
	libGL.so.1 => /lib64/libGL.so.1 (0x00007f4976304000)
	/lib64/ld-linux-x86-64.so.2 (0x0000559381bf9000)
	libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f4976100000)
	libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f4975d6d000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f4975b50000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f4975929000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4975712000)
	libglapi.so.0 => /lib64/libglapi.so.0 (0x00007f49754e3000)
	libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0 (0x00007f49752de000)
	libxcb-dri3.so.0 => /lib64/libxcb-dri3.so.0 (0x00007f49750db000)
	libxcb-present.so.0 => /lib64/libxcb-present.so.0 (0x00007f4974ed6000)
	libxcb-sync.so.1 => /lib64/libxcb-sync.so.1 (0x00007f4974ccf000)
	libxshmfence.so.1 => /lib64/libxshmfence.so.1 (0x00007f4974acc000)
	libwayland-client.so.0 => /lib64/libwayland-client.so.0 (0x00007f49748bd000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f4974693000)
	libXau.so.6 => /lib64/libXau.so.6 (0x00007f497448d000)
	libxcb-util.so.1 => /lib64/libxcb-util.so.1 (0x00007f4974287000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f4974061000)
	liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f4973e4d000)
	libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f4973b67000)
	libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f4973953000)
	libgudev-1.0.so.0 => /lib64/libgudev-1.0.so.0 (0x00007f4973747000)
	libdatrie.so.1 => /lib64/libdatrie.so.1 (0x00007f497353f000)
	libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007f4973313000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f4973103000)
	libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007f4972f00000)
	libxcb-glx.so.0 => /lib64/libxcb-glx.so.0 (0x00007f4972ce3000)
	libXxf86vm.so.1 => /lib64/libXxf86vm.so.1 (0x00007f4972add000)
	libmount.so.1 => /lib64/libmount.so.1 (0x00007f4972893000)
	libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f4972650000)
	libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f4972449000)

Comment 17 Hans de Goede 2017-01-23 10:32:27 UTC
Hmm, so sway links to libwayland-server suggesting that it itself is a wayland server / compositor. As such it may need a patch similar to this one:

https://cgit.freedesktop.org/xorg/xserver/commit/?id=f4a41155479e68bf55740c1dfffafc78e4c02087

To make sure the a glvnd enabled libEGL knows which EGL implementation to load.

Eitherway given that no other problems have been reported I believe that it is best to report a new bug against sway for this and track this further in this new bug.

Comment 18 Fabio Alessandro Locati 2017-01-23 11:41:59 UTC
Yes, Sway is a wayland server (https://en.wikipedia.org/wiki/List_of_display_servers#Wayland)

Comment 19 Jan Pokorný [poki] 2017-01-23 12:51:02 UTC
Anyway, it would be perhaps preferred if such a disruptive update was
postponed for f26, in line with Fedora policies.

Comment 20 Jan Pokorný [poki] 2017-01-23 13:09:40 UTC
re [comment 15]:

Indeed, following sequence fixes the issue for me:

# rpm -e --nodeps libglvnd-{glx,egl,devel,gles}
# dnf downgrade  https://kojipkgs.fedoraproject.org//packages/mesa/13.0.3/2.fc26/x86_64/mesa-{dri-drivers,filesystem,libEGL,libGL,libGLES,libgbm,libglapi,libwayland-egl,libEGL-devel,libGL-devel,libwayland-egl-devel}-13.0.3-2.fc26.x86_64.rpm
# reboot   # for good measure, could be just a WM -> VT -> WM round trip

(I wish I could do it in a smoother way: [bug ]1415687].)

-> blacklisting mesa updates for the time being.

Comment 21 Fedora Update System 2017-01-23 14:30:21 UTC
libglvnd-0.2.999-7.gitdc16f8c.fc25 mesa-13.0.3-3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 22 Jan Pokorný [poki] 2017-01-24 10:04:49 UTC
The issue in the sway context (and perhaps elsewhere if observed) may be explained
with a difference in ldd output before and after the update:

$ comm -3 <(sed 's| (.*$||' sway_ldd.bad | sort) \
  <(sed 's| (.*$||' sway_ldd.good | sort) |\
   sed 's|\t\t|old only: |;s|\t|new only: |' | sort
> new only: libGLdispatch.so.0 => /lib64/libGLdispatch.so.0
> new only: libGLX.so.0 => /lib64/libGLX.so.0
> old only: libglapi.so.0 => /lib64/libglapi.so.0
> old only: libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0
> old only: libxcb-dri3.so.0 => /lib64/libxcb-dri3.so.0
> old only: libxcb-glx.so.0 => /lib64/libxcb-glx.so.0
> old only: libxcb-present.so.0 => /lib64/libxcb-present.so.0
> old only: libxcb-sync.so.1 => /lib64/libxcb-sync.so.1
> old only: libXdamage.so.1 => /lib64/libXdamage.so.1
> old only: libxshmfence.so.1 => /lib64/libxshmfence.so.1
> old only: libXxf86vm.so.1 => /lib64/libXxf86vm.so.1

Comment 23 Jan Pokorný [poki] 2017-01-25 10:58:32 UTC
... and this is the difference in the debug logs:

$ diff -u <(cut -d" " -f 4- swaylog.good.err) <(cut -d" " -f 4- swaylog.bad.err)
> [...]
>  [container.c:195] Creating default workspace 1
>  [container.c:212] Added workspace 1 for output 1
>  [layout.c:62] Adding 0x557dd31282c0 (2, 1920.000000x1080.000000) to 0x557dd30f0e50 (1, 1920.000000x1080.000000)
>  [debug_log.c:94] Setting focus to 0x557dd31282c0:18446744073709551615 (WORKSPACE '1')
>  [ipc-server.c:638] Sending workspace::focus event
> -[main.c:46] [wlc] EGL context is double buffered
> -[main.c:46] [wlc] EGL version: 1.4 (DRI2)
> -[main.c:46] [wlc] EGL vendor: Mesa Project
> -[main.c:46] [wlc] EGL client APIs: OpenGL OpenGL_ES 
> -[main.c:46] [wlc] EGL context (RGB888)
> -[main.c:46] [wlc] EGL_EXT_buffer_age EGL_EXT_image_dma_buf_import EGL_KHR_create_context EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_image_dma_buf_export EGL_WL_bind_wayland_display 
> -[main.c:46] [wlc] GL version: OpenGL ES 3.2 Mesa 13.0.3
> -[main.c:46] [wlc] GL vendor: Intel Open Source Technology Center
> -[main.c:46] [wlc] GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8888 GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_EXT_texture_sRGB_decode GL_OES_EGL_image GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer GL_EXT_read_format_bgra GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_OES_viewport_array GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug GL_KHR_robustness GL_KHR_texture_compression_astc_ldr GL_OES_depth_texture_cube_map GL_OES_surfaceless_context GL_EXT_color_buffer_float GL_EXT_separate_shader_objects GL_EXT_shader_framebuffer_fetch GL_EXT_shader_integer_mix GL_EXT_tessellation_point_size GL_EXT_tessellation_shader GL_ANDROID_extension_pack_es31a GL_EXT_copy_image GL_EXT_draw_buffers_indexed GL_EXT_draw_elements_base_vertex GL_EXT_gpu_shader5 GL_EXT_polygon_offset_clamp GL_EXT_primitive_bounding_box GL_EXT_shader_io_blocks GL_EXT_texture_border_clamp GL_EXT_texture_buffer GL_EXT_texture_cube_map_array GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_KHR_context_flush_control GL_KHR_robust_buffer_access_behavior GL_OES_copy_image GL_OES_draw_buffers_indexed GL_OES_draw_elements_base_vertex GL_OES_gpu_shader5 GL_OES_primitive_bounding_box GL_OES_sample_shading GL_OES_sample_variables GL_OES_shader_io_blocks GL_OES_shader_multisample_interpolation GL_OES_tessellation_point_size GL_OES_tessellation_shader GL_OES_texture_border_clamp GL_OES_texture_buffer GL_OES_texture_cube_map_array GL_OES_texture_stencil8 GL_OES_texture_storage_multisample_2d_array GL_EXT_blend_func_extended GL_EXT_buffer_storage GL_EXT_geometry_point_size GL_EXT_geometry_shader GL_EXT_shader_samples_identical GL_KHR_texture_compression_astc_sliced_3d GL_OES_geometry_point_size GL_OES_geometry_shader GL_OES_shader_image_atomic GL_EXT_clip_cull_distance GL_MESA_shader_integer_functions 
> -[main.c:46] [wlc] GLES2 renderer initialized
> -[main.c:46] [wlc] Set new bsurface to output (1)
> +[main.c:44] [wlc] Could not initialize any context
> +[main.c:46] [wlc] Released drm surface (0x563265ba69e8)
> +[main.c:46] [wlc] Removed bsurface from output (1)
>  [main.c:46] [wlc] Added output (1)
>  [main.c:46] [wlc] become active
> +[main.c:46] [wlc] Cleanup wlc
> +[exec_always.c:74] Child process created with pid 2524 for workspace 1
> +
> +the compositor to support the desktop-shell extension
> [...]

Comment 24 leigh scott 2017-01-25 11:22:46 UTC
(In reply to Jan Pokorný from comment #22)
> The issue in the sway context (and perhaps elsewhere if observed) may be
> explained
> with a difference in ldd output before and after the update:
> 
> $ comm -3 <(sed 's| (.*$||' sway_ldd.bad | sort) \
>   <(sed 's| (.*$||' sway_ldd.good | sort) |\
>    sed 's|\t\t|old only: |;s|\t|new only: |' | sort
> > new only: libGLdispatch.so.0 => /lib64/libGLdispatch.so.0
> > new only: libGLX.so.0 => /lib64/libGLX.so.0
> > old only: libglapi.so.0 => /lib64/libglapi.so.0
> > old only: libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0
> > old only: libxcb-dri3.so.0 => /lib64/libxcb-dri3.so.0
> > old only: libxcb-glx.so.0 => /lib64/libxcb-glx.so.0
> > old only: libxcb-present.so.0 => /lib64/libxcb-present.so.0
> > old only: libxcb-sync.so.1 => /lib64/libxcb-sync.so.1
> > old only: libXdamage.so.1 => /lib64/libXdamage.so.1
> > old only: libxshmfence.so.1 => /lib64/libxshmfence.so.1
> > old only: libXxf86vm.so.1 => /lib64/libXxf86vm.so.1

wlc seems to be failing


ldd /usr/lib64/libwlc.so.0 |grep glapi

The wlc code is supposed to load it

https://github.com/Cloudef/wlc/blob/master/src/platform/backend/drm.c#L510

Comment 25 Fabio Alessandro Locati 2017-01-25 11:58:47 UTC
I've rebuilt wlc based on latest HEAD yesterday to try to factor that out.
This should not be a problem for the specific line you highlighted, since is 2 years old.

Comment 26 Jan Pokorný [poki] 2017-01-27 12:40:40 UTC
[re comment 24]:

Well, it does load it, in runtime, which can hardly be captured in ldd
output if I am not mistaken.

From linker's debug log:

> calling init: /lib64/libGLESv2.so.2
> calling init: /lib64/libpixman-1.so.0
> calling init: /lib64/libchck-xdg.so.0
> calling init: /lib64/libchck-unicode.so.0
> calling init: /lib64/libchck-tqueue.so.0
> calling init: /lib64/libchck-string.so.0
> calling init: /lib64/libchck-sjis.so.0
> calling init: /lib64/libchck-pool.so.0
> calling init: /lib64/libchck-lut.so.0
> calling init: /lib64/libchck-fs.so.0
> calling init: /lib64/libchck-dl.so.0
> calling init: /lib64/libchck-buffer.so.0
> calling init: /lib64/libchck-atlas.so.0
> calling init: /lib64/libgdk_pixbuf-2.0.so.0
> calling init: /lib64/libcairo.so.2
> calling init: /lib64/libpangocairo-1.0.so.0
> calling init: /lib64/libinput.so.10
> calling init: /lib64/libjson-c.so.2
> calling init: /lib64/libxkbcommon.so.0
> calling init: /lib64/libwlc.so.0
>
> initialize program: /usr/bin/sway
>
> transferring control: /usr/bin/sway
> 
> file=libglapi.so.0 [0];  dynamically loaded by /lib64/libwlc.so.0 [0]
> find library=libglapi.so.0 [0]; searching
>  search cache=/etc/ld.so.cache
>   trying file=/lib64/libglapi.so.0
>
> file=libglapi.so.0 [0];  generating link map
>   dynamic: 0x00007f4fc53dad50  base: 0x00007f4fc51ae000   size: 0x000000000022e8f8
>     entry: 0x00007f4fc51b8320  phdr: 0x00007f4fc51ae040  phnum:                  8

I've also noticed that /lib64/libGLdispatch.so.0 is greedy to bind these symbols
that would otherwise likely be expected delivered by /lib64/libglapi.so.0:
_glapi_get_current, _glapi_tls_Current

Comment 27 Fedora Update System 2017-01-28 19:18:21 UTC
libglvnd-0.2.999-7.gitdc16f8c.fc25, mesa-13.0.3-3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 28 Fedora Update System 2017-01-29 07:38:25 UTC
libglvnd-0.2.999-7.gitdc16f8c.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 29 Jan Pokorný [poki] 2017-01-29 11:38:17 UTC
re [comment 5]:

>> Further, there is probably a need to have a f26 feature for more advertising
>> the needed changes wrt others packages. (having glvnd enabled mesa would be
>> outside of the scope of this feature).
> 
> There shouldn't be a need for changes outside of libglvnd + mesa.

Apparently it is, that's why I'd really want to see this only coming
in F26 and properly announced as new system-wide feature as it SHOULD
owing to the incompatibility with wlc library if no other software.

It seems ridiculous we got to the point Fedora is being optimized
for 3rd party proprietary software (drivers) through an artificial
metalayer at the expense of breaking other Fedora packages.

There's no "gamer" role per se mentioned at
https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Fedora_Workstation_PRD
Gamer intending to run Linux should think twice about the vendor
for the GPU, anyway.

That being said, I am willing to work towards the resolution of the
libglvnd vs. wlc issue, but currently I have zero knowledge in this
area, so it will be slow and painful trial and error.  Any pointers
welcome.

Comment 30 Hans de Goede 2017-01-29 11:45:54 UTC
Hi,

I believe that the best way forward with the sway / wlc issue is to contact sway and wlc upstream about this, perhaps they can help ?

Regards,

Hans

Comment 31 leigh scott 2017-01-29 12:01:28 UTC
(In reply to Jan Pokorný from comment #29)

Your argument is lame.
People install the nvidia driver because nouveau isn't reliable and is lagging on hardware support. 

> It seems ridiculous we got to the point Fedora is being optimized
> for 3rd party proprietary software (drivers) through an artificial
> metalayer at the expense of breaking other Fedora packages.
> 
> There's no "gamer" role per se mentioned at
> https://fedoraproject.org/wiki/Workstation/
> Workstation_PRD#Fedora_Workstation_PRD
> Gamer intending to run Linux should think twice about the vendor
> for the GPU, anyway.


Surely sacrificing a few sway users to fix the dreaded BSOD is worth it? :-)

Comment 32 Jan Pokorný [poki] 2017-01-29 12:05:26 UTC
Well, I suppose there should be summary of what is being changed
from the perspective of the surrounding packages supposed to adapt
to that.   That's why these would benefit heavily from proper
system-wide change.

Hans, you've already provided a link to xserver commit that may
come useful.  Is there any more to know about the changes?

Comment 33 Jan Pokorný [poki] 2017-01-29 12:07:52 UTC
Re [comment 31]:

Please, be more respectful when comparing the user base numbers
if you are making them up.

Comment 34 Hans de Goede 2017-01-29 13:32:15 UTC
Hi,

(In reply to Jan Pokorný from comment #32)
> Well, I suppose there should be summary of what is being changed
> from the perspective of the surrounding packages supposed to adapt
> to that.   That's why these would benefit heavily from proper
> system-wide change.
> 
> Hans, you've already provided a link to xserver commit that may
> come useful.  Is there any more to know about the changes?

Not really, the change should be transparent from an application using lib[E]GL pov, except for needing to help libEGL figure out what sort of 'window" handle you are passing in. Note that this is more of a X11 vs wayland problem which gets exposed by glvnd then really a glvnd problem. But if you do something similar to the mentioned xserver commit, then otherwise glvnd _should_ be transparent.

Regards,

Hans

Comment 35 Hans de Goede 2017-01-29 13:35:47 UTC
p.s.

Leight, Jan, please be excellent to each other:
https://getfedora.org/code-of-conduct

Comment 36 Hans de Goede 2017-01-29 13:56:43 UTC
I've put looking into the sway issue (and seeing if I can fix it) on my to do list for coming Monday.

Comment 37 Fedora Update System 2017-01-29 23:50:04 UTC
libglvnd-0.2.999-7.gitdc16f8c.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 38 Fedora Update System 2017-01-30 16:53:30 UTC
libglvnd-0.2.999-7.gitdc16f8c.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 39 Fedora Update System 2017-01-31 01:02:37 UTC
libglvnd-0.2.999-7.gitdc16f8c.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 41 Fedora Update System 2017-01-31 03:50:55 UTC
libglvnd-0.2.999-7.gitdc16f8c.fc25, mesa-13.0.3-6.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 42 Hans de Goede 2017-01-31 13:33:40 UTC
Ok,

I've fixed wlc (and thus sway) and a fixed wlc is building for f25+ now:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17524308
https://koji.fedoraproject.org/koji/taskinfo?taskID=17524338

I've also submitted a pull-req with the fix upstream:
https://github.com/Cloudef/wlc/pull/233

And I will add the f25 build to the libglvnd+mesa update in bodhi when it is done building:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547

Comment 43 Jan Pokorný [poki] 2017-01-31 13:45:55 UTC
Hans, thanks for the good news, it indeed works as expected once again
(exporting EGL_PLATFORM=gbm as suggested by Dave Arlie was verified as
workaround till those updates hit stable).

Comment 44 Fedora Update System 2017-01-31 13:53:58 UTC
libglvnd-0.2.999-7.gitdc16f8c.fc25 mesa-13.0.3-6.fc25 wlc-0.0.7-3.git12ee978.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 45 Fedora Update System 2017-01-31 23:49:18 UTC
libglvnd-0.2.999-7.gitdc16f8c.fc25, mesa-13.0.3-6.fc25, wlc-0.0.7-3.git12ee978.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 46 Fedora Update System 2017-02-02 15:25:45 UTC
libglvnd-0.2.999-9.gitdc16f8c.fc25 mesa-13.0.3-6.fc25 wlc-0.0.7-3.git12ee978.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 47 Fedora Update System 2017-02-02 22:49:28 UTC
libglvnd-0.2.999-9.gitdc16f8c.fc25, mesa-13.0.3-6.fc25, wlc-0.0.7-3.git12ee978.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 48 Fedora Update System 2017-02-03 09:04:35 UTC
libglvnd-0.2.999-9.gitdc16f8c.fc25 mesa-13.0.3-7.fc25 wlc-0.0.7-3.git12ee978.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 49 Fedora Update System 2017-02-03 23:49:07 UTC
libglvnd-0.2.999-9.gitdc16f8c.fc25, mesa-13.0.3-7.fc25, wlc-0.0.7-3.git12ee978.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 50 Fedora Update System 2017-02-06 14:53:52 UTC
libglvnd-0.2.999-10.gitdc16f8c.fc25 mesa-13.0.4-1.fc25 wlc-0.0.7-3.git12ee978.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 51 Fedora Update System 2017-02-07 02:49:08 UTC
libglvnd-0.2.999-10.gitdc16f8c.fc25, mesa-13.0.4-1.fc25, wlc-0.0.7-3.git12ee978.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 52 Fedora Update System 2017-02-15 14:18:33 UTC
libglvnd-0.2.999-10.gitdc16f8c.fc25 libva-1.7.3-3.fc25 mesa-13.0.4-1.fc25 wlc-0.0.7-3.git12ee978.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 53 Fedora Update System 2017-02-17 15:24:02 UTC
libglvnd-0.2.999-10.gitdc16f8c.fc25, libva-1.7.3-3.fc25, mesa-13.0.4-1.fc25, wlc-0.0.7-3.git12ee978.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9f6383547e

Comment 54 Fedora Update System 2017-02-26 01:35:16 UTC
libglvnd-0.2.999-10.gitdc16f8c.fc25, libva-1.7.3-3.fc25, mesa-13.0.4-1.fc25, wlc-0.0.7-3.git12ee978.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 55 JM 2017-03-10 13:32:22 UTC
libglvnd in mesa-13.0.4-1 broke a lot more than just sway, check 

Bug #1427174 
Bug #1429894

and

https://bugs.freedesktop.org/show_bug.cgi?id=99987#c7

Comment 56 Hans de Goede 2017-03-13 12:42:45 UTC
(In reply to JM from comment #55)
> libglvnd in mesa-13.0.4-1 broke a lot more than just sway, check 
> 
> Bug #1427174

Cannot reproduce, please provide detailed reproduction instructions in the bug.
 
> Bug #1429894

Fixed.

> and
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=99987#c7

Cannot reproduce, please provide detailed reproduction instructions in the bug.

Comment 57 Hans de Goede 2017-03-14 08:20:56 UTC
(In reply to JM from comment #55)
> libglvnd in mesa-13.0.4-1 broke a lot more than just sway, check 
> 
> Bug #1427174 
>
> and
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=99987#c7

Good news, "ln -s /usr/lib64/libGLX_mesa.so.0 /usr/lib64/libGLX_indirect.so.0" fixes this. I will prepare an update to add this to the Fedora mesa pkgs, but I need to coordinate this with the rpmfusion packages, since those currently add such a symlink to the nvidia libGLX.


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