Activity for KShots
-
KShots posted a comment on ticket #2
Actually, I was wrong - it shouldn't return "0" on success, it should return a positive number representing the file descriptor assigned. In your case, it successfully opened dacal.so and gave it a file descriptor of 3, then read it, and closed it (all successfully)... so yes, it definately successfully loaded the plugin. As far as uninstalling and starting over, that's usually up to the package manager. If you didn't use a package manager, you can see where cmake installs each file by setting up...
-
No, if you never had a previous version installed, that shouldn't be a possibility :(
-
Ok, so we'll say that's not a possibility. Let's make 100% sure it's loading the plugin. Use 'strace' to run the daemon. It will put out a TONNE of data, be warned. Look for any lines involving 'dacal.so', and more specifically, make sure that one such line returns "0" (success). ... if it's truly loading the plugin and not finding the organizer, I'm not sure what else to do at this point. If you know any C, I'd recommend running the dacal.c constructor code through a debugger (set a breakpoint in...
-
Neal, The daemon searches the plugin directory and tries to load each file there. I've been puzzled why it puts out those "file not found" messages, but libtool appears to try both with and without a '.so' extension (and fails without the extension, but succeeds with it). From the output, it is successfully loading the KDS plugin (despite the message) because the notification about the KDS plugin capabilities is from the KDS plugin. So... if it's loading the plugin successfully, it will poll the...
-
Only other thing I can think of is if it's not loading the dacal plugin. It looks for the vendor ID 04B4 and product ID 5A9B to find the organizer, and if the plugin finds it the daemon outputs the string "Found a device for the dacal plugin at (some address)". Can you find where your plugin was installed (should be 'dacal.so') and tell the daemon where to find it via the '-P' option? If you don't have a DC-016RW, the svn version shouldn't make much of a difference... it has a bit more tolerance...
-
Only other thing I can think of is if it's not loading the dacal plugin. It looks for the vendor ID 04B4 and product ID 5A9B to find the organizer, and if the plugin finds it the daemon outputs the string "Found a device for the dacal plugin at (some address)". Can you find where your plugin was installed (should be 'dacal.so') and tell the daemon where to find it via the '-P' option?
-
Also, just to confirm, you're using the latest released version, right? From your lsusb output, it showed you might have a Dacal 016RW, which wasn't supported until recently. I'd even go so far as to say that after some recent back-and-forth with another recent user, that I'd recommend using the latest version from the svn for the DC-016RW. Can you try the svn version?
-
Also, just to confirm, you're using the latest released version, right? From your lsusb output, it showed you had a Dacal 016RW, which wasn't supported until recently. I'd even go so far as to say that after some recent back-and-forth with another recent user, that I'd recommend using the latest version from the svn for the DC-016RW. Can you try the svn version?
-
Ok, the traffic on the daemon looks appropriate... did the client not return anything useful?
-
Looks like it's aborting because something else is already bound to the socket. Check to see if it's already running, and if not, delete the socket (it's stale) and try again. If it is running, kill it and run it again in the foreground
-
Neal, Pass the daemon a '-f' parameter to run in the foreground, so you do the following: sudo cdorganizerd -f You can also run it with '-h' to show what other knobs you can tweak.
-
Neal, Let's dig into this a bit... To confirm, you are running the daemon, right? I assume so because you did at one point find that the socket was created. If running into problems, recommend running the daemon in the foreground to observe any output. Make sure you are running the daemon with a user that has read/write access to the device. The lcdoctl utility can be run by any user (non-root). Let's start with that...
-
Neal, Sounds like you're almost there. You can start the daemon (cdorganizerd) with the '-h' or '--help' parameter to give you some idea of what parameters are available. Man pages are also installed - try "man cdorganizerd" and "man lcdoctl", although if you had to reconfigure ldconfig to get it running, the man pages may not have installed to the system. At a high level, the concept is that the daemon controls the organizer and runs in the background, and you can use lcdoctl to talk to the daemon...
-
* Fixed execution of insert disc code so it only executes DC016-specific code on insert on a DC016 device, rather than both DC016 and DC300 code
-
* Fixed issues with the dacal plugin returning messages to the daemon on the DC016RW for vendor command 4
-
* Fixed some boundary-checking cases for command execution
-
Try:lcdoctl -d dacal:0001094E execredirect 4 /tmp/test.txtStill shouldn't segfault, though... I'll have to investigate that.On Apr 4, 2018 11:59, Jeremy Turner <fabltd@users.sourceforge.net> wrote:Ok this fails: lcdoctl -d dacal:0001094E execredirect 4 dacal:0001094E /tmp/test.txt Results in: Segmentation fault (core dumped) Support for the DC016RW Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/libcdorganizer/discussion/613438/ To unsubscribe from further messages,...
-
I've done some refactoring that may have affected these... see what happens with revision 161.
-
* Fixed busy loop error in code that prevented all functions from working properly...
-
* Refactored the dacal plugin to call a function for its busy wait loops rather than pasting the same loops everywhere...
-
* Fixed pointer handling on vendor functions...
-
* Updated the interface to support bidirectional communication with plugins. I thought this was ironed out 10 years ago, but some refactoring was in order to handle error conditions in a sane manner
-
Ok, I'll see what I can crank out. The vendor functions are implemented exclusively in the plugins. lcdoctl simply passes them through. There shouldn't be any changes necessary in lcdoctl to add more functions. On 2018-03-13 16:40, Jeremy Turner wrote: Hi Quick hack sounds great. My c experience is only limited. So any help will be great. You'll need to add any new commands to the exec function and the list function. Is this in lcdoctl as well as dacal.c ? Support for the DC016RW [1] Sent from sourceforge.net...
-
The returned data is simply dropped by lcdoctl. If you want to monitor the returned data, you'll need to tie into the library functions directly. I'd considered some advanced tuning on lcdoctl that lets the user attempt to define the data returned for user-friendly parsing, but had not implemented it. Essentially, I'd need to write a parser for each type of data (char, string, short, long, binary blob (as hex? ), etc). Even then, depending on the data it may not handle it correctly - for example,...
-
lcdoctl doesn't parse the data returned from vendor functions, as they could be pretty much anything (strings, ints, binary blobs, etc). For adding additional commands, you'll need to modify dacal.c (the plugin) to support additional functions. You'll need to add any new commands to the exec function and the list function. On 2018-03-13 14:57, Jeremy Turner wrote: Hi Thanks Can the error be displayed as is in lcdoctl ? I belive my unit may also use some commands that you have not sniffed. I would...
-
Ok, now we're getting somewhere! I can see I screwed up the help - the vendor command should simply look at the '-d' argument, not requiring an additional device_id after the vendor command. At least, that's how it works programmatically. So the proper usage would be: lcdoctl -d dacal:0001094E vendor The control commands were reverse-engineered using a USB sniffer and the Windows control API to trigger and capture event traffic. As such, some commands are supported... if you know how to use it. The...
-
Which model are you using? The Dacal DC-300, the DC016RW, or something else?
-
Jeremy, Not sure... what build options did you pass to cmake? You can get a console-based configuration browser by running 'ccmake' on the source directory, which should let you tweak whatever values you need to make it work properly in your environment. The only dependencies for libcdorganizer are libusb-1.x and libtool. Your plugin loading issue is a bit strange... I can successfully load my plugins in my testing environment. It has me scratching my head that the daemon appears to know that the...
-
Jeremy, Not sure... what build options did you pass to cmake? You can get a console-based configuration browser by running 'ccmake' on the source directory, which should let you tweak whatever values you need to make it work properly in your environment. The only dependencies for libcdorganizer are libusb-1.x and libtool. Your plugin loading issue is a bit strange... I can successfully load my plugins in my testing environment. It has me scratching my head that the daemon appears to know that the...
-
Jeremy, I've updated the source and amd64 binary release for libcdorganizer after merging the 4.0.0 branch into the trunk... so try testing with that version. It looks like you were using the older 3.1.2 version from SVN. Working with your other questions, the lock file should have been under /var/run. Let me know what you experience when you use the newer version...
-
* Merged the 4.0.0 branch into the trunk
-
* Updated to include man pages for all components and public functions
-
I realize this thread is very old, but if someone is experiencing this issue, can you tell me what you're running on the command line, what the response is, and what the physical device is doing? I'm no longer convinced this is a HID device detachment issue.
-
Jeremy, yes and no. The svn version supports most functions of the DC016RW device. My last comment from nearly a decade ago was that there was a compatibility issue between the HID layer and the USB layer, in that libcdorganizer boots off the HID-layer controller so it can control it, and that causes the DVD device to not read properly. I think I was wrong with that assumption at this point. Looking back at the history of this thread, if what Knight wrote is correct (and he has been very accurate...
-
* Upgrading the laptop the existing code is sto...
-
* Coming back from a long break... inevitable c...
-
* Lots of work done in the rules section
-
* Tested all currently-defined client functiona...
-
* Lots and lots of refactoring...
-
* Fixed a nasty and difficult to trace crash ca...
-
* Added a 'core' library, which contains basic ...
-
* Spoke too soon, quite a few bugs in client/se...
-
* Fixed a crash on close caused by sockets atte...
-
* Client now communicates properly with server,...
-
* Client connections are functional again
-
* More progress on the client. Got rid of the M...
-
* Removed google's protocol buffers from code, ...
-
* Got tired of the dual dock widget approach, a...
-
* Moved from a simple TCP socket to an SSL sock...
-
* Tracked down and killed a chat bug - In the u...
-
* Fixed duplicate message issue - the server si...
-
* The client now works with functional dockwidg...
-
* Fixed one of the causes of double messages as...
-
* While only a few files were touched, signific...
-
* Wrestled with compiler optimizations to get t...
-
* Lots of refactoring of all messages
-
* Fixed an annoying memory bug that was trigger...
-
* Client/server/listserver communication has be...
-
* Moved the 6.0 branch to the trunk
-
* Made some minor changes that I could not relo...
-
Dependencies
-
Home
-
Architecture
-
Home
1