Question: Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:

''; executable = writeScript "pantheon" '' <del> export XDG_CONFIG_DIRS=${elementary-settings-daemon}/etc/xdg:${elementary-default-settings}/etc:$XDG_CONFIG_DIRS </del> <ins> # gnome-session can find RequiredComponents for `pantheon` session (notably pantheon's patched g-s-d autostarts) export XDG_CONFIG_DIRS=@out@/etc/xdg:$XDG_CONFIG_DIRS # Make sure we use our gtk-3.0/settings.ini export XDG_CONFIG_DIRS=${elementary-default-settings}/etc:$XDG_CONFIG_DIRS # * gnome-session can find the `pantheon' session # * use pantheon-mimeapps.list </ins> export XDG_DATA_DIRS=@out@/share:$XDG_DATA_DIRS <del> exec ${gnome-session}/bin/gnome-session --session=pantheon "$@" </del> <ins> # Start pantheon session. Keep in sync with upstream exec ${gnome-session}/bin/gnome-session --builtin --session=pantheon "$@" ''; # Absolute path patched version of the upstream xsession xsession = writeText "pantheon.desktop" '' [Desktop Entry] Name=Pantheon Comment=This session provides elementary experience Exec=@out@/libexec/pantheon TryExec=${wingpanel}/bin/wingpanel Icon= DesktopNames=Pantheon Type=Application </ins> ''; in stdenv.mkDerivation rec { pname = "elementary-session-settings-unstable"; <del> version = "2020-06-11"; </del> <ins> version = "2020-07-06"; </ins> repoName = "session-settings"; src = fetchFromGitHub { owner = "elementary"; repo = repoName; <del> rev = "130c9ae221913032ed18bcf6d21e3dcdba3c4209"; sha256 = "0bzg9vbq0ssnxgcb2vxpx6x9zv8ngkm9r3ki5q83m9al9919n0pr"; </del> <ins> rev = "fa15cbd83fba0ba30e9a302db880350bff5ace52"; hash = "sha256-26H791c7OAjFYtjVChIatICSocMt0uTej1TKBOvw+6w="; </ins> }; nativeBuildInputs = [


Question: Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:

]; postInstall = '' <ins> # our mimeapps patched from upstream to exclude: # * pantheon-mail -> geary # * evince.desktop -> org.gnome.Evince.desktop </ins> mkdir -p $out/share/applications cp -av ${./pantheon-mimeapps.list} $out/share/applications/pantheon-mimeapps.list <ins> # instantiates pantheon's dockitems </ins> cp "${dockitemAutostart}" $out/etc/xdg/autostart/default-elementary-dockitems.desktop <ins> # script `Exec` to start pantheon </ins> mkdir -p $out/libexec substitute ${executable} $out/libexec/pantheon --subst-var out chmod +x $out/libexec/pantheon <del> ''; postFixup = '' substituteInPlace $out/share/xsessions/pantheon.desktop  --replace "gnome-session --session=pantheon" "$out/libexec/pantheon"  --replace "wingpanel" "${wingpanel}/bin/wingpanel" </del> <ins> # absolute path patched xsession substitute ${xsession} $out/share/xsessions/pantheon.desktop --subst-var out </ins> ''; passthru = {


Question: Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:

, json-glib , elementary-dock , bamf <del> , switchboard </del> <ins> , switchboard-with-plugs </ins> , libunity , libsoup , wingpanel


Question: Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:

pkgconfig python3 vala <del> ]; </del> <ins> ]; </ins> buildInputs = [ bamf


Question: Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:

libhandy libsoup libunity <del> switchboard </del> <ins> switchboard-with-plugs </ins> wingpanel zeitgeist <del> ]; </del> <ins> ] ++ # applications-menu has a plugin to search switchboard plugins # see https://github.com/NixOS/nixpkgs/issues/100209 # wingpanel's wrapper will need to pick up the fact that # applications-menu needs a version of switchboard with all # its plugins for search. switchboard-with-plugs.buildInputs; </ins> mesonFlags = [ "--sysconfdir=${placeholder "out"}/etc"


Question: Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:

