razercfg is a tool for advanced configuration of several Razer branded mice. I'm uploading ebuilds for both 0.04 and 0.05 because 0.05 segfaults for me on amd64. Neither has been tested on any other arch. These packages can also currently be found in my overlay: https://trax.allenjb.me.uk/overlay
Created attachment 198112 [details] razercfg-0.04.ebuild
Created attachment 198114 [details] razercfg-0.05.ebuild
Just a quick note that both packages are exactly the same, except for KEYWORDS. Probably didn't need to bother uploading both, but it's late here =P
compiles and runs fine on my amd64 setup so maybe the keywork -amd64 could be removed for ~amd64 mind you the actualy application (qrazercfg) is of no use to me atm since I have a Razer Copperhead and that device isn't supported yet
Just for the record, this package is currently no replacement for app-misc/razertool...
Does razertool support both the Death Adder (1800) and the Lachesis? If not, I'd probably be willing to look at maintaining this. I've got one of each of those, but I still don't know how some things come together, I'm still reading through the code.... and then there is the whole qtpython portion of it, that i can't/won't test as I do not install qt.
razertool mostly is for the Copperhead (which is the one I have) AFAIR. If 0.0.6 works for you Steev, it may be worth bringing this package in tree then :)
0.0.6 (or recent git) still segfaults here on amd64. I even tried to debug some of it but it makes absolutely no sense. -[hw_deathadder.c:664]----------------------------------------------- printf("udev->bus->dirname: \"%s\"\n", udev->bus->dirname); snprintf(devid, sizeof(devid), "%04X-%04X-%s", udev->descriptor.idVendor, udev->descriptor.idProduct, serial); razer_create_idstr(buf, BUSTYPESTR_USB, "002", DEVTYPESTR_MOUSE, "DeathAdder", devid); --------------------------------------------------------------------- Razer device service daemon udev->bus->dirname: "002" Segmentation fault It has the correct string ("002") but still segfaults when accessing it. Once the printf is removed the hard coded "002" const char works fine. What's really weird is, the 002 needs to be a "const char" and using a normal char fails later on again. Also, it worked in the past when i forced to build a 32bit binary with -m32 but that's no longer possible (latest git version). I think it's currently to problematic to have it amd64 keyworded at all. I've contacted upstream about a year ago and he couldn't find a solution. So anyone who can reproduce the issue and fix it, please contact upstream with a patch.
joker@gentoo.org is actively maintaining it since 2011.
