Scotland Posted June 26 Report Share Posted June 26 Glad to see the first Linux version of the Skip app become available for download! The app launches but does not appear to recognize the remote when it is plugged in via USB. Details are included in a separate thread <opening this thread in the Beta feedback section of the forum.> 3 Quote Link to comment Share on other sites More sharing options...
clayton Posted June 26 Report Share Posted June 26 (edited) Originally thought this might be a permission issue, since (in my Debian VM), `/dev/hidraw*` is owned by root. I added this udev rule to set group ownership of hidraw devices to 'plugdev': KERNEL=="hidraw*", SUBSYSTEM=="hidraw", MODE="0644", GROUP="plugdev" Anyways, that wasn't enough to get it working for me. Next I fired up wireshark just to see if the app was even attempting to communicate with the remote, and I didn't see any host-->device traffic after starting the app. So my current theory is that there's still some permission issue that's preventing the app from writing to the device. But without the source code, only the flirc.tv folks can solve this :( Please consider releasing the source code for this app. It's currently a disaster to run/debug on Linux (appimage isn't actually all that portable) Edited June 26 by clayton Quote Link to comment Share on other sites More sharing options...
Brayden P Posted June 26 Report Share Posted June 26 I ran into this same issue when trying to get the app working in a VM... I was able to fix it by just changing the ownership of the /dev USB device to my user, but that isn't a good long term solution. Is your user in the plugdev group @clayton? On the appimage front, personally i have found appimages to be very finicky and have had better luck with flatpaks. That doesn't mean flatpaks are foolproof either though, i agree that releasing the source code is best long term. Quote Link to comment Share on other sites More sharing options...
clayton Posted June 26 Report Share Posted June 26 1 hour ago, Brayden P said: I ran into this same issue when trying to get the app working in a VM... I was able to fix it by just changing the ownership of the /dev USB device to my user, but that isn't a good long term solution. Which specific device node under /dev did you change ownership for? As you can see in my udev rule above, I was setting it on /dev/hidraw*, but if the app is using something else (/dev/ttyUSB* or ??) then the udev rule could be adjusted easily to set permissions automatically 1 hour ago, Brayden P said: Is your user in the plugdev group @clayton? Yes of course :) 1 hour ago, Brayden P said: On the appimage front, personally i have found appimages to be very finicky and have had better luck with flatpaks. That doesn't mean flatpaks are foolproof either though, i agree that releasing the source code is best long term. Ya in my experience flatpak is the least bad option for an "application bundle" distribution thing. Ideally the source for this application would be available so it could be provided in distro packaging and packaged as a flatpak (the two aren't mutually exclusive...) Quote Link to comment Share on other sites More sharing options...
Brayden P Posted June 26 Report Share Posted June 26 (edited) 1 hour ago, clayton said: Which specific device node under /dev did you change ownership for I honestly don't remember but it was what showed under lsusb. I applied it too just one device by manufacturer ID though, not all USB devices. Edited June 26 by Brayden P Quote Link to comment Share on other sites More sharing options...
clayton Posted June 27 Report Share Posted June 27 18 hours ago, Brayden P said: I honestly don't remember but it was what showed under lsusb. I applied it too just one device by manufacturer ID though, not all USB devices. Did you do this via a udev rule or `chown /dev/something` ? If you used a udev rule, did you match on the usb subsystem or ?? If you used chown manually, what file did you change ownership on? I've tried several variations of the udev rule I posted earlier, including making *all* usb devices RW for a group my user is in, but nothing seems to work. For kicks, I used strace to figure out if there's an explicit open() for some device file that fails, but I wasn't able to see anything obvious. I don't have any more ideas for debugging this particular app, it's a blackbox. flirc folks: How can I help you figure this out? How are customers supposed to get support for this product? Quote Link to comment Share on other sites More sharing options...
Brayden P Posted June 27 Report Share Posted June 27 (edited) 2 hours ago, clayton said: Did you do this via a udev rule or `chown /dev/something` ? If you used a udev rule, did you match on the usb subsystem or ?? If you used chown manually, what file did you change ownership on? I did chown [my user] /dev/bus/usb/vendorid/productid/. I found the vendor and product ids with lsusb. As I said, I never actually got it working though, so... Edited June 27 by Brayden P Quote Link to comment Share on other sites More sharing options...
clayton Posted June 27 Report Share Posted June 27 1 hour ago, Brayden P said: As I said, I never actually got it working though, so... Ohhhh I thought you **had** gotten it to work (emphasis mine): 23 hours ago, Brayden P said: I ran into this same issue when trying to get the app working in a VM... **I was able to fix it** by just changing the ownership of the /dev USB device to my user, but that isn't a good long term solution. Ok, so it seems like this may not be a permission issue then... In that case, we'll really need flirc's help... or access to the source code(...) so we can try to figure it out. Quote Link to comment Share on other sites More sharing options...
Brayden P Posted June 27 Report Share Posted June 27 To be clear, this issue that I had was through a Windows VM on my Linux machine, but it was a similar issue, which suggests a permission issue might exist. I was able to fix the permission issue, just other issues came up after that when I was working through the VM. I was also unable to run the Windows program through WINE, though I haven't yet taken a crack at the actual Linux version. Quote Link to comment Share on other sites More sharing options...
JackWhis Posted June 28 Report Share Posted June 28 Hi, Same problem here with Ubuntu 22.04.2 LTS, I see no "continue" button when plugging my remote as requested in the app. And when the app starts I get the following set of errors in the console: "Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so /usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_name Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so (WebKitWebProcess:13899): Gtk-WARNING **: 15:53:01.994: Theme parsing error: gtk.css:1422:23: 'font-feature-settings' is not a valid property name (WebKitWebProcess:13899): Gtk-WARNING **: 15:53:01.996: Theme parsing error: gtk.css:3308:25: 'font-feature-settings' is not a valid property name (WebKitWebProcess:13899): Gtk-WARNING **: 15:53:01.997: Theme parsing error: gtk.css:3770:23: 'font-feature-settings' is not a valid property name /usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_name Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so /usr/lib/x86_64-linux-gnu/gio/modules/libgiognomeproxy.so: undefined symbol: g_task_set_name Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiognomeproxy.so /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so: undefined symbol: g_task_set_name Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so /usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_name Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so" As mentioned here before lsusb sees the two devices just fine "Bus 001 Device 008: ID 20a0:0008 Clay Logic Skip 1s Bus 001 Device 005: ID 20a0:0006 Clay Logic flirc" I assume there's a problem with the installer ? Quote Link to comment Share on other sites More sharing options...
clayton Posted June 28 Report Share Posted June 28 (edited) 2 hours ago, JackWhis said: And when the app starts I get the following set of errors in the console: "Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so /usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_name Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so (WebKitWebProcess:13899): Gtk-WARNING **: 15:53:01.994: Theme parsing error: gtk.css:1422:23: 'font-feature-settings' is not a valid property name (WebKitWebProcess:13899): Gtk-WARNING **: 15:53:01.996: Theme parsing error: gtk.css:3308:25: 'font-feature-settings' is not a valid property name (WebKitWebProcess:13899): Gtk-WARNING **: 15:53:01.997: Theme parsing error: gtk.css:3770:23: 'font-feature-settings' is not a valid property name /usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_name Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgvfsdbus.so /usr/lib/x86_64-linux-gnu/gio/modules/libgiognomeproxy.so: undefined symbol: g_task_set_name Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiognomeproxy.so /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so: undefined symbol: g_task_set_name Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so /usr/lib/x86_64-linux-gnu/gvfs/libgvfscommon.so: undefined symbol: g_task_set_name Failed to load module: /usr/lib/x86_64-linux-gnu/gio/ It looks like this app is built with Tauri[1], which provides the build system for generating the appimage (I determined this by running 'strings' on the app's exe within the appimage). These seem to be linker errors, because there must(?) be some bug in Tauri's appimage packaging where some dependencies aren't included or detected properly at runtime, so the host libs are searched instead and it's not able to find some symbols presumably because it was (dynamically...) linked against some different version. appimage is really not a great portable format for these things... It also dynamically links against glibc (so, it requires glibc on the host), meaning it won't work on distros that don't use glibc. appimage also depends on FUSE, which may not be available on some distros/kernels. 1. https://github.com/tauri-apps/tauri Edited June 28 by clayton 1 1 Quote Link to comment Share on other sites More sharing options...
Scotland Posted July 14 Author Report Share Posted July 14 I just downloaded and tried the 0.9.90-Beta for Linux and there appears to be no change for me - plugging in the remote to the computer via the USB cable is not recognized by the app. I'm on Ubuntu 22.04.2 LTS using the 5.15 kernel version. Quote Link to comment Share on other sites More sharing options...
texasflirc Posted July 16 Report Share Posted July 16 (edited) Just posting to follow the conversation and show support for linux. Its DOA until the appimg issue is solved from the looks of it. I got the program to install on Fedora using AppImageLauncher but it does not see USB devices. I saw the app download on the website so I thought linux support was working. May want to make it clearer that it isnt. Edited July 16 by texasflirc 1 Quote Link to comment Share on other sites More sharing options...
jason Posted July 26 Report Share Posted July 26 Try 0.92, there is no automatic update in the app yet. It will now prompt you for permissions to install the udev rules. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.