''; postFixup = '' <del> for autostart in $(grep -rl "OnlyShowIn=GNOME;" $out/etc/xdg/autostart) do echo "Patching OnlyShowIn to Pantheon in: $autostart" sed -i "s,OnlyShowIn=GNOME;,OnlyShowIn=Pantheon;," $autostart done # This breaks lightlocker https://github.com/elementary/session-settings/commit/b0e7a2867608c3a3916f9e4e21a68264a20e44f8 # TODO: shouldn't be neeed for the 5.1 greeter (awaiting release) rm $out/etc/xdg/autostart/org.gnome.SettingsDaemon.ScreensaverProxy.desktop </del> # So the polkit policy can reference /run/current-system/sw/bin/elementary-settings-daemon/gsd-backlight-helper mkdir -p $out/bin/elementary-settings-daemon ln -s $out/libexec/gsd-backlight-helper $out/bin/elementary-settings-daemon/gsd-backlight-helper


Question: Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


Question: Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


Question: Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


Question: Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


Question: Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


Question: Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


Question: Describe the bug Installing the latest SBT is not possible. To Reproduce Expected behavior Install is successful Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata

echo -java-home ${jre.home} >>conf/sbtopts ''; <del> nativeBuildInputs = [ autoPatchelfHook ]; </del> <ins> nativeBuildInputs = stdenv.lib.optionals stdenv.isLinux [ autoPatchelfHook ]; </ins> <del> buildInputs = [ zlib ]; </del> <ins> buildInputs = stdenv.lib.optionals stdenv.isLinux [ zlib ]; </ins> installPhase = '' mkdir -p $out/share/sbt $out/bin


