'ckb-next' From Updated PPM Not Running

[MrDuckGuy]

I updated the PPM.

Since obtaining a Corsair mechanical keyboard (model K70), which needs an "icue" interface to program it (Mac and PC version), I found that a search for 'Corsair' in the PPM results in one application; "ckb-next." It will load into the system. It isn't running though. I'm assuming that there are missing dependencies.

'ckb-next' has a website that lists a series of needed dependencies and libraries, which I tried to install. The program still isn't running.
According to the website, one of the things needed is 'Qt5':
https://frickler24.github.io/ckb-next/m ... index.html

There's a forum that I investigated:
https://groups.google.com/g/ckb-next

Am not knowledgeable enough to get this working as of yet.

Thanks in advance.

bs'd

[MrDuckGuy]

Now I have gotten it to run partially, but the GUI hasn't loaded. I am only getting a 'settings' window and an error pop-up.
Terminal output:
run-as-spot ckb-next
QObject::startTimer: Timers cannot have negative intervals
No GPG2 or GPG detected. Signature verification disabled.
Using QSytemTrayIcon
Path to settings: "/home/spot/.config/ckb-next/ckb-next.conf"
Scanning "/usr/lib/x86_64-linux-gnu/ckb-next-animations/gradient"
Scanning "/usr/lib/x86_64-linux-gnu/ckb-next-animations/heat"
Scanning "/usr/lib/x86_64-linux-gnu/ckb-next-animations/invaders"
Scanning "/usr/lib/x86_64-linux-gnu/ckb-next-animations/life"
Scanning "/usr/lib/x86_64-linux-gnu/ckb-next-animations/mviz"
Scanning "/usr/lib/x86_64-linux-gnu/ckb-next-animations/pinwheel"
Scanning "/usr/lib/x86_64-linux-gnu/ckb-next-animations/pipe"
Scanning "/usr/lib/x86_64-linux-gnu/ckb-next-animations/rain"
Scanning "/usr/lib/x86_64-linux-gnu/ckb-next-animations/random"
Scanning "/usr/lib/x86_64-linux-gnu/ckb-next-animations/ripple"
Scanning "/usr/lib/x86_64-linux-gnu/ckb-next-animations/snake"
Scanning "/usr/lib/x86_64-linux-gnu/ckb-next-animations/wave"
Downloaded new firmware list. 39 entries found.

The popup output:
The ckb-next daemon is not running. This program will not work without it!
Start it once with:
sudo systemctl start ckb-next-daemon
Enable it for every boot:
sudo systemctl enable ckb-next-daemon

20220203-053859-screenshot.png (85.37 KiB) Viewed 1603 times

[mikewalsh]

@MrDuckGuy :-

Perhaps a silly question, but have you in fact tried to start the daemon?

Simply type, in the terminal, exactly what is suggested in the pop-up window, then hit 'Enter'. Assuming all dependencies are satisfied, there's no reason why that shouldn't do what you want...

Mike.

[MrDuckGuy]

@MrDuckGuy :- ... type, in the terminal, exactly what is suggested in the pop-up window, then hit 'Enter' ...
Mike.

Yes, I didn't want the last post to be too long, but this is the terminal output from when I try that:

root# sudo systemctl start ckb-next-daemon
sudo: systemctl: command not found

[mikewalsh]

@MrDuckGuy :-

Perhaps a silly question, but have you in fact tried to start the daemon?

Simply type, in the terminal, exactly what is suggested in the pop-up window, then hit 'Enter'. Assuming all dependencies are satisfied, there's no reason why that shouldn't do what you want...

Mike.

.....except, of course, you don't enter sudo (because we don't need it in Puppy)..!

Mike.

[MrDuckGuy]

... except, of course, you don't enter sudo (because we don't need it in Puppy)..! Mike. [/quote]

root# systemctl start ckb-next-daemon
bash: systemctl: command not found

[mikewalsh]

Oh, pish....

Of course, the damn thing's written to expect systemd, isn't it? The one thing that relatively few people here in Puppyland have got any time for.....

I guess you'll have to be patient, wait a bit, and see if anybody else can help with this. PhilB might have some ideas as to what might be needed; myself, I wouldn't even know where to start in respect of how to advise on this one....

Sorry!

Mike.

[mikeslr]

