Mutter & GNOME Shell 3.19.3 Bring More Fixes

[phoronix]

Phoronix: Mutter & GNOME Shell 3.19.3 Bring More Fixes

With GNOME 3.19.3 due for release this week, Florian Müllner has announced new versions of GNOME Shell and Mutter...

http://www.phoronix.com/scan.php?pag...-Mutter-3.19.1

[Anvil]

wonder how many bugs they have actually fixed an Created? have they fixed the gnome-terminal bug ? it wouldnt startup in a Wayland session

[ElectricPrism]

wonder how many bugs they have actually fixed an Created? have they fixed the gnome-terminal bug ? it wouldnt startup in a Wayland session

It wouldn't launch on some X installations aswell, not sure if related - I had to launch via xterm and google the crash message which helped. Gnome is the hero Linux needs.

[Anvil]

It wouldn't launch on some X installations aswell, not sure if related - I had to launch via xterm and google the crash message which helped. Gnome is the hero Linux needs.

iii'll have to try a Fedora Nightly when one builds

[Candy]

Have they fixed this issue by now ?
Bug has been reported in May 2015 (Fedora 22) and still no feedback from the maintainers.

[Modu]

I hope one day they will fix that damn mouse pointer freezes when you click show applications or slowdowns over app icons on wayland and gstreamer-vaapi support of totem.

[lkundrak]

Have they fixed this issue by now ?
Bug has been reported in May 2015 (Fedora 22) and still no feedback from the maintainers.

I don't think this is a bug nor that your understanding of the is correct. It might be that the UI is confusing a bit.

NetworkManager does not provide a mechanism to turn off a Wi-Fi device. The radio disable always disables all radios of a kind. That's on purpose -- the feature is intended for cases when you're not allowed to use radios (certain medical facilities, airplanes) and then it doesn't make sense to disable the radios selectively.

When you disconnect a Wi-Fi device then NetworkManager wouldn't reactivate another network on that device. That is probably what you're seeing with the nm-applet. Note that the device is still not disables and still uses the radio (e.g. scans the range for access points).

For your use case (which probably is a workaround for a questionable hardware setup) the best solution would be to write an udev rule that would turn on/off (with ip link or rfkill or whatever) the PCI device when you plug or unplug the USB one. Also, unloading the module for the Wi-Fi adapter you have but don't want to use is probably a better solution than hacking this into the UI. Also, blocking it in modules.conf of making NetworkManager ignore it by setting NM_UNMANAGED=yes with udev or modifying unmanaged-devices in NetworkManager.conf may make sense.

[Candy]

I don't think this is a bug nor that your understanding of the is correct.

I think your's isn't correct either.

With Fedora 20 and the Gnome 3.x that came shipped with it, it was absolutely possible to turn off individual WLAN devices within Gnome-Shell.

Example:

1) External Atheros WLAN USB device
2) Internal RTL18xx WLAN device

Within Gnome-Shell of Fedora 20 I was able to turn them on and off individually. Even within the Gnome 3.x that came with Fedora 22 you have the capabilities to turn individual WLAN devices on and off (at least each device provides its own ON/OFF slider). Sadly pulling one of those turns all WLAN devices ON or OFF. So the behaviour between the Gnome-Shell that cames bundled with Gnome 3.x on Fedora 20 vs. the Gnome-Shell that comes bundles with Gnome 3.x on Fedora 22 has changed.

From a users point of view this new behavior is an error and needs to be addressed and fixed. And no! Suggesting people to blackmask (as I temporarely have done in /etc/modules) is not the proper solution. I need both devices to cover up each other in case one dies. I want to turn it on within Gnome-Shell as I was able to within Fedora 20.

And No! The networkmanager-applet is capable in turning off and on individual devices. By turning on and off I mean the capabilities to turn off the device by not unloading it's modules. I mean it in terms of disabling it for the time beeing and enabling it on demand once necessary again.

Edit: There is of course also a global on off slider within Gnome-Shell to enable and or disable WLAN entirely in case of Airplane mode. But that is not the issue that I was referring to.

[Krejzi]

Have they fixed this issue by now ?
Bug has been reported in May 2015 (Fedora 22) and still no feedback from the maintainers.

That's a NetworkManager issue, and a Linux Kernel limitation. Last time I heard from NetworkManager maintainer, he said that there was no way to tell kernel which interface to disable, only to disable everything through rfkill (or enable everything).

[Candy]

That's a NetworkManager issue, and a Linux Kernel limitation. Last time I heard from NetworkManager maintainer, he said that there was no way to tell kernel which interface to disable, only to disable everything through rfkill (or enable everything).

Interesting! But if that's the case, then why does it work through NetworkManager Applet (as I use it under XFCE 4.x right now) and why did it work under Fedora 20 using Gnome-Shell ? Or said differently. As far as I know, Gnome-Shell under Fedora 20 still used the NetworkManager backend, while with the Gnome-Shell that came with Fedora 22, Gnome-Shell provided its own NetworkManager rewrite thingy ? So where is the real *bug* now ? I ask this because as you see within the bugreport above, the NetworkManager maintainer (for the package) retargeted the bug from NetworkManager (my initial thought) to Gnome-Shell (because they provide their own Networkfunctionality). Anyhow! Someone might have known and already respond correctly to the bugreport.