Question:
Describe the bug I'm trying to get Steam big picture to work with , xbox wireless adapter and a couple of xbox controllers. But if Steam is already running and I turn on my controllers, they successfully connect to the dongle, but steam doesn't detect them. If i first turn on the controllers, and then i start Steam, it recognizes them and they work fine. xow: I couldn't use the service file provided by the package because it would never start. I read somewhere that systemd is picky with symlinks, so i defined it myself, now it's starting fine. I also had to blacklist else xow would crash. Steam: To Reproduce Steps to reproduce the behavior: sure xow is running fine Steam on steam controllers to see if they work (they dont) Additional context I think xow is working fine. I tried the latest version (0.5) and the last commit, importing udev rules from the package and adding them to I also tried adding my user to the group. It doesn't matter if steam is running in big picture or not, i also tried steam native, still not working. Metadata Edit: Steam won't detect controllers even when using the wire. And also i tested the controllers with and and they work as expected. So i'm pretty sure the issue must be with steam.
This might be an upstream problem with , have you tried using it on a non NixOS system? I also maintain (a kernel driver for Xbox controllers) and I don't have this problem with Steam. Maybe try to test if there's still a problem on your system with xpadneo?
You might also want to try enabling xow using the NixOS module instead of writing a custom service:
Yes, i have another system with Arch and it's working fine there. Steam detects controller connections even when it's already running. That's what i tried at first, but xow wouldn't start, the service was hanging in an state. And I think it might be because when importing the service from the package, nix is creating a symlink to the service and it might cause some issues. Also I did some more tests with xow and controllers are working fine, , , this website https://gamepad- everywhere it works as expected, even Stardew Valley is able to detect them, but not Steam (well unless i restart it with controllers connected, then they are detected and working). It's really weird, I am able to pair them, xpadneo detects them, but they are totally unresponsive, everywhere. I uninstalled xow, and removed the wireless dongle when i tested this. Since xow it's working fine in browser with https://gamepad- and with some games, then udev rules should be fine , right? I would say it's an upstream issue with Steam, but it's working fine on Arch, so there might be some issues with some libs?
The xow NixOS module is fixed now. The problem was that NixOS specifically bypasses the Install section of service files and the module wasn't setting WantedBy for the service explicitly.
I am wih something similar here, I am using the gamepad via USB , before the config all software detected the control, and I was able to play without problems except for steam, which prevented me from using the big picture, after enabling this option I have the same behavior as steam for all applications, if I plug in the control it does not work until the next reboot. Any suggestions on where to debug to understand why this behavior? Dmesg and lsusb look ok.
Having a similar issue, since I'm not using xow or anything but kernel drivers: Steam isn't able to detect a hotplugged Xbox one wired controller. It works perfectly fine if I plug it in before starting Steam. I can also confirm this behavior works on Arch.
that's my situation too
I guess no news on this? :(
i'll take a look, probably something to do with udev rules. i dont have a xbox controller though, only a steam controller
This problem sufficiently annoys me at this point that if there are any instructions I can follow to provide information I'm happy to do so. Thanks for offering to look. I am currently in possession of 2 xbox controllers, several controllers that show up as xbox controllers, and some controllers that don't show up as xbox controllers. I have this issue with all these controllers to the best of my recollection.
the steam udev rules are almost the same as on other distros, though arch does i'll try borrowing a xbox controller. does this happen with only the xbox one or does it happen with 360 too
sadly i can't find a xbox one controller. the udev rules provided by the steam package are the same as on other distros, maybe it has something to do with our other udev rules. may also have something to do with bubblewrap
It seems to be related to linux usernamespaces which to my understanding remaps the id of the sender of udev events (from 0 to a big number) leading udev to ignore these messages if it's not zero. Running directly on my system and under (running as root and as a normal user) led me to believe this (). This issue may need to be fixed with bubblewrap, I don't think something can be done here. Unfortunately I don't have a solution :sweatsmile: PS : I don't know if fixing this issue will make everything work, .
these look related
I merged someone who has this issue please look into using the patched systemd with the steam fhsenv
I've just tested on latest NixOS unstable. A hotplugged Xbox One controller was successfully detected by Steam Big Picture. Thank you!
i haven't done anything that would have fixed this
Well that is exceptionally weird! Because it's definitely working for me, looks like an unrelated PR fixed it? This is straight out of my terminal, after starting Steam with no controller, disconnecting and connecting again:
This must be a change to how steam recognizes controllers. The program from still does not show events when started within There is still something odd: My joystick Logitech X52 HOTAS is recognized as a gamepad, while when I run steam packages on flatpak, it works properly. I don't know what they do differently in the flatpak version to get it working. Maybe using libgudev or a flatpak specific version of udev in the runtime packages? I have tested adding patched systemd to the fhs of steam, but this did not change anything (maybe some other udev library version was shadowing it)
I marked this as stale due to inactivity. →
I still have this issue, with both an xbox 360 controller with the wireless adapter as well with an 8Bitdo SN30+ in both wired and wireless mode. Starting steam with any of these already connected works, but if one gets connected after starting steam (or worse - shortly disconnects while playing) it will not be reconnected until a Steam restart. However, with a Steam Controller hotplugging works just fine! This happens with Steam Big Picture mode (and also in games, but I guess Big Picture mode is more readily reproducable). I assume I am doing something wrong as others have it fixed, is this really no longer an issue for others? Happy for any pointers and to assist in debugging. (my config is at in case it is needed, i am currently on )
I assume I am doing something wrong as others have it fixed, is this really no longer an issue for others? I have the same issue, with PS5 DualSense controllers. I debugged a bit during the christmas holiday, based on some info in either this issue or some other... By applying a patch (linked from the issue) I was able to see udev starting to detect hotplugging the controller in the Steam FHS env (it didn't detect these events by default), but still Steam wouldn't pick up the hotplugged controller.
I found my experimental config snippet from back then: AFAIR, I was worried that steam itself didn't use the patched libudev, but I'm pretty sure I looked up the process map and found it had (only) loaded the patched libudev, so I'm not sure what's going on. Didn't look at it since.
If anyone just wants to throw money at this problem I highly suggest the to solve it. The real win with this gamepad is that it always shows up as connected to your PC, even when it is powered off. It achieves this by coming with a usb dongle that shows up effectively as a wired joystick regardless if the gamepad is being used or not. Perfect solution for this problem... I have 3. I'll mention a potential con, though: Make sure you have good line of sight between the usb dongle and the gamepad (don't worry, it comes with a ~1m usb extension cable to allow good line of sight) and aren't too far away (3-4 m I would guess) or else the signal is really spotty. In my last setup I used this through the wall and it absolutely wouldn't work for any serious gaming, but now I have the pc in the same room as the gamepads with direct line of sight and it is perfect. But yeah... a real solution would be better and still appreciated by me. Just thought I'd post this in case anyone could benefit from it. :man_shrugging:
Another alternative is to use : in the config: then install and run it: I didn't have any issues since doing it since flatpak was updated to = 1.12
I still have this issue on Nix's version of steam using nixos-unstable. Enabling xpadneo did not fix it either.
may have fixed this
Seems like didn't fix it. I see that it is in nixos-unstable and it seems like Steam still displays the same issue with my DualSense controller. I need to restart Steam before it detects it
I am having this issue on every controller I have: Steam Controller Nintendo Switch Pro Controller PS3 Controller Gulikit King Kong Pro 2 Controller in all 4 modes (Switch, XInput, DInput, Android/iOS) USB adapters for NES, SNES, and Gamecube controllers It occurs when using both Bluetooth and USB, so I am 90% certain it has nothing to do with which controller you are using. The behavior is the same for all of them; when I connect any USB/Bluetooth controller it is not recognized or noticed by Steam if it is already running, but only when Steam is starting up while the controller is currently plugged in. Here's some information on what happens when I use the Gulikit controller (XInput mode via bluetooth): Controller connected and Steam is not started At this point, and are now created Now I start Steam And reports: And now and are created (???) Disconnected the controller with Steam running Nothing new in I reconnect the controller with Steam running* And and is back TL;DR - So it looks like Steam will normally start up and find the controller and then it will create the virtual input devices and . However, it won't create these devices when they are connected after Steam is already running. The question I have is why this happens and what can be done to fix it. It looks to be a NixOS specific issue as the problem doesn't appear to be on other Linux distributions like Arch (just reading off of what's in this thread, I haven't tried myself). If anyone wants me to try anything and test it on a fair variety of USB/Bluetooth controllers please let me know. I think something might be wrong with how the FHS wrapper () seems to be binding the devices that prevents new devices from being seen. EDIT: I just confirmed the and device files are appearing and disappearing in the environment that Steam runs in, so the FHS is actually properly creating those devices. The only difference I can see is that they are owned by in the FHS environment (versus in the normal environment). I can still properly access both. I did see : However, that would imply this is not NixOS specific and instead is default Steam behavior. No indication of how to change that default behavior though, so I can't find a way to confirm it.
This seems related:
Just as an datapoint: The Steam Controller is actually one that does not exhibit this issue for me, at least not when wirelessly connected with the Dongle that came with it. If I connect it via cable then it is the same as usual, only recognized when restarting steam. Also if connected via dongle and I replug the dongle, the controller only gets recognized when restarting steam. But if the dongle stays put and I shutdown the controller (by holding the Steam button for a few seconds) and start it again it works just fine with steam running. I guess it might be similar to the controller described in
I was surprised as well, and a little bit of digging reveals that SDL2 being inside flatpak and disables the unreliable udev-based discovery. And disabling it manually ! I opened to fix this.
Can confirm that it fixed the issue for me. Good job in discovering this
This is resolved for me now as well. Thank you all! :heart:

export TZ="$new_TZ" fi fi <ins> # udev event notifications don't work reliably inside containers. # SDL2 already tries to automatically detect flatpak and pressure-vessel # and falls back to inotify-based discovery [1]. We make SDL2 do the # same by telling it explicitly. # # [1] <https://github.com/libsdl-org/SDL/commit/8e2746cfb6e1f1a1da5088241a1440fd2535e321> export SDL_JOYSTICK_DISABLE_UDEV=1 </ins> '' + extraProfile; runScript = writeScript "steam-wrapper.sh" ''


Question:
In a NixOS 20.09 guest on a VMWare Windows host, with dwm as my window manager, the mouse cursor neither moves nor registers clicks when . To Reproduce Steps to reproduce the behavior: NixOS 20.09 in VMWare Workstation Player 16 VM (from the minimal ISO) xserver and dwm and in as normal user with a minimal can you have a look?
I can reproduce this. It does work if you login as but fails if you log into a normal user account. It also fails in .
Oh boy, even in the grown-up DM. That's bad.
Did this fix the issue for you? ? I'm having issues my self. I also posted in reddit to see if maybe I didn't do something correctly.
try the PR I just linked. My mouse problems went away when I compiled the kernel with CONFIGPS2VMMOUSE.
Thank you it works! This will be great to have. This might be a silly question, but is open-vm-tools 11.3.0 required for this to work? I didn't have time to try 11.2.5 on the stable channel. For anyone reading this the name value is MOUSEPS2VMMOUSE, might save you one failed kernel build before you figure it out. Here's my nix config that I used to allow non-root user to use the mouse in Xorg running on vmware fushion on MacOS - This config was a "get it to work" attempt with no regard to what the ramifications of how I went about it. My next step is to figure out what it all really means and see if I went about it correctly.

MODVERSIONS        = whenOlder "4.9" yes; MOUSE_ELAN_I2C_SMBUS = yes; MOUSE_PS2_ELANTECH = yes; # Elantech PS/2 protocol extension <ins> MOUSE_PS2_VMMOUSE  = yes; </ins> MTRR_SANITIZER     = yes; NET_FC             = yes; # Fibre Channel driver support # GPIO on Intel Bay Trail, for some Chromebook internal eMMC disks


Question:
Describe the bug from should have fledgling Ozone/wayland support. Users on other distros are having success. However, I am not. Looks like it might be a Nix-y thing: and no window opens.
I had it working once: (didn't re-test lately tho) It might also be a hardware/driver thing (changing might also help if it's related to any local state). Do you get any additional output (I usually get way more output)? Or it might be due to one of the many upstream bugs (). But if this is indeed related to Nix investigating/fixing it would be very nice.
too, saw it working once. , local state does affect it. I was having a totally different crash until I deleted . used to get more output, but no, that's everything, verbatim what I get from launching yesterday. It very well could just be upstream, but I'm getting jealous of adhoc reports of those builds working on other distros. Unfortunately I don't have a lot of time/ideas.
Ok, strange. I just tried this again with 87.0.4280.66 and got the following output (in my case this looks as with previous versions that crashed though). <details<summaryConsole output (the 2nd time no browser window appeared anymore)</summary<pre[nix-shell:~/google-chrome]$ which google-chrome-stable /nix/store/j3v003nw7mkhdzys4wih1zvw2lsvm8cq-google-chrome-87.0.4280.66/bin/google-chrome-stable [nix-shell:~/google-chrome]$ google-chrome-stable --enable-features=UseOzonePlatform --ozone-platform=wayland [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGL failed with error EGLNOTINITIALIZED, trying next display type [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGLES failed with error EGLNOTINITIALIZED [(20)] GLSurfaceEGL::InitializeOneOff failed. [(150)] Exiting GPU process due to errors during initialization [(621)] Failed to call method: org.freedesktop.DBus.Properties.Get: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(374)] InitializeSandbox() called with multiple threads in process gpu-process. [nix-shell:~/google-chrome]$ google-chrome-stable --enable-features=UseOzonePlatform --ozone-platform=wayland [(621)] Failed to call method: org.freedesktop.DBus.Properties.Get: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGL failed with error EGLNOTINITIALIZED, trying next display type [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGLES failed with error EGLNOTINITIALIZED [(20)] GLSurfaceEGL::InitializeOneOff failed. [(150)] Exiting GPU process due to errors during initialization [(374)] InitializeSandbox() called with multiple threads in process gpu-process. [(122)] ContextResult::kTransientFailure: Failed to send GpuChannelMsgCreateCommandBuffer. </pre</detailsYou're right, I just tried the exact same version but with instead of and it works pretty flawlessly (videos don't play but the rest seems fine). So this issue only seems to affect Google Chrome. Also: With Chromium I don't get any of those error messages on the console that I get with Google Chrome (only the usual ones as in your initial post, not the ones related to ANGLE/EGL/X11).
Since we will lose some Google account related stuff in chromium quite soon[1], I am looking into using Chrome for some stuff. At the moment I am using Chromium via and it is wonderfully fast and smooth (sway, nixos-unstable, intel-gpu), even though I have to disable something about video acceleration[2]. None of the three Chrome builds start with as reported in this Github issue. When also adding it runs (as a Wayland window), but the performance is bad. [1] ,-By%20Joey%20Sneddon&text=Users%20of%20the%20Chromium%20web,builds%20from%20March%2015%2C%. [2]
could you also report your Wayland compositor and GPU? Maybe that's related. I did test this on Sway and Weston (IIRC) with an old AMD Radeon HD 6950 GPU (Mesa's Radeon R600 Gallium3D Driver). I've also started following a few upstream issues that could be related: (seems Nvidia specific though) (reproducible on wlroots-based compositors) I'm still not sure if this is an upstream issue, GPU driver or Wayland compositor related issue, or Nixpkgs specific (either due to our Chromium packaging, due to some specific system dependencies, or due to issues with our Nix store paths). if you want you could also try to investigate this with e.g. (IIRC I briefly had a look but it's not a priority for me since I don't use Google Chrome).
I am on sway/wlroots/intel-gpu. I'll look into strace, but I fear my Linux debugging skills are a bit rusty.
I am not able interpret the output in any meaningful way, but I was able to get some more log output: conincides with
Wayland works on latest unstable chrome, but rendering falls back to software. Log Messages
It stopped showing window once I close and re-run chrome, but after removing it starts working again.
Current output, just for the record (GPU driver: , flags: ). Current output of (only works via ): Note: This obviously shouldn't try to open the X display. Current output of (doesn't work at all):
I have it working on stable 91.0.4472.114 with just the ozone platform flags, but there's no hardware acceleration at all.
that might be equivalent to the case then (which also works reliably but without hardware acceleration). For M92+ the situation is currently even worse as the GPU acceleration seems to be broken. I need to use to even launch Chromium or Google Chrome (unfortunately I lack time for a proper investigation but at least there are already some upstream bug reports).
With Google Chrome M92+ the Ozone/Wayland support seems to be completely broken on NixOS (coredump during startup): Chromium is still fine though. I've opened since there's also a nasty GPU acceleration regression now.

