Hi
since last Monday or so, I have been able to run firefox over ssh anymore. I thought it was my setup, but further investigation showed that it is something specific to firefox.
My setup is a bit more convoluted than this, but I am able to do:
$ ssh -X localhost gnome-terminal
And it shows a terminal as expected
$ ssh -X localhost firefox
Without a firefox running will hang there forever, no output at all. I tried doing strace of it, and see that is waiting for futexes. But haven't been able to see what is happening.
Until last Tuesday or so (I am on F23) firefox worked over ssh without any problems. I have been running it like that for something like a year.
Anyone has any suggestion? I tried also
$ ssh -Y localhost firefox
And it didn't helped at all (not that I am sure of the difference either).
Later, Juan.
PD. Really, what I normally do is run ssh to a virtual manchine in the same host.
On Tue, Mar 08, 2016 at 03:25:05PM +0100, Juan Quintela wrote:
Anyone has any suggestion?
Does setting LIBGL_DRI3_DISABLE=1 help?
Rich.
"Richard W.M. Jones" rjones@redhat.com wrote:
On Tue, Mar 08, 2016 at 03:25:05PM +0100, Juan Quintela wrote:
Anyone has any suggestion?
Does setting LIBGL_DRI3_DISABLE=1 help?
Yes. This makes it work. Thanks a lot.
Later, Juan.
On Tue, 2016-03-08 at 17:54 +0100, Juan Quintela wrote:
Yes. This makes it work. Thanks a lot.
Then it was probably broken by this update:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253
Michael Catanzaro mcatanzaro@gnome.org wrote:
Yes. This makes it work. Thanks a lot.
Then it was probably broken by this update:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253
The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as well (running Iceweasel on a remote Debian box from a local Fedora box). Does that mean that there is an error in Fe- dora, Firefox/Iceweasel, something else? Is there a bug tracking this?
Tim
On Tue, 29 Mar 2016 19:22:31 +0200, Tim Landscheidt wrote:
Michael Catanzaro mcatanzaro@gnome.org wrote:
Then it was probably broken by this update:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253
The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as well (running Iceweasel on a remote Debian box from a local Fedora box). Does that mean that there is an error in Fe- dora, Firefox/Iceweasel, something else? Is there a bug tracking this?
libreoffice-core-5.0.5.2-6.fc23.x86_64 is broken+workarounded the same way.
Jan
On Fri, 2016-04-01 at 21:30 +0200, Jan Kratochvil wrote:
On Tue, 29 Mar 2016 19:22:31 +0200, Tim Landscheidt wrote:
Michael Catanzaro mcatanzaro@gnome.org wrote:
Then it was probably broken by this update:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253
The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as well (running Iceweasel on a remote Debian box from a local Fedora box). Does that mean that there is an error in Fe- dora, Firefox/Iceweasel, something else? Is there a bug tracking this?
libreoffice-core-5.0.5.2-6.fc23.x86_64 is broken+workarounded the same way.
Jan
I will just add: DRI3 plus the modesetting graphics driver (mandatory for new Intel processors) plus accelerated compositing is known-broken in WebKit; we unfortunately cannot support that combination. As we are going to make accelerated compositing mandatory in WebKit in the near future, my understanding is that will break all apps using WebKit for users with new computers. Only known solution is LIBGL_DRI3_DISABLE=1. This is your obligatory "I told you so" for when the complaints start rolling in half a year from now.
This is https://bugs.freedesktop.org/show_bug.cgi?id=85064
I'm concerned that we may have enabled DRI3 before it was fully-baked, if it's known to be broken with Firefox, WebKit, LibreOffice....
Michael
On Sat, Apr 2, 2016 at 3:43 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Fri, 2016-04-01 at 21:30 +0200, Jan Kratochvil wrote:
On Tue, 29 Mar 2016 19:22:31 +0200, Tim Landscheidt wrote:
Michael Catanzaro mcatanzaro@gnome.org wrote:
Then it was probably broken by this update:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253
The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as well (running Iceweasel on a remote Debian box from a local Fedora box). Does that mean that there is an error in Fe- dora, Firefox/Iceweasel, something else? Is there a bug tracking this?
libreoffice-core-5.0.5.2-6.fc23.x86_64 is broken+workarounded the same way.
Jan
I will just add: DRI3 plus the modesetting graphics driver (mandatory for new Intel processors)
This is not true. While the plan is to get stop using device specific ddx drivers you do not need modesetting for "new intel processors" they works with the intel ddx as well.
plus accelerated compositing is known-broken in WebKit; we unfortunately cannot support that combination.
Why?
As we are going to make accelerated compositing mandatory in WebKit in the near future, my understanding is that will break all apps using WebKit for users with new computers. Only known solution is LIBGL_DRI3_DISABLE=1. This is your obligatory "I told you so" for when the complaints start rolling in half a year from now.
This is https://bugs.freedesktop.org/show_bug.cgi?id=85064
I'm concerned that we may have enabled DRI3 before it was fully-baked, if it's known to be broken with Firefox, WebKit, LibreOffice....
Its not broken with Firefox or LibreOffice ... it can by design not work remotely. This issue has been fixed in xserver git by transparently fallback to DRI2 in that case -> https://bugs.freedesktop.org/show_bug.cgi?id=93261
Also XWayland only supports DRI3; and DRI3 on X is a requirement for Vulkan. It also helps compositors like mutter to avoid tearing and improves performance. So if there are issues with WebKit they should be fixed. "It can't work lets go back to DRI2" isn't really an option in the long run
On 04/02/2016 12:20 AM, drago01 wrote:
Its not broken with Firefox or LibreOffice ... it can by design not work remotely. This issue has been fixed in xserver git by transparently fallback to DRI2 in that case -> https://bugs.freedesktop.org/show_bug.cgi?id=93261
Also XWayland only supports DRI3; and DRI3 on X is a requirement for Vulkan. It also helps compositors like mutter to avoid tearing and improves performance. So if there are issues with WebKit they should be fixed. "It can't work lets go back to DRI2" isn't really an option in the long run
Does this mean that eventually X applications over ssh will stop working?
You say it's currently fixed by falling back to DRI2, but then you say that DRI2 is going away or at least won't be supported.
On Sat, Apr 2, 2016 at 9:26 AM, Samuel Sieb samuel@sieb.net wrote:
On 04/02/2016 12:20 AM, drago01 wrote:
Its not broken with Firefox or LibreOffice ... it can by design not work remotely. This issue has been fixed in xserver git by transparently fallback to DRI2 in that case -> https://bugs.freedesktop.org/show_bug.cgi?id=93261
Also XWayland only supports DRI3; and DRI3 on X is a requirement for Vulkan. It also helps compositors like mutter to avoid tearing and improves performance. So if there are issues with WebKit they should be fixed. "It can't work lets go back to DRI2" isn't really an option in the long run
Does this mean that eventually X applications over ssh will stop working?
You say it's currently fixed by falling back to DRI2, but then you say that DRI2 is going away or at least won't be supported.
DRI2 will stay around. It just wont be the default choice for the above reasons.
On Sat, 02 Apr 2016 09:39:33 +0200, drago01 wrote:
On Sat, Apr 2, 2016 at 9:26 AM, Samuel Sieb samuel@sieb.net wrote:
On 04/02/2016 12:20 AM, drago01 wrote:
Also XWayland only supports DRI3;
You say it's currently fixed by falling back to DRI2, but then you say that DRI2 is going away or at least won't be supported.
DRI2 will stay around. It just wont be the default choice for the above reasons.
But after Fedora switches to Wayland (XWayland?) then you say DRI2 won't be around anymore. So I do not understand how it will work afterwards.
So if there are issues with WebKit they should be fixed. "It can't work lets go back to DRI2" isn't really an option in the long run
Therefore not only WebKit but also Firefox and LibreOffice each need their own specific fixes?
Jan
On Sat, Apr 2, 2016 at 10:04 AM, Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Sat, 02 Apr 2016 09:39:33 +0200, drago01 wrote:
On Sat, Apr 2, 2016 at 9:26 AM, Samuel Sieb samuel@sieb.net wrote:
On 04/02/2016 12:20 AM, drago01 wrote:
Also XWayland only supports DRI3;
You say it's currently fixed by falling back to DRI2, but then you say that DRI2 is going away or at least won't be supported.
DRI2 will stay around. It just wont be the default choice for the above reasons.
But after Fedora switches to Wayland (XWayland?) then you say DRI2 won't be around anymore. So I do not understand how it will work afterwards.
You get software rendering.
So if there are issues with WebKit they should be fixed. "It can't work lets go back to DRI2" isn't really an option in the long run
Therefore not only WebKit but also Firefox and LibreOffice each need their own specific fixes?
LibreOffie and Firefox do not need any fixes.
On Sat, 2016-04-02 at 09:20 +0200, drago01 wrote:
This is not true. While the plan is to get stop using device specific ddx drivers you do not need modesetting for "new intel processors" they works with the intel ddx as well.
Great. Maybe that plan could be delayed until this issue is resolved, then?
plus accelerated compositing is known-broken in WebKit; we unfortunately cannot support that combination.
Why?
I don't know. It works with other graphics drivers.
Its not broken with Firefox or LibreOffice ... it can by design not work remotely. This issue has been fixed in xserver git by transparently fallback to DRI2 in that case -> https://bugs.freedesktop.org/show_bug.cgi?id= 93261
OK
Also XWayland only supports DRI3; and DRI3 on X is a requirement for Vulkan.
OK
It also helps compositors like mutter to avoid tearing and improves performance.
OK
So if there are issues with WebKit they should be fixed. "It can't work lets go back to DRI2" isn't really an option in the long run
It would be great if somebody would fix this. I just want to give a heads-up that we are not going to delay architectural improvements in WebKit for just DRI3 plus modesetting driver, and that this is going to render lots of apps totally unusable (gnome-initial-setup, gnome- online-accounts, Evolution, etc.) possibly in the F25/F26 timeframe if this isn't resolved.
Michael
On Sat, 2016-04-02 at 09:17 -0500, Michael Catanzaro wrote:
So if there are issues with WebKit they should be fixed. "It can't work lets go back to DRI2" isn't really an option in the long run
It would be great if somebody would fix this. I just want to give a heads-up that we are not going to delay architectural improvements in WebKit for just DRI3 plus modesetting driver, and that this is going to render lots of apps totally unusable (gnome-initial-setup, gnome- online-accounts, Evolution, etc.) possibly in the F25/F26 timeframe if this isn't resolved.
That seems to be a bit over-dramatic. gnome-initial-setup works fine. The online accounts step will be affected, but that's about it.
On Mon, 2016-04-04 at 14:19 -0400, Matthias Clasen wrote:
That seems to be a bit over-dramatic. gnome-initial-setup works fine. The online accounts step will be affected, but that's about it.
Yes, only the webview portions of g-i-s would be affected, of course (gnome-online-accounts page, and the EULA page). Users will still be able to install Fedora. Only the webviews would become borderline unusable.
And the breakage will be limited to only those using the modesetting driver, i.e. computers than are newer than the ones we're probably using right now.
Michael
On Mon, Apr 4, 2016 at 3:13 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Mon, 2016-04-04 at 14:19 -0400, Matthias Clasen wrote:
That seems to be a bit over-dramatic. gnome-initial-setup works fine. The online accounts step will be affected, but that's about it.
And the breakage will be limited to only those using the modesetting driver, i.e. computers than are newer than the ones we're probably using right now.
Intel i7-6700k checking in. Unless i misunderstood the thread, does Skylake not use -modesetting?
On Mon, 4 Apr 2016 15:33:51 -0400 Eric Griffith egriffith92@gmail.com wrote:
On Mon, Apr 4, 2016 at 3:13 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Mon, 2016-04-04 at 14:19 -0400, Matthias Clasen wrote:
That seems to be a bit over-dramatic. gnome-initial-setup works fine. The online accounts step will be affected, but that's about it.
And the breakage will be limited to only those using the modesetting driver, i.e. computers than are newer than the ones we're probably using right now.
Intel i7-6700k checking in. Unless i misunderstood the thread, does Skylake not use -modesetting?
It does.
Also, I haven't seen any of the breakage in webkit mentioned in this thread here with a skylake laptop.
kevin
On Mon, 2016-04-04 at 13:56 -0600, Kevin Fenzi wrote:
It does.
Also, I haven't seen any of the breakage in webkit mentioned in this thread here with a skylake laptop.
The bug only occurs in accelerated compositing (OpenGL) mode, which is currently only used when necessary to support a particular web page (e.g. GitHub commit diffs, or search results on DuckDuckGo). Ongoing work is to make accelerated compositing mode mandatory and use it on all web pages. Once this work lands, modesetting driver users will need to disable DRI3 in order to practically use WebKit.
Michael
On Mon, 04 Apr 2016 15:23:56 -0500 Michael Catanzaro mcatanzaro@gnome.org wrote:
On Mon, 2016-04-04 at 13:56 -0600, Kevin Fenzi wrote:
It does.
Also, I haven't seen any of the breakage in webkit mentioned in this thread here with a skylake laptop.
The bug only occurs in accelerated compositing (OpenGL) mode, which is currently only used when necessary to support a particular web page (e.g. GitHub commit diffs, or search results on DuckDuckGo). Ongoing work is to make accelerated compositing mode mandatory and use it on all web pages. Once this work lands, modesetting driver users will need to disable DRI3 in order to practically use WebKit.
ok, that makes more sense. Thanks.
kevin
On Mon, 2016-04-04 at 15:23 -0500, Michael Catanzaro wrote:
On Mon, 2016-04-04 at 13:56 -0600, Kevin Fenzi wrote:
It does.
Also, I haven't seen any of the breakage in webkit mentioned in this thread here with a skylake laptop.
The bug only occurs in accelerated compositing (OpenGL) mode, which is currently only used when necessary to support a particular web page (e.g. GitHub commit diffs, or search results on DuckDuckGo). Ongoing work is to make accelerated compositing mode mandatory and use it on all web pages. Once this work lands, modesetting driver users will need to disable DRI3 in order to practically use WebKit.
Once again goes to show how problematic it is to use web rendering stacks from browsers in other places: Now we have an initial setup tool that depends on GL+DRI3 working just because it needs to render two entries in a webpage :-(
On Mon, Apr 4, 2016 at 9:33 PM, Eric Griffith egriffith92@gmail.com wrote:
On Mon, Apr 4, 2016 at 3:13 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Mon, 2016-04-04 at 14:19 -0400, Matthias Clasen wrote:
That seems to be a bit over-dramatic. gnome-initial-setup works fine. The online accounts step will be affected, but that's about it.
And the breakage will be limited to only those using the modesetting driver, i.e. computers than are newer than the ones we're probably using right now.
Intel i7-6700k checking in. Unless i misunderstood the thread, does Skylake not use -modesetting?
It does on F24 / rawhide ... it still uses the intel ddx on F23.
On Sat, 2 Apr 2016 09:20:00 +0200 drago01 drago01@gmail.com wrote:
This is not true. While the plan is to get stop using device specific ddx drivers you do not need modesetting for "new intel processors" they works with the intel ddx as well.
My understanding is that gen9 intel chipsets get modesetting, gen8 and earlier still use xorg-x11-drv-intel. (For f24+)
http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-drv-intel.git/commit/?h=f24...
...snip...
Also XWayland only supports DRI3; and DRI3 on X is a requirement for Vulkan. It also helps compositors like mutter to avoid tearing and improves performance. So if there are issues with WebKit they should be fixed. "It can't work lets go back to DRI2" isn't really an option in the long run --
Oddly, I have a skylake laptop here (gen 9) and it does indeed use modesetting driver, but I only get DRI2 (which is why I haven't seen any DRI3 problems I guess).
Apr 02 13:50:17 sheelba.scrye.com org.gnome.Shell.desktop[2064]: glamor: EGL version 1.4 (DRI2):
Is DRI3 only default for xorg-x11-drv-intel ?
kevin
On Sat, Apr 2, 2016 at 10:00 PM, Kevin Fenzi kevin@scrye.com wrote:
On Sat, 2 Apr 2016 09:20:00 +0200 drago01 drago01@gmail.com wrote:
This is not true. While the plan is to get stop using device specific ddx drivers you do not need modesetting for "new intel processors" they works with the intel ddx as well.
My understanding is that gen9 intel chipsets get modesetting, gen8 and earlier still use xorg-x11-drv-intel. (For f24+)
http://pkgs.fedoraproject.org/cgit/rpms/xorg-x11-drv-intel.git/commit/?h=f24...
That's a fedora specific patch I haven't seen yet. But given that's what we want to move to its ok anyways.
Also XWayland only supports DRI3; and DRI3 on X is a requirement for Vulkan. It also helps compositors like mutter to avoid tearing and improves performance. So if there are issues with WebKit they should be fixed. "It can't work lets go back to DRI2" isn't really an option in the long run --
Oddly, I have a skylake laptop here (gen 9) and it does indeed use modesetting driver, but I only get DRI2 (which is why I haven't seen any DRI3 problems I guess).
Apr 02 13:50:17 sheelba.scrye.com org.gnome.Shell.desktop[2064]: glamor: EGL version 1.4 (DRI2):
Is DRI3 only default for xorg-x11-drv-intel ?
No. This line does not tell you much.
Easy way to check for DRi3 is to run "glxinfo|grep buffer_age" ... if you have to lines in that output you'd have DRI3.
As for why you haven't seen problems ... because usually it "just works" (even better than DRI2).
On Sat, 2 Apr 2016 23:14:14 +0200 drago01 drago01@gmail.com wrote:
No. This line does not tell you much.
Easy way to check for DRi3 is to run "glxinfo|grep buffer_age" ... if you have to lines in that output you'd have DRI3.
Intuitive. :)
% glxinfo|grep buffer_age GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age,
As for why you haven't seen problems ... because usually it "just works" (even better than DRI2).
Alright.
kevin
On Sat, Apr 2, 2016 at 11:28 PM, Kevin Fenzi kevin@scrye.com wrote:
On Sat, 2 Apr 2016 23:14:14 +0200 drago01 drago01@gmail.com wrote:
No. This line does not tell you much.
Easy way to check for DRi3 is to run "glxinfo|grep buffer_age" ... if you have to lines in that output you'd have DRI3.
Intuitive. :)
Well that's the easiest thing I could think of that doesn't require jumping through hoops ... you could use dri3info, which isn't packaged.
But you can do: wget https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/tools/dri3inf... gcc -o dri3info dri3info.c `pkg-config --cflags --libs xcb-dri3 x11-xcb xrandr xxf86vm libdrm` ./dri3info
On 04/03/2016 04:11 AM, drago01 wrote:
On Sat, Apr 2, 2016 at 11:28 PM, Kevin Fenzi kevin@scrye.com wrote:
On Sat, 2 Apr 2016 23:14:14 +0200 drago01 drago01@gmail.com wrote:
No. This line does not tell you much.
Easy way to check for DRi3 is to run "glxinfo|grep buffer_age" ... if you have to lines in that output you'd have DRI3.
Intuitive. :)
Well that's the easiest thing I could think of that doesn't require jumping through hoops ... you could use dri3info, which isn't packaged.
But you can do: wget https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/tools/dri3inf... gcc -o dri3info dri3info.c `pkg-config --cflags --libs xcb-dri3 x11-xcb xrandr xxf86vm libdrm` ./dri3info
Should be:
wget https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/plain/tools/dri3in...
I'll note:
# glxinfo|grep buffer_age GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile,
# ./dri3info Display ':0' Unable to connect to DRI3 Primary refresh rate: 865625/14443 (59.9Hz)
On Fri, 2016-04-01 at 20:43 -0500, Michael Catanzaro wrote:
I will just add: DRI3 plus the modesetting graphics driver (mandatory for new Intel processors) plus accelerated compositing is known- broken in WebKit; we unfortunately cannot support that combination. As we are going to make accelerated compositing mandatory in WebKit in the near future, my understanding is that will break all apps using WebKit for users with new computers. Only known solution is LIBGL_DRI3_DISABLE=1. This is your obligatory "I told you so" for when the complaints start rolling in half a year from now.
This is https://bugs.freedesktop.org/show_bug.cgi?id=85064
I'm concerned that we may have enabled DRI3 before it was fully- baked, if it's known to be broken with Firefox, WebKit, LibreOffice....
Michael
Hi,
This is a heads-up that the change to enable accelerated compositing always has landed in WebKit trunk and will be landing in rawhide soon.
As previously discussed, the DRI3 plus modesetting driver combination is known to be broken in accelerated compositing mode as per [1]. WebKitWebViews will most likely not be functional in F25 for affected users. Any help in fixing [1] would of course be appreciated. The relevant upstream WebKit developers are not very interested in this problem because Debian doesn't use DRI3.
Michael
On 29.03.2016 19:22, Tim Landscheidt wrote:
Michael Catanzaro mcatanzaro@gnome.org wrote:
Yes. This makes it work. Thanks a lot.
Then it was probably broken by this update:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253
The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as well (running Iceweasel on a remote Debian box from a local Fedora box). Does that mean that there is an error in Fe- dora, Firefox/Iceweasel, something else? Is there a bug tracking this?
looks like
devel@lists.stg.fedoraproject.org
-
drago01 -
Eric Griffith -
Jan Kratochvil -
Juan Quintela -
Kevin Fenzi -
Matthias Clasen -
Michael Catanzaro -
Michael Stahl -
Orion Poplawski -
Richard W.M. Jones -
Samuel Sieb -
Tim Landscheidt