No guarantees. But like Puppys, Void linux also avoids systemd. [IIRC so does duvian -- but pkgs.org doesn't patrol duvian's repos].
pkgs.org reveals this link to Void's ckb-next binary, https://voidlinux.pkgs.org/current/void ... .xbps.html. You could download the file by opening to https://alpha.de.repo.voidlinux.org/cur ... 86_64.xbps in your web-browser. UExtract will decompress it, after which you could copy the necessary files into your system where your system expects to find them. Depending on which version of ckb-next your system expects you may need to create a symbolic link:
ln -s NAME-OF-the-version you have NAME-OF-THE-VERSION-YOUR-SYSTEM-NEEDS

Less likely to create a mess: try Vpup64 viewtopic.php?t=5016 or devuanpup, viewtopic.php?p=26799#p26799

[MrDuckGuy]

... could download the file by opening to https://alpha.de.repo.voidlinux.org/cur ... 86_64.xbps in your web-browser. UExtract will decompress it ...

Thanks!
Okay, I have the download.
How do we extract this?

20220203-115755-screenshot.png (37.88 KiB) Viewed 1559 times

[rockedge]

Right click with the mouse and from there I believe will be a menu option for Uextract. This program can decompress the .xbps file. (Might need the latest version of Uextract for the xbps extraction).

[mikeslr]

If you need it, the latest version of UEXtract can be obtained from here, viewtopic.php?t=594

UEXtract will create an extraction folder next to the ckb-next xbps file. Burrow into that folder noting the folders you have to open to reach the folder containing the ckb-next file(s). It's likely that it/they has to be copied into the corresponding folder on your system. But maybe tell us, and ask if Fossapup64 doesn't already have that folder.

But before you do that, see what happens if you Right-Click the file(s) and select ListDD from the pop-up window, then click the "Missing" button at the bottom left of the GUI which opens. That might tell you your system will need other files. Check the rest of the extraction folder to see if they also were provided. If not,
Choice 1 -- pack a picnic basket. There's a good chance that you're in for a long hunt for all the parts you're going to need.
Choice 2 -- quit. Using packages foreign to your operating system can result in a long, unsuccessful hunt.
Choice 3 -- Try one of the other Puppys I mentioned.

[MrDuckGuy]

... menu option for Uextract ... can decompress the .xbps ... need the latest version of Uextract for the xbps extraction ...

Thanks. I have the update. Version 4.7. It works! What now?

20220203-175223-screenshot.jpg (10.96 KiB) Viewed 1601 times

ListDD output:
MISSING
No missing dependencies
DEPENDENCIES
linux-vdso.so.1
/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
libudev.so.1 => /lib/libudev.so.1
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
/lib64/ld-linux-x86-64.so.2

20220203-182813-screenshot.jpg (31.58 KiB) Viewed 1599 times

No missing libraries or dependencies:

20220203-193004-screenshot.jpg (18.02 KiB) Viewed 1595 times

[rockedge]

Next I think you can copy what is in those directories to their matching locations on your system. So installed manually in effect. Then start the daemon. There is more info of commands -> https://frickler24.github.io/ckb-next/m ... EADME.html

[MrDuckGuy]

... installed manually in effect. Then start the daemon. There is more info of commands -> https://frickler24.github.io/ckb-next/m ... EADME.html ...

Great! I found all the files in the system directories, so I'm pretty sure I don't need to copy anything yet. I tried to follow the "manual" directions, and the ckb-daemon did install. The ckb program still didn't find it.

Also the systemctl add-on is in the PPM, so I added that, and now the command seems to work, but when I implemented it, I couldn't see any difference.

20220204-010917-screenshot.jpg (46.56 KiB) Viewed 1582 times

Here's the terminal output so far:

20220204-011943-screenshot.jpg (180.06 KiB) Viewed 1582 times

[mikewalsh]

This is a bit like support for so many other 'proprietary' items under Linux.

It's the same with the 'solaar' package for support of Logitech mice & pointing devices. In theory, it sounds great; in practice, however, execution of many of the functions is....so-so. Nowhere near as smooth as you would expect under Windows.

But then, you have to remember; no-one that produces hardware to be used with Windows will even release it onto the market UNTIL they have fully-functioning drivers/additional software completely ready-to-go, OOTB. Most of these companies are in the game to make money out of you, after all!

With Linux and the open-source world, financial remuneration doesn't really enter into it. Devs work on things that interest them; when that interest wanes, projects go stale, and then die. And it all has to be performed via 'reverse-engineering' of the Windows drivers/firmware, anyway, since manufacturers are not interested in supporting a market where there's no money to be made.

Such is the reality of the present-day Linux ecosystem.

Mike.

[MrDuckGuy]

... a bit like support for so many other 'proprietary' items under Linux. ... the reality of the present-day Linux ecosystem. ...

So ... what if I install wine, and download the Windows version of icue (the Corsair utility)? Would that possibly be more straightforward?