, libXcursor, libXext, libXfixes, libXrender, libXScrnSaver, libXcomposite, libxcb , alsa-lib, libXdamage, libXtst, libXrandr, libxshmfence, expat, cups , dbus, gtk3, gdk-pixbuf, gcc-unwrapped, at-spi2-atk, at-spi2-core <del> , libkrb5, libdrm, mesa </del> <ins> , libkrb5, libdrm, libglvnd, mesa </ins> , libxkbcommon, pipewire, wayland # ozone/wayland # Command line programs


Question:
Describe the bug from should have fledgling Ozone/wayland support. Users on other distros are having success. However, I am not. Looks like it might be a Nix-y thing: and no window opens.
I had it working once: (didn't re-test lately tho) It might also be a hardware/driver thing (changing might also help if it's related to any local state). Do you get any additional output (I usually get way more output)? Or it might be due to one of the many upstream bugs (). But if this is indeed related to Nix investigating/fixing it would be very nice.
too, saw it working once. , local state does affect it. I was having a totally different crash until I deleted . used to get more output, but no, that's everything, verbatim what I get from launching yesterday. It very well could just be upstream, but I'm getting jealous of adhoc reports of those builds working on other distros. Unfortunately I don't have a lot of time/ideas.
Ok, strange. I just tried this again with 87.0.4280.66 and got the following output (in my case this looks as with previous versions that crashed though). <details<summaryConsole output (the 2nd time no browser window appeared anymore)</summary<pre[nix-shell:~/google-chrome]$ which google-chrome-stable /nix/store/j3v003nw7mkhdzys4wih1zvw2lsvm8cq-google-chrome-87.0.4280.66/bin/google-chrome-stable [nix-shell:~/google-chrome]$ google-chrome-stable --enable-features=UseOzonePlatform --ozone-platform=wayland [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGL failed with error EGLNOTINITIALIZED, trying next display type [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGLES failed with error EGLNOTINITIALIZED [(20)] GLSurfaceEGL::InitializeOneOff failed. [(150)] Exiting GPU process due to errors during initialization [(621)] Failed to call method: org.freedesktop.DBus.Properties.Get: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(374)] InitializeSandbox() called with multiple threads in process gpu-process. [nix-shell:~/google-chrome]$ google-chrome-stable --enable-features=UseOzonePlatform --ozone-platform=wayland [(621)] Failed to call method: org.freedesktop.DBus.Properties.Get: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGL failed with error EGLNOTINITIALIZED, trying next display type [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGLES failed with error EGLNOTINITIALIZED [(20)] GLSurfaceEGL::InitializeOneOff failed. [(150)] Exiting GPU process due to errors during initialization [(374)] InitializeSandbox() called with multiple threads in process gpu-process. [(122)] ContextResult::kTransientFailure: Failed to send GpuChannelMsgCreateCommandBuffer. </pre</detailsYou're right, I just tried the exact same version but with instead of and it works pretty flawlessly (videos don't play but the rest seems fine). So this issue only seems to affect Google Chrome. Also: With Chromium I don't get any of those error messages on the console that I get with Google Chrome (only the usual ones as in your initial post, not the ones related to ANGLE/EGL/X11).
Since we will lose some Google account related stuff in chromium quite soon[1], I am looking into using Chrome for some stuff. At the moment I am using Chromium via and it is wonderfully fast and smooth (sway, nixos-unstable, intel-gpu), even though I have to disable something about video acceleration[2]. None of the three Chrome builds start with as reported in this Github issue. When also adding it runs (as a Wayland window), but the performance is bad. [1] ,-By%20Joey%20Sneddon&text=Users%20of%20the%20Chromium%20web,builds%20from%20March%2015%2C%. [2]
could you also report your Wayland compositor and GPU? Maybe that's related. I did test this on Sway and Weston (IIRC) with an old AMD Radeon HD 6950 GPU (Mesa's Radeon R600 Gallium3D Driver). I've also started following a few upstream issues that could be related: (seems Nvidia specific though) (reproducible on wlroots-based compositors) I'm still not sure if this is an upstream issue, GPU driver or Wayland compositor related issue, or Nixpkgs specific (either due to our Chromium packaging, due to some specific system dependencies, or due to issues with our Nix store paths). if you want you could also try to investigate this with e.g. (IIRC I briefly had a look but it's not a priority for me since I don't use Google Chrome).
I am on sway/wlroots/intel-gpu. I'll look into strace, but I fear my Linux debugging skills are a bit rusty.
I am not able interpret the output in any meaningful way, but I was able to get some more log output: conincides with
Wayland works on latest unstable chrome, but rendering falls back to software. Log Messages
It stopped showing window once I close and re-run chrome, but after removing it starts working again.
Current output, just for the record (GPU driver: , flags: ). Current output of (only works via ): Note: This obviously shouldn't try to open the X display. Current output of (doesn't work at all):
I have it working on stable 91.0.4472.114 with just the ozone platform flags, but there's no hardware acceleration at all.
that might be equivalent to the case then (which also works reliably but without hardware acceleration). For M92+ the situation is currently even worse as the GPU acceleration seems to be broken. I need to use to even launch Chromium or Google Chrome (unfortunately I lack time for a proper investigation but at least there are already some upstream bug reports).
With Google Chrome M92+ the Ozone/Wayland support seems to be completely broken on NixOS (coredump during startup): Chromium is still fine though. I've opened since there's also a nasty GPU acceleration regression now.

