Package Details: g13-git 20160120-5

Git Clone URL: https://aur.archlinux.org/g13.git (read-only)
Package Base: g13
Description: Userspace driver for the Logitech G13 Keyboard
Upstream URL: https://github.com/ecraven/g13
Licenses: unknown
Submitter: punkrockguy318
Maintainer: khampf
Last Packager: khampf
Votes: 5
Popularity: 0.286333
First Submitted: 2015-09-04 03:37
Last Updated: 2016-04-03 17:18

Dependencies (3)

Required by (0)

Sources (3)

Latest Comments

1 2 3 4 Next › Last »

tib05 commented on 2018-11-03 02:19

The package is also segfaulting for me, but as krafgor said, if you use the --log_level switch with those values: "warning", ""fatal" and "error", the executable doesn't segfault anymore. It somehow seems to be link with the output that the program produces depending on that log_level switch. I'm not sure how I could debug this further

VileLasagna commented on 2018-09-16 07:45

This seems to be some optimization gone wrong somehow. I prepended " CXXFLAGS=-ggdb" to the make call in the PKGBUILD to try and suss this out but then it just stopped crashing altogether.

Also possible that this had to do with me adding the UDEV rule from the repo and calling "sudo udevadm trigger" to be able to debug it in the first place but I'm going to call that "very very unlikely".

All in all pretty weird. I was getting the same sort of result (locally built worked, from package random segfault). Now the systemd service seems to be working, the whole thing.

It's good enough for me personally right now, but let me know if there's something else I can help with if this doesn't magically fix itself

khampf commented on 2018-06-24 19:44

I have been looking into the segfaults as I also am getting them but as far as I can tell it is a bad allocation and could even be permissions but I have not gotten it to work yet. Next step will be to load the sources in an IDE and see what is what. Not sure when I will have time to do so but I even started thinking rewriting some boost library usage into modern STL because I have had it with the boost libraries

krafgor commented on 2018-06-23 22:26

Output showing a segfault:

[zeus@pe ~]$ sudo /usr/bin/g13d [2018-06-23 17:19:44.892711] [0x00007f0b69e22780] [info] set log level to info [2018-06-23 17:19:44.892848] [0x00007f0b69e22780] [info] Known keys on G13: Segmentation fault

That said:

[zeus@pe ~]$ sudo /usr/bin/g13d --config /etc/g13/default.bind --pipe_out /run/g13d/g13-0_out --log_level error

Produces:

[2018-06-23 17:24:26.101508] [0x00007face96c3780] [info] set log level to info [2018-06-23 17:24:26.101585] [0x00007face96c3780] [info] set_string_config_value config = "/etc/g13/default.bind" [2018-06-23 17:24:26.101600] [0x00007face96c3780] [info] set_string_config_value pipe_out = "/run/g13d/g13-0_out" [2018-06-23 17:24:26.101615] [0x00007face96c3780] [info] set_string_config_value log_level = "error" STICK_UP { 0 x 0.1 / 1 x 0.3 } SEND KEYS: UP STICK_DOWN { 0 x 0.7 / 1 x 0.9 } SEND KEYS: DOWN STICK_LEFT { 0 x 0 / 0.2 x 1 } SEND KEYS: LEFT STICK_RIGHT { 0.8 x 0 / 1 x 1 } SEND KEYS: RIGHT STICK_PAGEUP { 0 x 0 / 1 x 0.1 } SEND KEYS: PAGEUP STICK_PAGEDOWN { 0 x 0.9 / 1 x 1 } SEND KEYS: PAGEDOWN

Along with what appears to be a functioning device.

When I hit ctrl+c, I get the segmentation fault (I do not know if that is surprising, since ctrl+c is supposed to kill the process).

Or, I guess a better test:

[zeus@pe ~]$ sudo /usr/bin/g13d --log_level error

Also produces the working keypad and (ctrl+c) produces:

free(): invalid pointer Aborted

What do I need to do to help troubleshoot the issue?

Techjar commented on 2018-06-09 06:19

Not sure what, but something changed recently and g13d now segfaults with this package. If I clone the git repo and build it myself it runs fine.

khampf commented on 2017-06-08 09:32

punkrockguy318: I would rather not bump the pkrel without having a single change in this package, if someone holds libboost at a specific version they would be urged to recompile exactly the same binary over and over without any changes. The solution would be to have backwards compatibility when linking with libboost and not dependant on a single version. We should check into if libboost is linked right or what the problem upstream really is

punkrockguy318 commented on 2017-06-08 00:38

@khampf - the only thing i could think to do would be to bump pkgrel each time this package requires a recompile. that will prompt users using an AUR helper to recompile the package.

khampf commented on 2017-06-06 13:01

It breaks every time libboost gets updated, a recompilation is needed to make it operational again. Not sure on how to solve this as pinning libboost version would make me notice earlier but a recompilation with theese sources as is do work on all versions of libboost.

punkrockguy318 commented on 2017-06-05 23:29

@Skylead
Are you still having this issue? I just recompiled today and didn't have any shared library issues

Skylead commented on 2017-06-02 22:10

Broken with boost 1.64.0

g13d: error while loading shared libraries: libboost_program_options.so.1.63.0: cannot open shared object file: No such file or directory