Link to Corsair's utility from their website:
https://www.corsair.com/us/en/downloads

[mikewalsh]

@MrDuckGuy :-

Umm.....well, you could certainly try. Nowt to stop you from doing so, but I wouldn't like to say what your chances would be. WINE tends to struggle with translating Window hardware stack 'calls' into its Linux equivalent, simply because in this area, the two really ARE 'different'. Like chalk & cheese, y'know?

There isn't even a mention of this application in the Wine HQ database.....and this has more than 25,000+ items that have been tested for compatibility under WINE. The fact that it's not listed doesn't mean it wouldn't work (after a fashion, perhaps), but it's NOT a good sign...

Your call, TBH. I cannot advise one way or the other on this one.

Mike.

[mikeslr]

Mr. Duckguy,

You remind me of my wife. When we have to go somewhere she'll print-out both Mapquest and Google directions, gets into the car, turns on the Garmins, then asks me 'What route should we take?' Then she does whatever comes into her head.

Puppy is NOT the operating system for which application creators publish instructions. If you want to follow the instructions published for Ubuntu, run Ubuntu.

"UEXtract will create an extraction folder next to the ckb-next xbps file. Burrow into that folder noting the folders you have to open to reach the folder containing the ckb-next file(s). It's likely that it/they has to be copied into the corresponding folder on your system. But maybe tell us, and ask if Fossapup64 doesn't already have that folder." Emphasis added. viewtopic.php?p=48957#p48957

[MrDuckGuy]

... Puppy is NOT the operating system ...

20220204-083332-screenshot.jpg (33.93 KiB) Viewed 1551 times

It's not from ubutu, though - this installed version is the PPM version.

------
I DID compare the extracted files with the installed files, but I don't see the difference between them.
------
Seems like there are a few options; I can try to get the ckb-next utility to recognize that the ckb-next daemon is installed; I can download Corsair's original ICUE utility for Windows and try to run it using wine; I can return the keyboard and get my money back; I can use the keyboard and put up with the annoying animations; I can turn off the backlighting and have a keyboard with backlighting that doesn't work the way I want it to.

[mikewalsh]

This is why, having several years experience of Linux, I tend to research hardware before I buy it. I've learnt it doesn't always pay to buy first, and blithely assume that it will work..!

Mike.

[rockedge]

@MrDuckGuy So let's review what is going on, the ckb-next daemon is installed? If so does the daemon start?

But you are having trouble getting the utilities that communicate with the daemon, to connect? Does the daemon respond from the command line?

The first most important thing is to determine if the ckb-next daemon is up and running, and if it is we're most likely in business

[MrDuckGuy]

... I tend to research hardware before I buy it. I've learnt it doesn't always pay to buy first, ... assume that it will work..!

Thanks Mike. And thanks to everyone else. I did learn a little at least about how to extract files and use the terminal.

I might try to start a new topic on using wine to run the native utility from the manufacturers, but I think I may return the keyboard anyway. I am disappointed that the programming of these types of keyboards aren't self contained. At the prices they charge (considering you can get a Raspberry Pi or an Arduino for under $30), I find it difficult to believe manufacturers can't put enough electronics in these units to make them self-contained so that they can be programmed without any software. They could be updated with flash files or even SD cards, if that is a possible concern, but who knows. Many of these kinds of keyboards are priced well over $100 and even over $200. It's embarrassing that the electronics are at so rudimentary a level that there's almost no onboard programming.

I'm obviously not technical enough to figure this out. I was just trying to get rid of the annoying colors, I just wanted to program it for a single color or white backlight without any animation. The onboard controls don't allow that. The animation can't be disabled without the software. Nor can the multi-colored lighting. It's a great mechanical keyboard to type on though. If you never look at the distracting light show.

IMG_20220204_104222757.jpg (83.46 KiB) Viewed 1546 times

[MrDuckGuy]

@MrDuckGuy So let's review what is going on ... does the daemon start ... to determine if the ckb-next daemon is up and running, and if it is we're most likely in business

Yes, I'm able to get it running from a terminal from root#, but the main utility itself (ckb-next) has to run from spot. I don't know why the utility doesn't recognize that ckb-next-daemon is loaded and running.

I ran it both with and without the sudo command, and killed it and reloaded it (ckb-next-daemon). Each time I start the ckb-next utility, though, it can't see that it's loaded and running.

Terminal output from ./ckb-next-daemon command:

20220204-111523-screenshot.jpg (34.77 KiB) Viewed 1541 times

20220204-011943-screenshot-x.jpg (70.09 KiB) Viewed 1545 times

[rockedge]