liberation_ttf curl util-linux xdg-utils wget flac harfbuzz icu libpng opusWithCustomModes snappy speechd bzip2 libcap at-spi2-atk at-spi2-core <del> libkrb5 libdrm mesa coreutils </del> <ins> libkrb5 libdrm libglvnd mesa coreutils </ins> libxkbcommon pipewire wayland ] ++ optional pulseSupport libpulseaudio ++ optional libvaSupport libva


Question:
Describe the bug from should have fledgling Ozone/wayland support. Users on other distros are having success. However, I am not. Looks like it might be a Nix-y thing: and no window opens.
I had it working once: (didn't re-test lately tho) It might also be a hardware/driver thing (changing might also help if it's related to any local state). Do you get any additional output (I usually get way more output)? Or it might be due to one of the many upstream bugs (). But if this is indeed related to Nix investigating/fixing it would be very nice.
too, saw it working once. , local state does affect it. I was having a totally different crash until I deleted . used to get more output, but no, that's everything, verbatim what I get from launching yesterday. It very well could just be upstream, but I'm getting jealous of adhoc reports of those builds working on other distros. Unfortunately I don't have a lot of time/ideas.
Ok, strange. I just tried this again with 87.0.4280.66 and got the following output (in my case this looks as with previous versions that crashed though). <details<summaryConsole output (the 2nd time no browser window appeared anymore)</summary<pre[nix-shell:~/google-chrome]$ which google-chrome-stable /nix/store/j3v003nw7mkhdzys4wih1zvw2lsvm8cq-google-chrome-87.0.4280.66/bin/google-chrome-stable [nix-shell:~/google-chrome]$ google-chrome-stable --enable-features=UseOzonePlatform --ozone-platform=wayland [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGL failed with error EGLNOTINITIALIZED, trying next display type [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGLES failed with error EGLNOTINITIALIZED [(20)] GLSurfaceEGL::InitializeOneOff failed. [(150)] Exiting GPU process due to errors during initialization [(621)] Failed to call method: org.freedesktop.DBus.Properties.Get: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(374)] InitializeSandbox() called with multiple threads in process gpu-process. [nix-shell:~/google-chrome]$ google-chrome-stable --enable-features=UseOzonePlatform --ozone-platform=wayland [(621)] Failed to call method: org.freedesktop.DBus.Properties.Get: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGL failed with error EGLNOTINITIALIZED, trying next display type [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGLES failed with error EGLNOTINITIALIZED [(20)] GLSurfaceEGL::InitializeOneOff failed. [(150)] Exiting GPU process due to errors during initialization [(374)] InitializeSandbox() called with multiple threads in process gpu-process. [(122)] ContextResult::kTransientFailure: Failed to send GpuChannelMsgCreateCommandBuffer. </pre</detailsYou're right, I just tried the exact same version but with instead of and it works pretty flawlessly (videos don't play but the rest seems fine). So this issue only seems to affect Google Chrome. Also: With Chromium I don't get any of those error messages on the console that I get with Google Chrome (only the usual ones as in your initial post, not the ones related to ANGLE/EGL/X11).
Since we will lose some Google account related stuff in chromium quite soon[1], I am looking into using Chrome for some stuff. At the moment I am using Chromium via and it is wonderfully fast and smooth (sway, nixos-unstable, intel-gpu), even though I have to disable something about video acceleration[2]. None of the three Chrome builds start with as reported in this Github issue. When also adding it runs (as a Wayland window), but the performance is bad. [1] ,-By%20Joey%20Sneddon&text=Users%20of%20the%20Chromium%20web,builds%20from%20March%2015%2C%. [2]
could you also report your Wayland compositor and GPU? Maybe that's related. I did test this on Sway and Weston (IIRC) with an old AMD Radeon HD 6950 GPU (Mesa's Radeon R600 Gallium3D Driver). I've also started following a few upstream issues that could be related: (seems Nvidia specific though) (reproducible on wlroots-based compositors) I'm still not sure if this is an upstream issue, GPU driver or Wayland compositor related issue, or Nixpkgs specific (either due to our Chromium packaging, due to some specific system dependencies, or due to issues with our Nix store paths). if you want you could also try to investigate this with e.g. (IIRC I briefly had a look but it's not a priority for me since I don't use Google Chrome).
I am on sway/wlroots/intel-gpu. I'll look into strace, but I fear my Linux debugging skills are a bit rusty.
I am not able interpret the output in any meaningful way, but I was able to get some more log output: conincides with
Wayland works on latest unstable chrome, but rendering falls back to software. Log Messages
It stopped showing window once I close and re-run chrome, but after removing it starts working again.
Current output, just for the record (GPU driver: , flags: ). Current output of (only works via ): Note: This obviously shouldn't try to open the X display. Current output of (doesn't work at all):
I have it working on stable 91.0.4472.114 with just the ozone platform flags, but there's no hardware acceleration at all.
that might be equivalent to the case then (which also works reliably but without hardware acceleration). For M92+ the situation is currently even worse as the GPU acceleration seems to be broken. I need to use to even launch Chromium or Google Chrome (unfortunately I lack time for a proper investigation but at least there are already some upstream bug reports).
With Google Chrome M92+ the Ozone/Wayland support seems to be completely broken on NixOS (coredump during startup): Chromium is still fine though. I've opened since there's also a nasty GPU acceleration regression now.

cp -a opt/* $out/share cp -a usr/share/* $out/share <del> # To fix --use-gl=egl: test -e $out/share/google/$appname/libEGL.so ln -s libEGL.so $out/share/google/$appname/libEGL.so.1 test -e $out/share/google/$appname/libGLESv2.so ln -s libGLESv2.so $out/share/google/$appname/libGLESv2.so.2 </del> substituteInPlace $out/share/applications/google-$appname.desktop  --replace /usr/bin/google-chrome-$dist $exe substituteInPlace $out/share/gnome-control-center/default-apps/google-$appname.xml