Jump to content
Flirc Forums

Linux v0.9.80 Skip app - USB Plugin event unrecognized


Scotland

Recommended Posts

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.>

 

 

  • Like 3
Link to comment
Share on other sites

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 by clayton
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...)

Link to comment
Share on other sites

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 by Brayden P
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by Brayden P
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ?

 

Link to comment
Share on other sites

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 by clayton
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • Scotland changed the title to Linux v0.9.80 Skip app - USB Plugin event unrecognized

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 by texasflirc
  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...