Don't despair! We're going to figure it out. This will get the daemon running as spot.
Try:

Code: Select all

killall ckb-next-daemon
run-as-spot ckb-next-daemon

What now is needed to control the daemon and program the keyboard?

[MrDuckGuy]

I think I did try that. Here's the output (in screenshot). It returns an output saying it must be run as root, while the main utility does the opposite - it refuses to run as root:

20220204-111934-screenshot.jpg (38.72 KiB) Viewed 1540 times

[rockedge]

From looking at this screenshot it appears to be working and connected to the keyboard.

I am not sure here what you need now but you can pen another terminal and see if you can start the other program as spot. So one as root and start the other as spot.

Code: Select all

run-as-spot <your-other-program>

[MrDuckGuy]

From looking at this screenshot it appears to be working and connected to the keyboard. ... not sure here what you need now but you can pen another terminal and see if you can start the other program as spot ...

Code: Select all

run-as-spot <your-other-program>

Yes, I've been doing that. I can get it to start with

Code: Select all

run-as-spot <ckb-next>

, but it will hang at the set up screen, then a popup window says that ckb-next-daemon isn't running:

20220204-163912-screenshot.jpg (11.88 KiB) Viewed 1528 times

So, I installed systemctl from the PPM, and tried that command (from the popup):

20220204-164728-screenshot.jpg (64.11 KiB) Viewed 1528 times

Terrminal output (from above screenshot):

Code: Select all

root# run-as-spot systemctl start ckb-next-daemon
ERROR:systemctl:writing STATUS {'MainPID': 27966}: [Errno 13] Permission denied: '/var/run/ckb-next-daemon.service.status'
	 to status file /var/run/ckb-next-daemon.service.status
Traceback (most recent call last):
  File "/usr/bin/systemctl", line 4521, in <module>
    result = command_func(*modules)
  File "/usr/bin/systemctl", line 1755, in start_modules
    return self.start_units(units, init) and found_all
  File "/usr/bin/systemctl", line 1765, in start_units
    if not self.start_unit(unit):
  File "/usr/bin/systemctl", line 1783, in start_unit
    return self.start_unit_from(conf)
  File "/usr/bin/systemctl", line 1793, in start_unit_from
    return self.do_start_unit_from(conf)
  File "/usr/bin/systemctl", line 1886, in do_start_unit_from
    self.execve_from(conf, newcmd, env)
  File "/usr/bin/systemctl", line 2049, in execve_from
    out = self.open_journal_log(conf)
  File "/usr/bin/systemctl", line 1638, in open_journal_log
    return open(os.path.join(log_file), "a")
PermissionError: [Errno 13] Permission denied: '/var/log/journal/ckb-next-daemon.service.log'
root# 

As already noted, the main utility, ckb-next, will not allow itself to run as root:

20220204-165141-screenshot.jpg (20.17 KiB) Viewed 1528 times

Output from above screenshot:

Code: Select all

root# ckb-next
QObject::startTimer: Timers cannot have negative intervals
No GPG2 or GPG detected. Signature verification disabled.
The ckb-next GUI should not be run as root.
root# 

[rockedge]

Right now try ->

Code: Select all

ckb-next-daemon
run-as-spot ckb-next

never mind the systemctl yet! And that is already installed and does not need to be installed. That is the service controller for the entire system.

Just try to get the thing running and then comes the time to use systemctl to make it a "service" that the daemon starts at boot. For now just concentrate on starting the thing. I feel like you're making it harder on yourself than it should be.

[mikewalsh]

Right now try ->

Code: Select all

ckb-next-daemon
run-as-spot ckb-next

never mind the systemctl yet! And that is already installed and does not need to be installed. That is the service controller for the entire system.

Just try to get the thing running and then comes the time to use systemctl to make it a "service" that the daemon starts at boot. For now just concentrate on starting the thing. I feel like you're making it harder on yourself than it should be.

Heh. Sometimes you need to take a lateral approach to problem-solving in Puppy. Following instructions to the letter is all very well, but sometimes - just sometimes, mind - ya gotta sneak up on its 'blind-side'....and clobber it into submission!

Mike.

[mikeslr]

I'm reluctant to toss another 2pence in as resolution of the situation is likely above my pay-grade. But I, at least, have nothing to loose.
Spot isn't just a matter of permissions. When it's working properly it's also a matter of location. That is, applications run-as-spot can only access files and applications within the spot folder. So I wonder what would happen --if it was possible-- to reconstruct the entire application, ckb-next included, within the spot folder? Kind-of-like how MikeWalsh constructed Google-Chrome.sfs a couple of years ago.