Re: [concordance-devel] [PATCH] Fix serial number handling for ZWave-HID remotes.
On 07/30/2013 12:25 AM, Phil Dibowitz wrote: On 07/23/2013 08:15 PM, Scott Talbert wrote: Use the normal byte ordering for them. Additionally, we were off by one byte when copying the the serial number data in UDP_Read(). Applied. Thanks, this format works great. I like this workflow quite a lot. Though I understand why the kernel maintainers are so picky about commit messages now... this flow doesn't give you the opportunity to tweak the message at the last second. You can edit the saved email, or simply run git commit --amend after it's been applied. If you apply a bunch of patches in a batch, you can use git rebase -i to edit commit messages further back. You likely want to do all that before you push though. -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] [PATCH] Fix serial number handling for ZWave-HID remotes.
On 07/30/2013 10:16 AM, Phil Dibowitz wrote: On 07/30/2013 08:09 AM, Stephen Warren wrote: On 07/30/2013 12:25 AM, Phil Dibowitz wrote: On 07/23/2013 08:15 PM, Scott Talbert wrote: Use the normal byte ordering for them. Additionally, we were off by one byte when copying the the serial number data in UDP_Read(). Applied. Thanks, this format works great. I like this workflow quite a lot. Though I understand why the kernel maintainers are so picky about commit messages now... this flow doesn't give you the opportunity to tweak the message at the last second. You can edit the saved email, or simply run git commit --amend after it's been applied. If you apply a bunch of patches in a batch, you can use git rebase -i to edit commit messages further back. You likely want to do all that before you push though. AFAIK, you can't amend commits by another person, and commit happens in the tree as you. No, you can amend any commit without affecting the patch author field. I do it all the time. BTW, I'm pretty sure there's even a cmdline option to git am that'll allow you to edit the commit description while the patch is being applied the first time, so there wouldn't even be a need to amend it. -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] LatestFirmware.hfw?
On 06/19/2013 07:07 AM, Scott Talbert wrote: ... Nope, Update Remote is what you want. That should give you a configuration file, not a firmware file. I wonder if perhaps we are reporting the firmware version incorrectly to the website and it is thinking that we need to upgrade the firmware. If the FW on the remote is too old (to support the new config file, simply not the latest, by some other metric?), the website will push a FW update first, IIRC. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Remote (525) not detected after successful update: couldn't initializing libconcord: Error connecting or finding the remote
On 10/24/2012 05:19 PM, Curtis Walker wrote: Hello! My first email to the list. I finally got sick of booting into Windows just to update my Harmony 525. It's about the only thing I still use Windows for, so finding concordance and congruity was most welcome. Anyway, I have successfully updated my remote using concordance (0.24) and congruity frontend (ver. 15) using the Logitech website (http://members.harmonyremote.com/) as per the instructions here: http://madabar.com/techblog/2011/09/09/logitech-harmony-universal-remote-linux-software-support/ My distro is Arch Linux (rolling release, up to date, using systemd). 1. Remote is successfully detected (evidenced by concordance -iv in terminal). 2. Congruity launches appropriately when using the logitech website () 3. Remote update is successful, but the Reconnect to Remote stage fails. 4. running concordance iv in a terminal at this time states ERROR: Couldn't initializing libconcord: Error connecting or finding the remote That shows that concordance can't re-connect to the remote, whereas... This appears the same as this discussion thread: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584896. From what I ... in that bug report, concordance can re-connect to the remote. This sounds like a different issue? -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Congruity Port to New API
On 07/26/2012 07:29 PM, Scott Talbert wrote: On Mon, 23 Jul 2012, Stephen Warren wrote: ... If you want, perhaps I can hand off congruity maintenance to you since you've obviously got some interest in it; I assume that Sourceforge will let me set up other committers/admins. Let me know if you want, and what your Sourceforge login ID is. Sure, I wouldn't mind helping with the maintenance. My Sourceforge ID is swt2c. OK, I've added you to the project with full admin capabilities; feel free to move the project forward as you see fit. Let me know if you have any questions about how things are set up. I'd suggest you check in the changes for the new libconcord branch in a side-branch until the required libconcord release is made; that way, main/master/HEAD congruity will continue to work with main/master/HEAD libconcord. I believe svn makes it easy enough to do one-off merges into the main branch these days (or just migrate it to git:-). -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Congruity Port to New API
On 07/15/2012 08:53 AM, Scott Talbert wrote: Hi Stephen, I have been contributing to Concordance lately, and I have written a patch for Congruity to port it to the new libconcord API. If you have some time, I would greatly appreciate it if you could review the patch, which I have attached. Details on my changes are listed below. Sorry for the slow response; I've been away on vacation. I've quoted the attachment below. A lot of my feedback is more about the libconcord API changes than the congruity patch itself. +import threading It'd be better to simply consistently use thread rather than mixing thread and threading. -version = 15+ +version = 16+ Functional patches shouldn't touch the version; it should only be bumped during or right after release. -# Fix typo in libconcord 0.20 Python bindings +# Test to ensure we have the new API available. try: -libconcord.delete_blob +libconcord.update_configuration except: -libconcord.delete_blob = libconcord.delete_block +str = traceback.format_exc() +app = wx.PySimpleApp() +dlg = wx.MessageDialog( +None, +Could not load the correct version of libconcord; please ensure +that the latest version is installed.\n\n + str, +congruity: Dependency Error, +wx.OK | wx.ICON_ERROR +) +dlg.ShowModal() +os._exit(1) Hmm. I've made sure that congruity to date can run with almost any version of libconcord. That change breaks this feature. Isn't there a way to introduce support for the new libconcord APIs without making it non-backwards-compatible? -def program_callback_imp(count, current, total, context): +def program_callback_imp(stage_id, count, current, total, type, context): if not context: return +if stage_id == libconcord.LC_CB_STAGE_NUM_STAGES: +return + try: -(f, fcontext) = context -percent = (current * 100) / total -f(False, percent, fcontext) +if isinstance(context, ProgramRemotePanelBase): That's not very object-oriented; it'd be better to call a function/method in the context object, and have that function do whatever is appropriate, rather than having the code query the type of the context and then act differently. +if stage_id not in context.dg_widgets: +context.dg_widget_added = threading.Event() +wx.CallAfter(context._AddDg, stage_id) +context.dg_widget_added.wait() +context._DgStart(context.dg_widgets[stage_id]) Uggh. I'll comment on that later. @@ -379,54 +365,7 @@ class WelcomePanel(MessagePanelBase): self.next = self.resources.page_connect -xml = POINTER(c_ubyte)() -xml_size = c_uint() -libconcord.read_file( -self.resources.ezhex_filename, -byref(xml), -byref(xml_size) -) -self.resources.SetXmlData(xml, xml_size) - -type = c_int() -libconcord.identify_file(xml, xml_size, byref(type)) Uggh. Why can't libconcord parse the file without being attached to the remote; the file format should be completely standalone and parse-able offline. @@ -688,7 +694,6 @@ class ProgramRemotePanelBase(WizardPanelBase, Deco self.dc = DecoratedContainer(self, self.resources) DecoratedContainerThreadMixin.__init__(self, self.dc) -self._AddWidgets() self.sizer.Add(self.dc, 0, wx.EXPAND | wx.ALL, 5) This and the related changes will cause a horrible regression in the utility of the GUI; the poor user will just see more and more tasks randomly appearing, and have no idea when the end is in sight. congruity may as well embed a vte (terminal) widget and just run the concordance application in it given this change. I've complained about this libconcord API change repeatedly before... That all said, I don't really have much time or motivation for congruity work these days, so I'm not going to really push back hard on these changes. If you want, perhaps I can hand off congruity maintenance to you since you've obviously got some interest in it; I assume that Sourceforge will let me set up other committers/admins. Let me know if you want, and what your Sourceforge login ID is. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] [PATCH] New API, 89x support
On 07/23/2011 01:19 AM, Phil Dibowitz wrote: On 03/08/2011 09:09 AM, Phil Dibowitz wrote: Stephen - Any comments on this? I'd like to prepare to merge this to HEAD, but you're the primary consumer (other than me), so I'd like any input you have... Stephen, you still alive? I'd like to get this merged so I can release 89x and 9xx support and start working in the full zwave support. Like I said at the time, I don't think the API was appropriate for congruity's use, at least not without significantly changing the way the UI represents progress through the programming operations and reducing the amount of information available to the user. That said, I don't have much time to modify congruity to /any/ API these days, so I wouldn't let that stop you moving concordance forward. -- Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Harmony 785 support
On 06/06/2011 09:57 PM, Stephen Warren wrote:
On 06/04/2011 08:59 PM, Mathieu Trudel-Lapierre wrote:
Hi,
Here I'm reporting an issue I got from the Debian bugs for congruity.
For reference, that's http://bugs.debian.org/584896.
Apparently congruity tries to do the Reconnect to Remote task right
after Verify Upgrade. This yields a failure, because it seems like
the 785 restarts after Verify Upgrade as isn't yet ready to answer
to new connections. It's been suggested by the reporter to just wait a
bit in congruity before reconnecting.
Unless something is broken, congruity attempts to connect 60 times, with
a 1 second delay between each try. The remote shouldn't take that long
to reboot...
Does the user see the problem immediately, or after this ~60s delay?
Oh, I checked the code, it's 180 retries after a reset.
This is the error message:
Unknown error
(libconcord function reset_remote error -19)
Traceback (most recent call last):
File /usr/bin/congruity, line 702, in _WorkerFunction
self._WorkerFunctionBody()
File /usr/bin/congruity, line 862, in _WorkerFunctionBody
libconcord.reset_remote()
File /usr/lib/python2.6/dist-packages/libconcord.py, line 97, in
__call__
raise LibConcordException(self.func_name, result)
LibConcordException: libconcord function 'reset_remote' failed with
error code -19 ('Unknown error')
Hmmm. I hould have read that before. libconcord's reset function is
failing, probably because the remote acts on the reset request before it
can actually send back the response to the reset request. I'd suggest
fixing this in libconcord if possible (perhaps just have reset ignore
that kind of error)
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] reset fails
On 02/19/2011 06:06 PM, Phil Dibowitz wrote: On 10/15/2010 08:37 AM, Marc Williams wrote: Using stock Ubuntu 10.04 I tried building concord .23/congruity 15 for my 880. It works well up to a point. Everything is recognized and the remote update proceeds normally through Verify Upgrade but it fails at Reconnect with the following: Stephen, Did you ever look into this? This looks like a congruity issue. I think I'd asked Marc to test with concordance to see if the problem showed up there too or not, but didn't hear anything back. I've never seen this with my 880. All congruity is doing is calling the libconcord connect function every few seconds until it succeeds, so it's hard to imagine why it'd be specific to congruity. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Harmony 900 Support
On 01/09/2011 12:52 PM, Damian wrote: Hi. When will the support for Harmony 900 be available? I don't think there is a specific time-scale; it all depends on when people have the time to work on it. The original software is really crap for customizing. concordance/congruity don't replace the original customization website, they simply implement the method to download the data the website generates to the remote. -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Harmony 700
On 01/08/2011 11:02 AM, Fredrik Sjögren wrote: Hi! If I buy this one, will I be able to use it using Linux? In the support matrix is says that firmware updates is not working. Do I need that? It's fairly unlikely you'll need firmware upgrade. In my uuntu 0.21 is the current version but 0.22 is mention in the bug linked to. Do I need to compile it myself? 0.22 was the first release to support the 700. It looks like Ubuntu natty (not yet released) is the first to include that version of concordance, so yes, you would have to compile from source. It's pretty easy though. -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Config size incorrect on 525
On 10/31/2010 06:01 AM, David Sheldon wrote:
It seems that the config flash size detection doesn't work well on my 525,
see the output of concordance -v -i next.
This may be another fallout from my reformatting of the remote
information table. Does the following patch solve your issue?
diff -u -p -r1.12 remote_info.h
--- libconcord/remote_info.h1 Aug 2010 14:35:52 - 1.12
+++ libconcord/remote_info.h3 Nov 2010 01:18:26 -
@@ -313,7 +313,7 @@ static const TArchInfo ArchList[]={
{
SERIAL_LOCATION_FLASH, // serial_location
0x000110, // serial_address
- 0x00, // flash_base
+ 0x80, // flash_base
0x81, // firmware_base
0x82, // config_base
0x81, // firmware_update_base
Sorry about that...
Concordance 0.23+CVS
Copyright 2007 Kevin Timmerman and Phil Dibowitz
This software is distributed under the GPLv3.
Requesting Identity: 100% done
Model: Logitech Harmony 525 (Mocha Decaf)
Skin: 22
Firmware Version: 2.6
Firmware Type: 0
Hardware Version: 2.5
External Flash: 512 KiB - FF:12 25F040
Architecture: 9
Protocol: 9
Manufacturer: Harmony Remote 0-2.6.0
Product: Harmony Remote 0-2.6.0
IRL, ORL, FRL: 64, 64, 0
USB VID: 046D
USB PID: C111
USB Ver: 0916
Serial Number: {6A02E1FB-BE01-6802-B3D8-9DDF00018E2B}
{6AF8D7ED-0012-6AA6-0001-8E6BBFD80BE2}
{51220104-0100-258E-A96E-A680B0D8A8CF}
Config Flash Used: 102% (-8013 of -7808 KiB)
Success!
It seems that this causes config extraction to fail:
$ sudo ./concordance -v -c
Concordance 0.23+CVS
Copyright 2007 Kevin Timmerman and Phil Dibowitz
This software is distributed under the GPLv3.
Requesting Identity: 100% done
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Dumping config: Aborted
I've read the thread at
http://www.mail-archive.com/concordance-devel@lists.sourceforge.net/msg00992.html
and it looks like the patch mentioned there has been applied to my
tree.
Any idea what else I can do?
David
--
Achieve Improved Network Security with IP and DNS Reputation.
Defend against bad network traffic, including botnets, malware,
phishing sites, and compromised hosts - saving your company time,
money, and embarrassment. Learn More!
http://p.sf.net/sfu/hpdev2dev-nov
___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] API feedback wanted: Supporting zwave remotes
On 08/31/2010 02:26 PM, Phil Dibowitz wrote: On 08/31/2010 06:08 AM, Stephen Warren wrote: So, perhaps: // Returns TLOConnectivity, TLOUpdateConfiguration, TLOUpdateFirmware TopLevelOperation *gen_op_from_website_file(remote, filename); // Always returns TLOBackupFirwmare TopLevelOperation *gen_backup_firmware_op(remote, filename)\ // ... TopLevelOperation *gen_restore_firmware_op(remote, filename) TopLevelOperation *gen_backup_configuration_op(remote, filename) TopLevelOperation *gen_restore_configuration_op(remote, filename) // or one function per operation type: Status tlo_execute(tlo, callback, ...) I guess I just don't see the advantage here over just making our existing API more top-level-oriented, ala: update_configuration(pof) backup_configuration(filename) update_firmware(pof) backup_firmware(filename) set_time() get_time() reset() The primary advantage is having a unified way for an application to query which steps are involved in an operation ahead of time. Without a single TopLevelOperation object that can be queried for all the steps, in order to support libconcord defining operation steps instead of hard-coding them in an application, there would need to be some API per operation type for querying this information. Instead of: tlo_get_step_count(tlo) tlo_get_step_type(tlo, step_id) tlo_get_... You'd have something like: update_config_get_step_count(?) update_config_get_step_type(?, step_id) update_config_get_... backup_firmware_get_step_count(?) backup_firmware_get_step_type(?, step_id) backup_firmware_get_... ... .. an explosion of functions. The unified TopLevelObject also gives a good place to store operation-specific state; e.g. a TLO created for an 880 config update might include the set-time step, but one of a 700 config wouldn't, and having some specific object other than global variables in libconcord.cpp would be a good idea. I totally buy your argument that update_configuration should reset and set time. In practice, users can press CTRL-C while running any application, or click the cancel button in congruity (which will abort between libconcord API calls right now), or just unplug their remote. In this case, the worst that should happen is the remote booting into safe mode and needing another firmware or configuration update attempt. Sure, but then you KNOW your breaking out of a program in the middle, as opposed to a nice cancel button that implies a nicer cancel. No? I'm not sure if the distinction is that obvious to end-users? congruity has had a cancel option since the beginning IIRC (personally I find apps that can't cancel very annoying), and I don't recall any reports of users screwing themselves with it; -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] API feedback wanted: Supporting zwave remotes
Sorry for top-posting, but I'm making a general response rather than to individual points. So, I don't think it'd be that hard for congruity to support any of the API designs below, including different paths for different remote architectures all determined at run-time. However, I'd prefer a single unified API. My reasoning is this: congruity/concordance's purpose is to provide a pretty UI over libconcord, and not to implement knowledge of how to program the different remotes; such abstraction (whether it be a unified API, or even just a database that maps from arch to a list of required operations by the UI application) belongs in libconcord, since that's where all other knowledge re: remote programming is. From my perspective, I think the perfect API would be a single top-level API to do each of: 1) Identify/parse any update/... file 1a) A function to load/parse/... the file 1b) Function(s) to query any information about the parsed file (e.g. what type of operation is being performed, so this information can be presented to the user) 1c) Function(s) to query the number and type of steps required to implement the operation. 2) A single function to perform the entire operation (or perhaps a single function per type of operation) This would completely internalize all knowledge of file-formats, operations, which remotes exist, set of steps required to implement the operations, etc. The callback from step 2 would need to be enhanced to include a step ID as well as percentage or byte-count, in order to match with the data returned by function(s) in 1c above. I propose this also because I see that some of the operations have XML files that can (and do) list multiple regions to be updated. Thus, the set of operations to be executed is not only driven by remote architecture, but also by update/... file content. Currently, the API is structured to only handle a single contiguous region that must be erased and written. With the above API, any changes to support N regions would be entirely internal to libconcord, and an application would simply see extra entries in the step list; something at least congruity could easily adapt to. Perhaps something like what's below (names need more though; this is just a rough outline): struct ParsedOperationFile enum OperationType Connectivity UpdateConfiguration UpdateFirmware LearnIR enum StepType InitialWebPing PrepareForUpdate EraseRegion WriteRegion VerifyRegion FinalizeUpdate Reset ReconnectToRemote SetTime // e.g. yes for 880 no for 700 FinalWebPing ... enum StepStatus Starting Executing Complete_Success Failure Status Callback(ParsedOperationFile *pof, void *cbcontext, uint32 step, StepStatus step_status, uint complete_count, uint target_count) ParsedOperationFile *load_file(char *filename) void destroy_file(ParsedOperationFile *pof) OperationType pof_type(ParsedOperationFile *pof) uint pof_step_count(ParsedOperationFile *pof) StepType pof_step_type(ParsedOperationFile *pof, uint step) // e.g. region ID for erase/write/verify, which can be added // to (or interpolated into printf-style) step labels in the UI ??? pof_step_parameters(ParsedOperationFile *pof, uint step, // ???: enum parameter_type, uint parameter_id) // or update_config_execute, update_firmware_execute, ...? Status pof_execute(ParsedOperationFile *pof, Callback *cb, void *context) ? pof_get_failure_information(ParsedOperationFile *pof, ...?) congruity would use pof_step_* to create the UI widgets when entering e.g. the update configuration page, then whenever a callback was executed, map from step number to UI widget, and update the percentage completion bar. Perhaps extra APIs to determine if a step's completion level is Kb, percent, ... Perhaps pof_step_parameters would return both data that forms part of a UI label for the step, and other metadata like this? Or, perhaps have specific functions for specific step types. The callback could return Continue/Abort to allow implementation of a cancel button in a UI. How does that sound? On 08/26/2010 12:50 PM, Phil Dibowitz wrote: OK all, [ Stephen, as the primary user of the libconcord API, I'm particularly looking for input here from you ] I now have fully functioning 89x support for config updates, connectivity tests, and web communication. (No work yet on firmware or learn-ir). The current libconcord API was designed very much around the HID remotes, and so a config update in 0.22 looks like: prep_config() invalidate_flash() erase_config() write_config_to_remote() verify_remote_config() finish_config() reset_remote() [... reconnect] set_time() The ZWave remotes don't expose the low levels that the HID remotes do. There's no flash addresses to worry about, or even manual invalidation and erasing. It looks like this: write_config_to_remote()
Re: [concordance-devel] libconcord.py 0.22 looks for missing libconcord.so.2
On 08/12/2010 10:16 AM, Phil Dibowitz wrote: On Thu, Aug 12, 2010 at 04:55:25PM +0100, Chris Mayo wrote: In 0.22 libconcord.py sets: ABI_VERSION = 2 causing it to look for libconcord.so.2 Crap. That should have gone 0 - 1, not 0 - 2. I have to release a 0.23 this weekend anyway, I'll fix that. I think it was originally 1 not 0. I don't think this value should have been changed at all, since when I build latest CVS, the link command includes: -Wl,-soname -Wl,libconcord.so.1 -o .libs/libconcord.so.1.1.0 ... and the Python bindings should be looking for the soname. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Rolling a version 0.22, zwave support, etc.
Stephen Warren wrote: Well, there's a small build problem on Windows, since I forgot to add the new APIs to the DLL export file; see attached patch. (Hopefully this applies OK, since I generated it using Cygwin; perhaps the line-endings are broken, but it should be obvious-enough to apply manually). Phil, did you miss this patch? With that fix in place, I tried a config update under XP. The first time, the verify failed, but the second time it worked fine. Perhaps that's the same kind of timing issue as under Linux. I also tried all the other supported actions on the 700. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] [PATCH] Fix ArchList typos
On 08/01/2010 08:37 AM, Phil Dibowitz wrote: On 08/01/2010 05:39 AM, Stephen Warren wrote: Attached is a patch to fix this. I must have confused a couple different lines when reformatting the ArchList... It's a good thing this happened on a remote we have for testing! Yeah. One of the things I'd really like to do one day is use gunittest and gmock to add full unittesting. But doing that is a pretty significant project to mock out all the remote responses properly... Long ago, I actually started work on a library with libusb's API that emulated a Harmony 880. I don't recall how far I got... -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Rolling a version 0.22, zwave support, etc.
Phil Dibowitz wrote: On 08/01/2010 08:44 PM, Stephen Warren wrote: On 08/01/2010 08:38 AM, Phil Dibowitz wrote: On 08/01/2010 04:27 AM, Stephen Warren wrote: Oh, perhaps we should add a note in the libconcord README re: needing a kernel patch to get the 700 working? Have we tested it in Windows? No, I haven't. Obviously I haven't held the release for it, but it'd be good to test... Well, there's a small build problem on Windows, since I forgot to add the new APIs to the DLL export file; see attached patch. (Hopefully this applies OK, since I generated it using Cygwin; perhaps the line-endings are broken, but it should be obvious-enough to apply manually). With that fix in place, I tried a config update under XP. The first time, the verify failed, but the second time it worked fine. Perhaps that's the same kind of timing issue as under Linux. I also tried all the other supported actions on the 700. ? concordance/win/Debug ? consnoop/win/Debug ? libconcord/win/Debug ? libconcord/win/libconcord_winhid.ncb ? libconcord/win/libconcord_winhid.sln ? libconcord/win/libconcord_winhid.suo ? libconcord/win/libconcord_winhid.vcproj.ESK.Stephen Warren.user ? win/concordance.ncb Index: libconcord/win/libconcord.def === RCS file: /cvsroot/concordance/concordance/libconcord/win/libconcord.def,v retrieving revision 1.9 diff -u -p -r1.9 libconcord.def --- libconcord/win/libconcord.def 12 Oct 2008 22:35:26 - 1.9 +++ libconcord/win/libconcord.def 2 Aug 2010 01:36:04 - @@ -70,6 +70,8 @@ read_config_from_remote write_config_to_remote write_config_to_file verify_remote_config +prep_config +finish_config erase_config find_config_binary -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] [ANNOUNCE] congruity-15 released
* 2010-08-01 Stephen Warren s-t-concorda...@wwwdotorg.org - congruity-15 is released - Call new APIs in libconcord-0.22, for Harmony 700 support. - Tweak WrappedStaticText.UpdateText again, so it shows all text and doesn't wrap it strangely, at least with Lucids's wxpython 2.8.10.1-0ubuntu1. https://sourceforge.net/projects/congruity/ https://sourceforge.net/downloads/congruity/congruity/15/ -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Rolling a version 0.22, zwave support, etc.
On 07/29/2010 05:14 PM, Stephen Warren wrote: On 07/29/2010 02:35 PM, Phil Dibowitz wrote: All, As I'm starting to code up 89x support I realize I'm likely going to have to make more significant breakages to the API than the 700 made... So my plan at this point is to prep an 0.22 release, and get that out, hopefully this weekend, and then make a branch in CVS to start working on the zwave remotes. Things left: * I have some cleanups to the concordance output still pending * Cleanup the Changelog * Update the so-numbers appropriately for libconcord * Usual release stuff: version number changes, cvs tag, etc. Anyone object to this plan (Stephen, since you release software that depends on libconcord, I'm looking at you)? That sounds fine to me; I just have to bump a rev number and create a tar once you've released. Actually, I could even release a compatible version first:-) Oh, perhaps we should add a note in the libconcord README re: needing a kernel patch to get the 700 working? -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] [PATCH] Harmony 700 support
On 07/31/2010 08:01 AM, Phil Dibowitz wrote: Stephen, You're 700 patch breaks config dumps - at least for the 880, but I would guess for all remotes. ... #8 0xb7e1917d in operator new[](unsigned int) () from /usr/lib/libstdc++.so.6 #9 0xb7fbdb52 in read_config_from_remote (out=0xbc00, size=0xbbfc, cb=0x804b3a0cb_print_percent_status, cb_arg=0x1) at libconcord.cpp:796 #10 0x0804b34f in dump_config (options=0xbc30, file_name=0xbe3e /tmp/tout, cb=0x804b3a0cb_print_percent_status, cb_arg=0x0) at concordance.c:414 #11 0x0804bdfb in main (argc=Cannot access memory at address 0x317d ) at concordance.c:1295 The failing code in frame 8 is: *size = ri.config_bytes_used; *out = new uint8_t[*size]; but *size == 0xfffe08f7, way too large. This is calculated in CRemote::GetIdentity(). I suspect I botched the remote_info ArchList[] table that's used in those calculations when I reformatted it. I'll double-check all the values and fix this tonight... -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] [PATCH] Fix ArchList typos
On 07/31/2010 08:35 PM, Stephen Warren wrote:
On 07/31/2010 08:01 AM, Phil Dibowitz wrote:
Stephen,
You're 700 patch breaks config dumps - at least for the 880, but I would
guess for all remotes.
...
#8 0xb7e1917d in operator new[](unsigned int) () from /usr/lib/libstdc++.so.6
#9 0xb7fbdb52 in read_config_from_remote (out=0xbc00, size=0xbbfc,
cb=0x804b3a0cb_print_percent_status, cb_arg=0x1) at libconcord.cpp:796
#10 0x0804b34f in dump_config (options=0xbc30,
file_name=0xbe3e /tmp/tout, cb=0x804b3a0cb_print_percent_status,
cb_arg=0x0) at concordance.c:414
#11 0x0804bdfb in main (argc=Cannot access memory at address 0x317d
) at concordance.c:1295
The failing code in frame 8 is:
*size = ri.config_bytes_used;
*out = new uint8_t[*size];
but *size == 0xfffe08f7, way too large. This is calculated in
CRemote::GetIdentity(). I suspect I botched the remote_info ArchList[]
table that's used in those calculations when I reformatted it. I'll
double-check all the values and fix this tonight...
Attached is a patch to fix this. I must have confused a couple different
lines when reformatting the ArchList... It's a good thing this happened
on a remote we have for testing!
I've now tested all available operations on 880, and everything except
firmware update on 700.
libconcord/remote_info.h
- Fix typos in ArchList caused during recent reformatting.
Signed-Off-By: Stephen Warren swar...@wwwdotorg.org
? concordance/.deps
? concordance/.libs
? concordance/Makefile
? concordance/Makefile.in
? concordance/aclocal.m4
? concordance/autom4te.cache
? concordance/concordance
? concordance/config.h
? concordance/config.h.in
? concordance/config.log
? concordance/config.status
? concordance/configure
? concordance/libtool
? concordance/ltmain.sh
? concordance/stamp-h1
? consnoop/consnoop
? libconcord/.deps
? libconcord/.libconcord.cpp.swp
? libconcord/.libs
? libconcord/.remote.cpp.swp
? libconcord/.remote_info.h.swp
? libconcord/Makefile
? libconcord/Makefile.in
? libconcord/aclocal.m4
? libconcord/autom4te.cache
? libconcord/binaryfile.lo
? libconcord/config.guess
? libconcord/config.h
? libconcord/config.h.in
? libconcord/config.log
? libconcord/config.status
? libconcord/config.sub
? libconcord/configure
? libconcord/depcomp
? libconcord/install-sh
? libconcord/libconcord.la
? libconcord/libconcord.lo
? libconcord/libtool
? libconcord/libusbhid.lo
? libconcord/ltmain.sh
? libconcord/missing
? libconcord/remote.lo
? libconcord/remote_z.lo
? libconcord/stamp-h1
? libconcord/usblan.lo
? libconcord/web.lo
? libconcord/bindings/perl/Makefile
? libconcord/bindings/perl/blib
? libconcord/bindings/perl/concord.bs
? libconcord/bindings/perl/concord.pm
? libconcord/bindings/perl/concord_wrap.c
? libconcord/bindings/perl/pm_to_blib
? libconcord/bindings/python/libconcord.pyc
Index: libconcord/remote_info.h
===
RCS file: /cvsroot/concordance/concordance/libconcord/remote_info.h,v
retrieving revision 1.11
diff -u -p -r1.11 remote_info.h
--- libconcord/remote_info.h27 Jul 2010 19:33:53 - 1.11
+++ libconcord/remote_info.h1 Aug 2010 03:35:25 -
@@ -299,10 +299,10 @@ static const TArchInfo ArchList[]={
0x01, // firmware_base
0x02, // config_base
0x1D, // firmware_update_base
- 2, // firmware_4847_offset
+ 4, // firmware_4847_offset
0x50545054, // cookie
4, // cookie_size
- 5, // end_vector
+ 4, // end_vector
PIC18LC801, // micro
0, // flash_size
1536, // ram_size
@@ -317,12 +317,12 @@ static const TArchInfo ArchList[]={
0x81, // firmware_base
0x82, // config_base
0x81, // firmware_update_base
- 2, // firmware_4847_offset
+ 4, // firmware_4847_offset
0x4D434841, // cookie
4, // cookie_size
4, // end_vector
PIC18LF4550, // micro
- 0, // flash_size
+ 16, // flash_size
2048, // ram_size
256,// eeprom_size
Internal, // usb
Re: [concordance-devel] Rolling a version 0.22, zwave support, etc.
On 07/29/2010 02:35 PM, Phil Dibowitz wrote: All, As I'm starting to code up 89x support I realize I'm likely going to have to make more significant breakages to the API than the 700 made... So my plan at this point is to prep an 0.22 release, and get that out, hopefully this weekend, and then make a branch in CVS to start working on the zwave remotes. Things left: * I have some cleanups to the concordance output still pending * Cleanup the Changelog * Update the so-numbers appropriately for libconcord * Usual release stuff: version number changes, cvs tag, etc. Anyone object to this plan (Stephen, since you release software that depends on libconcord, I'm looking at you)? That sounds fine to me; I just have to bump a rev number and create a tar once you've released. Actually, I could even release a compatible version first:-) -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] [PATCH] Harmony 700 support
On 07/27/2010 01:44 PM, Phil Dibowitz wrote: I've also updated the website's supported-models page to list the arch of the 700, link to the bug, and say it's supported in CVS. Out of curiosity, have you looked into firmware support at all? I did a little. From the protocol side, I think there were a few minor differences of similar order of magnitude to the changes required for configuration support; a couple of small extra messages that I think had static content. The hard part is that there are multiple disjoint regions of firmware that must be updated, so the firmware parsing API would have to be updated to represent this. Worse and following on from that, the format of the firmware file is much more complex; it's a zip file containing a top-level XML description file and a separate file for each region to be updated, or something like that. Still, it's probably within possibility to get working, it'll just require API and application changes etc. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] [PATCH] Harmony 700 support
On 07/26/2010 01:04 PM, Phil Dibowitz wrote:
On Sat, Jul 24, 2010 at 07:58:27PM -0600, Stephen Warren wrote:
OK. I added the prep_config/finish_config to test.pl and validated that
this works on the 700. Updated version is attached.
Thanks!
I did a more thorough look through the code this time. There's only one thing,
which I've put below.
BTW - Greg accepted the kernel patch, it'll merge into Linus' tree at the next
merge window.
Index: libconcord/remote.cpp
===
RCS file: /cvsroot/concordance/concordance/libconcord/remote.cpp,v
retrieving revision 1.39
diff -u -p -r1.39 remote.cpp
--- libconcord/remote.cpp11 Feb 2009 20:00:13 - 1.39
+++ libconcord/remote.cpp25 Jul 2010 01:55:19 -
@@ -103,7 +103,7 @@ int CRemote::GetIdentity(TRemoteInfori
const unsigned int rx_len = rsp[0] 0x0F;
if ((rsp[0] 0xF0) != RESPONSE_VERSION_DATA ||
-(rx_len != 7 rx_len != 5)) {
+(rx_len != 5 rx_len != 7 rx_len != 8)) {
debug(Bogus ident response: %02X, rsp[1]);
return LC_ERROR_INVALID_DATA_FROM_REMOTE;
}
@@ -117,7 +117,13 @@ int CRemote::GetIdentity(TRemoteInfori
ri.architecture = rx_len 6 ? 2 : rsp[5] 4;
ri.fw_type = rx_len 6 ? 0 : rsp[5] 0x0F;
ri.skin = rx_len 6 ? 2 : rsp[6];
-ri.protocol = rx_len 7 ? 0 : rsp[7];
+if (rx_len 7) {
+ri.protocol = 0;
+} else if (rx_len 8) {
+ri.protocol = rsp[7];
+} else {
+ri.protocol = ri.architecture;
+}
Wait, this doesn't seem right. protocol is a binary field which either says to
use one rxlenmap or another, and also to determine if the max_chunk_len for
reading flash is 700 or 1022. So in the case of the 700 your making it 14,
which
will have the same effect as '1', but isn't quite what we want either.
Am I completely missing something here?
Yes, this is a little odd. However, IIRC, this matches what the official
software prints. Or perhaps it doesn't print the value, but some field
in the HTTP responses is the value of ri.protocol at least in
libconcord, and the offical software sends 14 here. I don't think the
value of ri.protocol is solely 0 or 1 on existing remotes?
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] [PATCH] Harmony 700 support
On 07/24/2010 12:50 AM, Phil Dibowitz wrote:
On Fri, Jul 23, 2010 at 09:41:14PM -0600, Stephen Warren wrote:
On 07/23/2010 12:40 PM, Phil Dibowitz wrote:
On Thu, Jul 22, 2010 at 07:18:50PM -0600, Stephen Warren wrote:
Oh, and I added the new functions to the Python bindings too, which I
forgot before.
Cool. Can you either (1) do the same for the perl bindings or (2) create a bug
(and assign it to me) to do it?
Um, do the Perl bindings work at all? I don't see any implementation of
pretty much any libconcord functionality. Perhaps swig automatically
parses libconcord.h and auto-generates the functions? If so, I guess
it'll just work for the new functions, just like it does for the
existing similar functions?
It reads libconcord.h to generate every function, and there's a lot of
overrides and custom handling in concord.i.
However, in this case test.pl needs to be updated for the new firmware changes
you did, plus make sure it works for the 700 (it needs to call prep/post
update and make sure the swig bindings work correctly and no additional
overrides are needed).
OK. I added the prep_config/finish_config to test.pl and validated that
this works on the 700. Updated version is attached.
? install
? concordance/.deps
? concordance/.libs
? concordance/Makefile
? concordance/Makefile.in
? concordance/aclocal.m4
? concordance/autom4te.cache
? concordance/concordance
? concordance/config.h
? concordance/config.h.in
? concordance/config.log
? concordance/config.status
? concordance/configure
? concordance/libtool
? concordance/ltmain.sh
? concordance/stamp-h1
? consnoop/consnoop
? libconcord/.deps
? libconcord/.libconcord.h.swp
? libconcord/.libs
? libconcord/Makefile
? libconcord/Makefile.in
? libconcord/aclocal.m4
? libconcord/autom4te.cache
? libconcord/binaryfile.lo
? libconcord/config.guess
? libconcord/config.h
? libconcord/config.h.in
? libconcord/config.log
? libconcord/config.status
? libconcord/config.sub
? libconcord/configure
? libconcord/depcomp
? libconcord/install-sh
? libconcord/libconcord.la
? libconcord/libconcord.lo
? libconcord/libtool
? libconcord/libusbhid.lo
? libconcord/ltmain.sh
? libconcord/missing
? libconcord/remote.lo
? libconcord/remote_z.lo
? libconcord/stamp-h1
? libconcord/usblan.lo
? libconcord/web.lo
? libconcord/bindings/perl/.concord.pm.swp
? libconcord/bindings/perl/.test.pl.swp
? libconcord/bindings/perl/Makefile
? libconcord/bindings/perl/blib
? libconcord/bindings/perl/concord.bs
? libconcord/bindings/perl/concord.pm
? libconcord/bindings/perl/concord_wrap.c
? libconcord/bindings/perl/pm_to_blib
? libconcord/bindings/python/libconcord.pyc
Index: concordance/concordance.c
===
RCS file: /cvsroot/concordance/concordance/concordance/concordance.c,v
retrieving revision 1.39
diff -u -p -r1.39 concordance.c
--- concordance/concordance.c 5 Jul 2009 13:46:56 - 1.39
+++ concordance/concordance.c 25 Jul 2010 01:55:19 -
@@ -467,6 +467,11 @@ int upload_config(uint8_t *data, uint32_
post_preconfig(data, size);
}
+ printf(Preparing Update:);
+ if ((err = prep_config())) {
+ return err;
+ }
+ printf( done\n);
/*
* We must invalidate flash before we erase and write so that
* nothing will attempt to reference it while we're working.
@@ -500,6 +505,12 @@ int upload_config(uint8_t *data, uint32_
}
printf( done\n);
+ printf(Finalizing Update: );
+ if ((err = finish_config())) {
+ return err;
+ }
+ printf( done\n);
+
if ((*options).noreset) {
return 0;
}
Index: libconcord/libconcord.cpp
===
RCS file: /cvsroot/concordance/concordance/libconcord/libconcord.cpp,v
retrieving revision 1.41
diff -u -p -r1.41 libconcord.cpp
--- libconcord/libconcord.cpp 20 May 2009 19:46:09 - 1.41
+++ libconcord/libconcord.cpp 25 Jul 2010 01:55:19 -
@@ -880,6 +880,28 @@ int verify_remote_config(uint8_t *in, ui
return 0;
}
+int prep_config()
+{
+ int err = 0;
+
+ if ((err = rmt-PrepConfig(ri))) {
+ return LC_ERROR;
+ }
+
+ return 0;
+}
+
+int finish_config()
+{
+ int err = 0;
+
+ if ((err = rmt-FinishConfig(ri))) {
+ return LC_ERROR;
+ }
+
+ return 0;
+}
+
int erase_config(uint32_t size, lc_callback cb, void *cb_arg)
{
int err = 0;
@@ -1023,34 +1045,9 @@ int is_config_safe_after_fw()
int prep_firmware()
{
int err = 0;
- uint8_t data[1];
- if (ri.arch-firmware_update_base == ri.arch-firmware_base) {
- /*
-* The preperation for where the staging area IS the config
-* area.
-*restart config
-*write 1 to flash
Re: [concordance-devel] [PATCH] Harmony 700 support
On 07/23/2010 12:40 PM, Phil Dibowitz wrote: On Thu, Jul 22, 2010 at 07:18:50PM -0600, Stephen Warren wrote: Oh, and I added the new functions to the Python bindings too, which I forgot before. Cool. Can you either (1) do the same for the perl bindings or (2) create a bug (and assign it to me) to do it? Um, do the Perl bindings work at all? I don't see any implementation of pretty much any libconcord functionality. Perhaps swig automatically parses libconcord.h and auto-generates the functions? If so, I guess it'll just work for the new functions, just like it does for the existing similar functions? If I'm way off base, I'll happily go file a bug... -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] [PATCH] Harmony 700 support
Attached is a patch to support the Harmony 700.
Signed-Off-By: Stephen Warren swar...@wwwdotorg.org
Note: The new prep_config/finish_config functions are technically
required to match the Windows software. However, during my testing, I
forgot to update congruity to call those functions, and everything
worked as expected. Should I just rip those new functions out? That
would significantly reduce the size of the patch, and remove the need to
release a new congruity version too.
I've tested the following from congruity using downloads from the website:
* Check connectivity
* Update configuration
* Learn IR
? install
? concordance/.deps
? concordance/.libs
? concordance/Makefile
? concordance/Makefile.in
? concordance/aclocal.m4
? concordance/autom4te.cache
? concordance/concordance
? concordance/config.h
? concordance/config.h.in
? concordance/config.log
? concordance/config.status
? concordance/configure
? concordance/libtool
? concordance/ltmain.sh
? concordance/stamp-h1
? consnoop/consnoop
? libconcord/.deps
? libconcord/.libconcord.cpp.swp
? libconcord/.libs
? libconcord/.remote.cpp.swp
? libconcord/.remote.h.swp
? libconcord/.remote_info.h.swp
? libconcord/Makefile
? libconcord/Makefile.in
? libconcord/aclocal.m4
? libconcord/autom4te.cache
? libconcord/binaryfile.lo
? libconcord/config.guess
? libconcord/config.h
? libconcord/config.h.in
? libconcord/config.log
? libconcord/config.status
? libconcord/config.sub
? libconcord/configure
? libconcord/depcomp
? libconcord/install-sh
? libconcord/libconcord.la
? libconcord/libconcord.lo
? libconcord/libtool
? libconcord/libusbhid.lo
? libconcord/ltmain.sh
? libconcord/missing
? libconcord/remote.lo
? libconcord/remote_z.lo
? libconcord/stamp-h1
? libconcord/usblan.lo
? libconcord/web.lo
? libconcord/bindings/python/libconcord.pyc
Index: concordance/concordance.c
===
RCS file: /cvsroot/concordance/concordance/concordance/concordance.c,v
retrieving revision 1.39
diff -u -p -r1.39 concordance.c
--- concordance/concordance.c 5 Jul 2009 13:46:56 - 1.39
+++ concordance/concordance.c 22 Jul 2010 01:26:12 -
@@ -467,6 +467,11 @@ int upload_config(uint8_t *data, uint32_
post_preconfig(data, size);
}
+ printf(Preparing Update:);
+ if ((err = prep_config())) {
+ return err;
+ }
+ printf( done\n);
/*
* We must invalidate flash before we erase and write so that
* nothing will attempt to reference it while we're working.
@@ -500,6 +505,12 @@ int upload_config(uint8_t *data, uint32_
}
printf( done\n);
+ printf(Finalizing Update: );
+ if ((err = finish_config())) {
+ return err;
+ }
+ printf( done\n);
+
if ((*options).noreset) {
return 0;
}
Index: libconcord/libconcord.cpp
===
RCS file: /cvsroot/concordance/concordance/libconcord/libconcord.cpp,v
retrieving revision 1.41
diff -u -p -r1.41 libconcord.cpp
--- libconcord/libconcord.cpp 20 May 2009 19:46:09 - 1.41
+++ libconcord/libconcord.cpp 22 Jul 2010 01:26:12 -
@@ -880,6 +880,36 @@ int verify_remote_config(uint8_t *in, ui
return 0;
}
+int prep_config()
+{
+ int err = 0;
+
+ if (ri.architecture != 14) {
+ return 0;
+ }
+
+ if ((err = rmt-PrepConfig())) {
+ return LC_ERROR;
+ }
+
+ return 0;
+}
+
+int finish_config()
+{
+ int err = 0;
+
+ if (ri.architecture != 14) {
+ return 0;
+ }
+
+ if ((err = rmt-FinishConfig())) {
+ return LC_ERROR;
+ }
+
+ return 0;
+}
+
int erase_config(uint32_t size, lc_callback cb, void *cb_arg)
{
int err = 0;
Index: libconcord/libconcord.h
===
RCS file: /cvsroot/concordance/concordance/libconcord/libconcord.h,v
retrieving revision 1.21
diff -u -p -r1.21 libconcord.h
--- libconcord/libconcord.h 14 Oct 2008 19:35:01 - 1.21
+++ libconcord/libconcord.h 22 Jul 2010 01:26:12 -
@@ -275,6 +275,15 @@ int write_config_to_file(uint8_t *in, ui
int verify_remote_config(uint8_t *in, uint32_t size, lc_callback cb,
void *cb_arg);
/*
+ * Preps the remote for a config upgrade
+ */
+int prep_config();
+/*
+ * Tells the remote the config upgrade was successful and that it should
+ * use the new config upon next reboot.
+ */
+int finish_config();
+/*
* Flash can be changed to 0, but not back to 1, so you must erase the
* flash (to 1) in order to write the flash.
*/
Index: libconcord/remote.cpp
===
RCS file: /cvsroot/concordance/concordance/libconcord/remote.cpp,v
retrieving revision 1.39
diff -u -p -r1.39
[concordance-devel] [PATCH] Fix error-checking in Python bindings
While testing out Harmony 770 support, I found a bug in the Python
bindings' error checking of a couple functions that return something
other than a libconcord return code.
Signed-Off-By: Stephen Warren swar...@wwwdotorg.org
Index: bindings/python/libconcord.py
===
RCS file:
/cvsroot/concordance/concordance/libconcord/bindings/python/libconcord.py,v
retrieving revision 1.6
diff -u -p -r1.6 libconcord.py
--- bindings/python/libconcord.py 8 Mar 2009 18:52:41 - 1.6
+++ bindings/python/libconcord.py 23 Jun 2010 02:14:02 -
@@ -687,14 +687,14 @@ write_safemode_to_file = _create_func(
# int is_fw_update_supported(int direct);
is_fw_update_supported = _create_func(
'is_fw_update_supported',
-_ret_lc_concord(),
+c_int,
_in('direct', c_int)
)
# int is_config_safe_after_fw();
is_config_safe_after_fw = _create_func(
'is_config_safe_after_fw',
-_ret_lc_concord()
+c_int
)
# int prep_firmware();
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Harmony 700 Support
On 06/06/2010 04:55 AM, Phil Dibowitz wrote: On 06/05/2010 09:44 PM, SourceForge.net wrote: Here's the status: Thanks for updating the bug, and for all the work, Stephen. I'm responding to the list and not the bug since this is just discussion and note an update. A few thoughts: 1. Have you seen the remote successfully work in Windows, using the official software? Since you bought it on ebay, I'm starting to wonder if perhaps the device is damaged/faulty? Yes, it works just fine there. 2. I have another theory, regarding timing, I'll throw out on the linux-usb thread you started... Yeah, I should try out that sleep etc. sometime... -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Logitech Harmony 700
On 03/30/2010 09:02 PM, Stephen Warren wrote: So, I've taken a look at the Harmony 700 logs, and overall it looks basically similar to other remotes. However, there are definitely some differences that will take some work. I got a 700 today via eBay. By correlating some stuff against the HTTP traffic, here are a few more details: Harmony 700 GET_VERSION response 28 GET_VERSION response, length 8 25 Firmware version 2.5 (Region 2 version) # 22 in safe mode on SRW's remote; region 0/1 version? 00 HW version 0.0 1C Flash ID (FW returns these swapped relative to CFI/JEDEC protocol) 15 Flash Manufacturer E0 Architecture (and protocol) 14, fw_type 0 (0=normal, 4=safe mode) 42 Skin 0C ?? Should be protocol, but Logitech's SW reports 14 (0xE) for protocol; is it just using arch instead? 23 Region 0 or 1 version 2.3?? # 22 on SRW's remote; just an earlier version?? i.e. basically the same as the 880, except: * Don't know what the 0C byte is; perhaps it is protocol and the Logitech SW is buggy and sending architecture in the HTTP commands instead. * One extra byte returned; probably safe mode FW version or something like that. The flash chip is from EON. I can't find the exact model, but this is what's printed on it, and what I could find from Googling: cFeon F16-100HIP Q93F03D 20CDA --- 32Mbit serial flash memory w/ 4KB uniform sector (0x1 isn't 4KB; either the firmware fakes this, or there are multiple flash chips with the same ID and different sector sizes. I'd bet on the FW myself) http://www.essi.com.tw/products/products.aspx EN25F32/EN25Q32A p2009121811192.pdf I've decoded most of the information for remote_info.h. The firmware downloads are a zip containing: Data.xml: XML file listing which other files to process in which order, and the parameters for the done web post. Region_2.EZUpgrade: The actual FW data, in the same format as e.g. for the 880, with the exceptions: a) Doesn't include HTTP parameters since they're in Data.xml b) Includes two sets of data to write; a static configuration and a firmware, the latter being the only thing we'd normally expect on other remotes. Oh, and it looks like the firmware block already has the checksum as 4847 bytes written into it unlike other remotes. Maybe that was a server-side update; I should check my 880 and see... More to come once I've hacked libconcord to do the different/new pre-/post-update commands and actually attempted some write operations. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Logitech Harmony 700
So, I've taken a look at the Harmony 700 logs, and overall it looks basically similar to other remotes. However, there are definitely some differences that will take some work. To decode some more, it'd be useful if we could capture a complete trace of the HTTP traffic between Logitech's software and their web-server, and also the download files that it pushes to the client to execute. You'd have to install some kind of network sniffer (e.g. wireshark) to capture the former. To capture the download files, you'd need to use a web-browser to access http://members.harmonyremote.com/, and force the browser to save the files instead of automatically opening them with the Logitech software (there should be a separate file for identifying the remote, updating configuration, updating firmware). There are some fields in the HTTP responses that libconcord generates that need to be tallied back to fields in the GET_VERSION response, and flash/eeprom/... reads. That's why we need the HTTP dump (note: this dump will include your Harmony user ID and password). Also, since the 700 firmware updates appears to have two separate regions, we'd need to take a look at the config file that the website pushes (may also include your user ID/password) to work out how to extract the two sections of firmware. As far as supporting the 700: a) We could probably force any GET_VERSION response with length 8 to be the 700 for now. b) We need to add new entry points to libconcord for pre-/post- configuration update to send the new restart config commands. c) We need to somehow expand the firmware APIs to be able to erase and program two separate sections. Perhaps the remote will work OK if we erase both sections then program both sections. That would allow this to be implemented without any API changes by hiding more complex blobs behind the APIs (list of data blobs instead of a single data blob). However, if the order *has* to be erase, write, erase, write, then we'd need to modify the libconcord API to allow the client application to specifically iterate through the sections that need to be programmed. (I wonder if I should get a 700 from eBay/Amazon; this will probably need some iterative tweaking to get it working) I include some notes on the protocol comparisons against an 880 below: Harmony 700 GET_VERSION response 28 GET_VERSION response, length 8 25 Firmware version 2.5 (Region 2 version) 00 ?? Board version 0.0.0 1C HW version 0x15:1c 15 HW version 0x15:1c E0 ?? 42 ?? 0C ?? 23 Region 0 or 1 version 2.3?? Harmony 880 GET_VERSION response 27 GET_VERSION response, length 7 40 Firmware version 4.0 18 HW version 1.8 49 Flash ID 01 Flash manufacturer 80 Architecture 8, fw_type 0 0F Skin 08 Protocol Harmony 700 Update Config Write Restart Config 02 02 * NEW; no command here on 880 A3 0A 09 00 Write Restart Config 05 00 * NEW; no command here on 880 A3 0A 05 00 Write Invalidate Flash Erase Flash 03..10 Write Flash 03..end Erase Flash 1E..1F * SKIPPED by libconcord on 880 Write Restart Config 03 01 * NEW; no command here on 880 A3 0A 03 01 Write Restart Config 06 00 * NEW; no command here on 880 A3 0A 06 00 Reset Device (02) Harmony 880 Update Config Write Invalidate Flash Erase Flash 02..0C Write Flash 02..end Erase Flash 1E..1F * Skipped by libconcord on 880 Reset Device (02) Harmony 700 Firmware Write Unknown * CHANGED; different command to 880 A1 0B Erase Flash 02 * NEW; multiple regions Write Flash 02..end* NEW; multiple regions Erase Flash 00..01 Write Flash 00..end Write RAM 00 02 Read RAM 00 Reset Device (02) Harmony 880 Firmware Write RAM 00 00 A3 06 00 00 Read RAM 00 Write Invalidate Flash Erase Flash 1D Write Flash 1D..end Write RAM 00 02 Read RAM 00 Reset Device (02) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Logitech Harmony 700
Phil Dibowitz wrote: For those following along at home... I had a small bit of time to look into this this week. The 700's response to GET_IDENTITY is completely different. And honestly, I don't have the time to pull it apart, at least for the next couple of weeks. The short of it is, that we expect the length to be 7 or 5, and can parse it accordingly. But these remotes' response' length is 8.. and I was rather hoping it was just another random byte we didn't care about, but that's not the case. I also tried forcing it to 5 and parsing it that way - both just quick hacks because I didn't have time to actually pull it apart. Not surprisingly, neither worked, Stephen or Kevin - Chris Mayo has been kind enough to provide SnoopyPro dumps if either of you have time. Let him or I know, and one of us will forward the logs into you. Yes, I should finally get around to looking at this; please do forward me the logs. Also, any information you can extract from the original SW would be useful (FW version, maybe it has some advanced information page or log file; I don't recall). Perhaps you have the firmware upgrade file saved somewhere? There's enough 'knowns', it shouldn't be _that_ hard. He can probably tell you his firmware version, for example, which we could then find - it's only 8 bytes. I hope. ;) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] congruity uploaded to Debian (Fwd: congruity_13+dfsg-1_amd64.changes ACCEPTED)
Mathieu Trudel-Lapierre wrote: Stephen, I think in principle I agreed, but was still waiting on a higher-res or modified image or something? That's very possible, I'm kind of bad at following up... And looking back at the thread, it's indeed what the issue was. I've attached the scaled + cropped image, as it is in the debian upload; where as I said it's not *exactly* the same size because I wanted to retain aspect ratio, but it's very close. Mathieu, I forgot to mention, a couple days back, I released congruity-14 that includes your image. Thanks very much. Sorry it took so long to get around to this. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] congruity uploaded to Debian (Fwd: congruity_13+dfsg-1_amd64.changes ACCEPTED)
Phil Dibowitz wrote: On Fri, Nov 20, 2009 at 01:31:32PM -0500, Mathieu Trudel-Lapierre wrote: Note, it's a -dfsg upload because I replaced the remote.png image with one I took of my own Harmony 670, scaled and cropped to a similar size, to be able to upload with no license issues. Perhaps the file I used could be used instead of the current one in the tarballs, so that future uploads don't require this mod? I released that file under the GPL-3, and I will be happy to send it by email to someone for it to be added to SVN, for example. That ones up to Stephan... I think in principle I agreed, but was still waiting on a higher-res or modified image or something? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Licensing issue for congruity's remote.png
Mathieu Trudel wrote: Le dimanche 11 octobre 2009 à 23:56 -0600, Stephen Warren a écrit : However, I'm quite open to replacing the image in congruity, if anyone has any image that has a better license, and looks good... Stephen, Attached is a picture I took of my own Harmony 670 today, which I am happy to release under the GPL (version 2 or later). I've already resized it a little and made it transparent to the best of my skills. I also obviously still have the original 1.something Mb file. Let me know if it looks good enough. Yes, that looks great! Is the original 1M file you have a higher resolution than the image you attached? If so, can you crop it down and resize it to the same size (aspect-ratio correct though) as remote.png in congruity currently? I can do this if our original isn't any better resolution. Thanks. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] [PATCH] congruity : error in Pronto code conversion
Andreas Schulz wrote: Stephen, After some time, I now had reason to check the Pronto code conversion of congruity, just to discover an error in the code: Thanks for the patch. I guess I missed that bit when I was reading the spec! I've checked in the fix to congruity SVN. You just copy the burst/space times entered as Pronto hex code to the IR signal that is passed to libconcord. However, in Pronto codes burst/space times are given in units of the IR carrier cycle (which is provided by the second hex word, in units of Pronto clock cycles), whereas libconcord expects burst/space times in microseconds. So, what is missing is to multiply the Pronto duration values by the IR carrier cycle (in microseconds). See attached patch for the correction, where I also introduced the value PRONTO_CLOCK=4145146 (Hz) to replace the 'magic' value of (100 / .241246). Andreas -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] concordance failure on new ubuntu
Marc Williams wrote:
Thanks, but neither the install_policykit nor the install udev worked (I
didn't try the 3rd one). What did work though was this:
echo 'SYSFS{idVendor}==046d, SYSFS{idProduct}==c111, MODE=666'
|sudo tee /etc/udev/rules.d/custom-concordance.rules
That's essentially what make install_dev should do for you. I just
tested it on Jaunty 32-bit, and it worked fine for me.
Did you configure libconcord with a non-standard prefix? If so, the
makefile will install the udev policy in the wrong place. Perhaps you
can just run make install_udev again, and paste the output here?
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] concordance failure on new ubuntu
Marc Williams wrote:
Thanks, but neither the install_policykit nor the install udev worked (I
didn't try the 3rd one). What did work though was this:
echo 'SYSFS{idVendor}==046d, SYSFS{idProduct}==c111, MODE=666'
|sudo tee /etc/udev/rules.d/custom-concordance.rules
That's essentially what make install_dev should do for you. I just
tested it on Jaunty 32-bit, and it worked fine for me.
Did you configure libconcord with a non-standard prefix? If so, the
makefile will install the udev policy in the wrong place. Perhaps you
can just run make install_udev again, and paste the output here?
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Congruity
Phil Dibowitz wrote: Stephen, I went to go look at bug 2786023 about congruity getting undefined symbols, but I didn't get very far. It looks like with the wx module changed, or you made a typo: It looks like I've mostly run congruity using wxGTK-2.8.xx; it worked on Fedora 10 last time I tried it (apparently with XXX according to the README) and with the following on Ubuntu Jaunty: libwxgtk2.8-0 python-wxgtk2.8 Maybe older versions don't work? [p...@rider congruity-10]$ /usr/local/bin/congruity Xlib: extension RANDR missing on display :0.0. Traceback (most recent call last): File /usr/local/bin/congruity, line 1951, in module main(sys.argv) File /usr/local/bin/congruity, line 1938, in main wizard = Wizard(resources, Finalizer(resources)) File /usr/local/bin/congruity, line 1664, in __init__ sizer_buttons.AddStretchSpacer() AttributeError: 'BoxSizer' object has no attribute 'AddStretchSpacer' Looking at the help for the module, I see AddSpacer(), InsertSpacer(), PrependSpacer(), but no AddStretchSpacer. In fact, I see nothing .*Stretch.* at all. -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] [PATCH] A couple minor tweaks to libconcord/INSTALL.linux
See attached. Index: libconcord/INSTALL.linux === RCS file: /cvsroot/concordance/concordance/libconcord/INSTALL.linux,v retrieving revision 1.9 diff -u -p -r1.9 INSTALL.linux --- libconcord/INSTALL.linux 4 Mar 2009 00:20:07 - 1.9 +++ libconcord/INSTALL.linux 4 Mar 2009 02:11:05 - @@ -25,7 +25,7 @@ As root, simply run make install 3. INSTALL UDEV/CONSOLEKIT/POLICYKIT SUPPORT (OPTIONAL) If you don't want to have to be root to use concordance (or any other -libconcord frontend, you'll need to setup udev, consolekit, or policykit +libconcord frontend), you'll need to set up udev, consolekit, or policykit support. If you don't know which of these your distribution uses, then the plain udev support will work: @@ -46,7 +46,7 @@ files and install them in the right plac to the remote when it's plugged in. In otherwords, there is no need to do udev and policykit - policykit will take care of everything needed for policykit. -If you're system is using consolekit, then you can use: +If your system is using consolekit, then you can use: make consolekit sudo make install_consolekit @@ -56,12 +56,12 @@ all systems. EXTRA INSTALL NOTES + By default this library installs in /usr/local/lib. You can override the PREFIX (/usr/local) by passing a PREFIX variable to make: make PREFIX=/usr/ - ADDITIONAL NOTES Because this software uses libusb, it does Direct IO. That means the library -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Firmware Upgrade 525
Phil Dibowitz wrote: Stephen, Have you been looking at any of the firmware-on-525 stuff? I've poured over it several times and sent several debug patches to folks and looked through the dumps a lot... I haven't looked at it at all. I thought the thing you were missing was answered by Kevin (the mystery bytes were the serial number or something like that.) However, if that wasn't the whole thing, I can probably find time to try to look at it. But I don't see anything we're doing differently. We're getting the firmware to update, but we're missing some magic that lets the remote know it's on a new version. I could really use a second set of eyes if you have some time. Since you managed to figure out the magic bytes before, I figured you may habe some luck with this. I'm happy to send you all of the various debug stuff I have offlist if you're interested... Thanks, -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Firmware Upgrade 525
Steffen Sieg wrote: I have another problem: while setting up my remote, there came up a file named LearnIr.EZTut. And congruity does not recognize this. It was to learn some instructions from an original remote control. The most recent actual release of congruity doesn't support IR learning. However, if you check out the latest code from SVN, then it should work fine (with the lastest libconcord from CVS too) So I did it completely in windows in a virtual box machine, and it went relatively good, but not perfect. Regards Steffen Sieg -- ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] Minor proposed IR learning API change
Phil,
I'd like to propose the attached patch, which adds callback parameters
to learn_from_remote.
Whilst it's not that useful in the current implementation (the progress
values aren't that meaningful), I'd argue it makes sense to make this
change before the next libconcord release, so that we can implement the
actual calling of the callback whenever we want, without needlessly
breaking binary compatibility of this API between releases.
Checkin comment:
libconcord/libconcord.h:
libconcord/libconcord.cpp:
libconcord/bindings/python/libconcord.py:
Add callback parameters to learn_from_remote
libconcord/remote.h:
libconcord/remote.cpp:
libconcord/remote_z.cpp:
Add callback parameters to LearnIR
concordance/concordance.c:
Pass new callback parameters to learn_from_remote
Remove redundant percentage printing; the callback does it now.
? concordance/.concordance.c.swp
? concordance/.deps
? concordance/.libs
? concordance/Makefile
? concordance/Makefile.in
? concordance/aclocal.m4
? concordance/autom4te.cache
? concordance/concordance
? concordance/config.guess
? concordance/config.h
? concordance/config.h.in
? concordance/config.log
? concordance/config.status
? concordance/config.sub
? concordance/configure
? concordance/depcomp
? concordance/install-sh
? concordance/libtool
? concordance/ltmain.sh
? concordance/missing
? concordance/stamp-h1
? libconcord/.deps
? libconcord/.libconcord.cpp.swp
? libconcord/.libconcord.h.swp
? libconcord/.libs
? libconcord/.remote.cpp.swp
? libconcord/.remote.h.swp
? libconcord/.remote_z.cpp.swp
? libconcord/Makefile
? libconcord/Makefile.in
? libconcord/aclocal.m4
? libconcord/autom4te.cache
? libconcord/binaryfile.lo
? libconcord/config.guess
? libconcord/config.h
? libconcord/config.h.in
? libconcord/config.log
? libconcord/config.status
? libconcord/config.sub
? libconcord/configure
? libconcord/depcomp
? libconcord/install-sh
? libconcord/libconcord.la
? libconcord/libconcord.lo
? libconcord/libtool
? libconcord/libusbhid.lo
? libconcord/ltmain.sh
? libconcord/missing
? libconcord/remote.lo
? libconcord/remote_z.lo
? libconcord/stamp-h1
? libconcord/usblan.lo
? libconcord/web.lo
? libconcord/bindings/python/.libconcord.py.swp
? libconcord/bindings/python/libconcord.pyc
Index: concordance/concordance.c
===
RCS file: /cvsroot/concordance/concordance/concordance/concordance.c,v
retrieving revision 1.33
diff -u -p -r1.33 concordance.c
--- concordance/concordance.c 12 Oct 2008 22:35:26 - 1.33
+++ concordance/concordance.c 14 Oct 2008 03:42:34 -
@@ -284,11 +284,10 @@ int learn_ir_commands(uint8_t *data, uin
printf(press corresponding key );
printf(on original remote within 5 sec:\n);
printf(Learning IR signal: );
-cb_print_percent_status(0, 0, 1, NULL);
err = learn_from_remote(carrier_clock,
- ir_signal, ir_signal_length);
+ ir_signal, ir_signal_length,
+ cb_print_percent_status, NULL);
if (err == 0) {
- cb_print_percent_status(1, 1, 1, NULL);
printf( done\n);
}
break;
Index: libconcord/libconcord.cpp
===
RCS file: /cvsroot/concordance/concordance/libconcord/libconcord.cpp,v
retrieving revision 1.37
diff -u -p -r1.37 libconcord.cpp
--- libconcord/libconcord.cpp 12 Oct 2008 22:35:26 - 1.37
+++ libconcord/libconcord.cpp 14 Oct 2008 03:42:34 -
@@ -1342,7 +1342,8 @@ void delete_key_names(char **key_names,
* Returns 0 for success, error code for failure.
*/
int learn_from_remote(uint32_t *carrier_clock,
- uint32_t **ir_signal, uint32_t *ir_signal_length)
+ uint32_t **ir_signal, uint32_t *ir_signal_length,
+ lc_callback cb, void *cb_arg)
{
if (rmt == NULL){
return LC_ERROR_CONNECT;
@@ -1354,7 +1355,8 @@ int learn_from_remote(uint32_t *carrier_
}
/* try to learn code via Harmony from original remote: */
- return rmt-LearnIR(carrier_clock, ir_signal, ir_signal_length);
+ return rmt-LearnIR(carrier_clock, ir_signal, ir_signal_length, cb,
+ cb_arg);
}
/*
Index: libconcord/libconcord.h
===
RCS file: /cvsroot/concordance/concordance/libconcord/libconcord.h,v
retrieving revision 1.20
diff -u -p -r1.20 libconcord.h
--- libconcord/libconcord.h 12 Oct 2008 22:35:26 - 1.20
+++ libconcord/libconcord.h 14 Oct 2008 03:42:34 -
@@ -431,7 +431,8 @@ void delete_key_names(char **key_names,
* via delete_ir_signal() when not needed any longer.
*/
int learn_from_remote(uint32_t *carrier_clock,
- uint32_t **ir_signal, uint32_t *ir_signal_length);
+ uint32_t **ir_signal, uint32_t *ir_signal_length,
+ lc_callback cb, void *cb_arg);
void delete_ir_signal(uint32_t *ir_signal);
Index: libconcord/remote.cpp
===
RCS file: /cvsroot/concordance/concordance/libconcord/remote.cpp,v
retrieving revision 1.35
diff -u -p
Re: [concordance-devel] [patch 0/2] Change of libconcord API for IR codes learning - Build 20081010
Phil Dibowitz wrote:
Stephen - you have a patch waiting in the wings - can you send that in now?
Sorry to make you wait so long.
No problem; updated patch attached.
I have validated congruity against the resultant modified libconcord.py,
but using a previous version of Andreas's patch for the libconcord C
files. I'll validate congruity against latest concordance CVS as soon as
I can.
Patch description:
concordance/libconcord/bindings/python/README:
* Add information on how to enable the debug tracing
concordance/libconcord/bindings/python/libconcord.py:
* Add error-code constants
* Implement debug tracing
Prints all functions called, their parameters, and results
* Modify the prototyping mechanism for the libconcord functions, allowing
parameters to be explicitly marked as input or output (required for debug
tracing), and integrating result error-checking into the return type
definition.
* Modify formatting of new IR functions to match the rest of the file.
? libconcord/.libconcord.h.swp
? libconcord/bindings/python/.libconcord.py.swp
? libconcord/bindings/python/.swp
Index: libconcord/bindings/python/README
===
RCS file: /cvsroot/concordance/concordance/libconcord/bindings/python/README,v
retrieving revision 1.1
diff -u -p -r1.1 README
--- libconcord/bindings/python/README 15 Apr 2008 02:34:08 - 1.1
+++ libconcord/bindings/python/README 12 Oct 2008 23:07:21 -
@@ -32,3 +32,14 @@ the bindings to your PYTHONPATH. For exa
export PYTHONPATH=/path/to/libconcord/bindings/python
+Debugging
+
+
+If you set the environment variable LIBCONCORD_PY_TRACE to string 1, then
+libconcord.py will trace all function calls. This may prove helpful when
+debugging client applications.
+
+For example, in bash:
+
+LIBCONCORD_PY_TRACE=1 ./congruity /path/to/Connectivity.EZHex
+
Index: libconcord/bindings/python/libconcord.py
===
RCS file: /cvsroot/concordance/concordance/libconcord/bindings/python/libconcord.py,v
retrieving revision 1.2
diff -u -p -r1.2 libconcord.py
--- libconcord/bindings/python/libconcord.py 12 Oct 2008 22:35:26 - 1.2
+++ libconcord/bindings/python/libconcord.py 12 Oct 2008 23:07:22 -
@@ -1,7 +1,7 @@
#
-# vi: formatoptions+=tc textwidth=80 tabstop=8 shiftwidth=8 noexpandtab:
+# vi: formatoptions+=tc textwidth=80 tabstop=8 shiftwidth=4 expandtab:
#
-# $Id: libconcord.py,v 1.2 2008/10/12 22:35:26 jaymzh Exp $
+# $Id: libconcord.py,v 1.1 2008/04/08 09:50:29 jaymzh Exp $
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -18,19 +18,58 @@
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
#
-
from ctypes import *
+from ctypes import _Pointer
import platform
+import os
import sys
+import traceback
+
+# Debug request parsing
+
+debug = (os.environ.get(LIBCONCORD_PY_TRACE, 0) == 1)
+
+# Define the libconcord ABI this libconcord.py corresponds to
+# Bump this when the .so file version gets bumped
+
+ABI_VERSION = 0
+
+# Load the DLL
-# Internal DLL handle
if platform.system() == 'Windows':
_dll = cdll.LoadLibrary('libconcord.dll')
else:
-_dll = cdll.LoadLibrary('libconcord.so.0')
+_dll = cdll.LoadLibrary('libconcord.so.' + str(ABI_VERSION))
+
+# Public libconcord API: Custom types
+
+# typedef void (*lc_callback)(uint32_t, uint32_t, uint32_t, void*);
+callback_type = CFUNCTYPE(None, c_uint, c_uint, c_uint, py_object)
+
+# Public libconcord API: Error codes
+
+LC_ERROR = 1
+LC_ERROR_INVALID_DATA_FROM_REMOTE = 2
+LC_ERROR_READ = 3
+LC_ERROR_WRITE = 4
+LC_ERROR_INVALIDATE = 5
+LC_ERROR_ERASE = 6
+LC_ERROR_VERIFY = 7
+LC_ERROR_POST = 8
+LC_ERROR_GET_TIME = 9
+LC_ERROR_SET_TIME = 10
+LC_ERROR_CONNECT = 11
+LC_ERROR_OS = 12
+LC_ERROR_OS_NET = 13
+LC_ERROR_OS_FILE = 14
+LC_ERROR_UNSUPP = 15
+LC_ERROR_INVALID_CONFIG = 16
+LC_ERROR_IR_OVERFLOW = 17
+
+# Public libconcord API: Exception types
-# This exception may be raised by any function that returns an LC_ERROR_*.
class LibConcordException(Exception):
+This exception may be raised by any function that returns an LC_ERROR_*.
def __init__(self, func, result):
self.func = func
self.result = result
@@ -47,6 +86,7 @@ class LibConcordException(Exception):
)
# Internal function result checking functionality
+
class _CheckRetCode(object):
def __init__(self, func_name):
self.func_name = func_name
@@ -57,179 +97,308 @@ class _CheckRetCode(object):
raise LibConcordException(self.func_name, result)
return result
+# Internal helpers for result prototyping
+
+class _ret(object):
+def __init__(self):
+pass
+
+class _ret_void(_ret):
+def __init__(self):
+pass
+
+def real_ctypes_type(self):
+return c_int
+
+def checker(self):
+return None
+
+
Re: [concordance-devel] [patch 0/2] Change of libconcord API for IR codes learning - Build 20081010
Phil Dibowitz wrote: Stephen - I know you've been keeping Congruity in step with Andreas patches, but now that his patches are actually applied, you may want to make sure it works with CVS head. Yup, congruity (irlearn branch) works fine with libconcord CVS, including for IR learning. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] IR learning support in congruity
FYI, I've implemented IR learning support in congruity (either from the Harmony or from a Pronto hex file). This support is now in the trunk of SVN. Have at it! - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] IR learning: Success story, and error-handling feedback
I just used the IR learning feature in congruity/libconcord to learn the home button of the original Roku Netflix player, and the Harmony website recognized the signal as a pre-existing key it knew about. So, the whole chain works! Some feedback on error handling in the libconcord API: learn_from_remote() simply returns the result code from rmt-LearnIR unchanged. LearnIR() returns different kinds of error codes, depending on what error occurred. Sometimes, error codes from HID_(Read|Write)Report are returned directly, and sometimes, LC_* are returned. This makes it difficult for a client application to correctly interpret what went wrong. In particular, if the user never presses the button on the original remote, HID_ReadReport fails, and ends up returning error code -110 (on my system at least). Since this is non-zero, congruity treats this as an error. I can't special-case this error code, because there's no defined LC_* code to mean timeout; the -110 error code is unlikely to be portable (and I have no idea if it's specific to this case either). Can LearnIR() be modified to: a) Always return LC_* error codes. and b) On timeout, either: 1) Return a new LC_* error code for this specific reason or 2) Return OK, and an empty array of learned data This will allow congruity to detect the timeout situation, and allow the user to retry the learning process. Other kinds of error would still be fatal. Right now, the error is treated as fatal. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] firmware 525
Phil Dibowitz wrote: Koen Erens wrote: hi, is there any progress on the 525 firmware update? i get the -110 error while trying to update from 2.1 to 2.6 Not at the moment sorry. I've finally started having time to work through the backlog of patches while I was moving, and have gotten comments out to everyone (anyone who thinks they're waiting for me on a patch, please let me know). As soon as I get those all merged and tested, firmware is the next thing on the list. Are you willing to try patches? Since I don't have a 525 (I don't have anything other than my 880), we'll need testers... FYI, somebody I know at the local Linux User's Group just picked up a used 525, so they may be able to test some stuff out too. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] libconcord new full patch (Re: Next try for the big IR learning patch..)
On Tue, June 24, 2008 1:04 am, Andreas Schulz wrote:
So, maybe we can agree on the following interface:
That should work. Just a few mostly small comments:
In the delete_* functions, I'd use a more descriptive name for the
parameter than garbage, e.g.:
void delete_key_names(char **key_names);
In the description for get_key_names:
* Memory allocated for the strings must be freed by the caller
* via destroy_key_names() when not needed any longer, i.e.
* after all codes have been posted via post_new_code.
I would avoid specifically mentioning deleting the memory after
post_new_code, because some clients will probably do this:
char ** key_names = get_key_names(...);
duplicate key_names into some internal structure (e.g. Python strings in a
list)
delete_key_names(key_names);
process the internal structure
The internal structure could be created by duplicating all the strings and
indexing them in some different way. Note: The key names are obviously
required to call post_new_code later, but there's no requirement it be the
same actual string (memory location holding it, that is), but simply that
the content of the string must be the same.
So, perhaps simply say this instead:
* Memory allocated for the strings must be freed by the caller
* via destroy_key_names() when no longer needed.
Same for other allocating functions.
In get_key_names, rather than returning an array with a NULL entry to
indicate the end, how about this:
int get_key_names(uint8_t *data, uint32_t size,
char *** key_names, uint32_t *key_names_length);
and called/used like this:
char **key_names;
uint32_t key_names_length;
int err = get_key_names(d, s, key_names, key_names_length);
if (err != SUCCESS) {
// handle error here
return;
}
for (int i = 0; i key_names_length; ++i) {
printf(Key name %d is '%s'\n, i, key_names[i]);
}
This:
a) Can allow more meaningful error status
b) Is explicit about the array length up front
One could make a similar change to encode_for_posting, but since that's
always returning just one string, I'm not worried about that so much; your
call.
I would rename post_new_code's code parameter to encoded, to hint that
it comes from encode_for_posting.
Thanks for implementing this guys, and being open to API changes.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] libconcord new full patch (Re: Next try for the big IR learning patch..)
On Mon, June 23, 2008 3:11 pm, Andreas Schulz wrote: On Sunday 22 June 2008, Stephen Warren wrote: In the documentation for get_key_name, it may be worth mentioning that valid index values start at 1 anything wrong with index starting at 1 for '1'st entry? Probably not, but it's sufficiently unusual for C (and many other languages) that it's just worth mentioning. Well, concordance could do that as well, so what about: char **get_keynames(uint8_t *data, uint32_t size); void destroy_keynames(char **names); and be done with the XML data in one call? That'd work too. I'll have to check whether it's easy to deal with char** in the Python bindings; it should be... I started adding deallocators in libIRremotes, and will do so for libconcord. I'm not sure about the internals of python - will deallocators be of any use there, and when should they be called? Absolutely useful. libconcord.py should simply expose the function call as-is; never automatically call them (except in a situation where the bindings actually copy the returned data into a Python type, rather than returning a ctypes type referencing the memory, but we don't ever do that, currently at least). The client app (e.g. congruity) should call them at the same time a C application would; whenever it's done using the returned data. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] libconcord new full patch (Re: Next try for the big IR learning patch..)
On Mon, June 23, 2008 3:28 pm, Phil Dibowitz wrote: Andreas Schulz wrote: Well, concordance could do that as well, so what about: char **get_keynames(uint8_t *data, uint32_t size); void destroy_keynames(char **names); and be done with the XML data in one call? I don't think we need the call to destory() in this case. I don't agree. Why should the client (or bindings) know how the memory was allocated, and hence how to free it. malloc() is common, but if the client/bindings simply assume this, and call free() on the data, things will break very horribly if libconcord was built using a debug malloc library that redefines malloc/free to be something else, and perhaps actually allocates a different (larger) sized chunk of memory in order to add debug information headers/trailers, meaning that the actual pointer passed to real free should be, say, 8 bytes less than that returned by the debug malloc. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] libconcord new full patch (Re: Next try for the big IR learning patch..)
Andreas Schulz wrote:
Next, here comes the latest version of my IR learning patch for
libconcord.
A few comments on the API:
+ * pulse_count : total number of pulse and space durations in pulses
+ * pulses should start with a pulse and end with a space duration,
+ * hence pulse_count will always be an even number.
A pulse is usually a low-high-low transition, whereas these docs
talk about pulses and spaces. There should be differentiation between
pulses (mark followed by space), marks (high time), and spaces (low time)
So, I'd rewrite the docs as:
+/*
+ * Data structure information:
+ *
+ * carrier_clock: In Hz, usually ~36000..4
+ * pulses: IR mark/space durations (alternating) in microseconds
+ * pulse_count: Total number of pulses, i.e. total number of marks plus
+ * total number of spaces. Pulses consist of a mark plus a space,
+ * hence pulse_count will always be an even number.
In the documentation for get_key_name, it may be worth mentioning that
valid index values start at 1 (rather than the typical 0) and increment
by 1 until NULL is returned. With the current docs, it could be legal
for index values 1, 2 to be defined, 3, 4 not, then 5, 6, 7 to be
defined. Actually, see below for further comments on the semantics of
this API.
Please document that the memory pointed at by get_key_name's return
value needs to be free'd by the client. libconcord needs an API for the
client to call to do this; not all clients are C, and hence they can't
all call C's free(), and delete_blob is only defined for file blobs
(which are free()d using delete[], which should only be used for new[]'d
pointers, and not for malloc/strdup/...-returned pointers).
I really don't like the static buffer used by get_key_name. It's nasty
that a client can only use this API on a single data blob at a time, and
that the API internally maintains non-obvious implicit state. I'd prefer
something more like the API below, where the XMLBuffer is dynamically
allocated per iterator, but the type/content is still opaque to the client:
void *keyiter_create(uint8_t *data, uint32_t size);
char *keyiter_next(void* keyiter);
void keyiter_destroy(void *keyiter);
void keyiter_key_destroy(char *);
where the client uses this like:
void *i = keyiter_create(d, s);
for (;;) {
char *s = keyiter_next(i);
if (!s) {
break;
printf(Key: '%s'\n, s);
keyiter_key_destroy(s);
}
keyiter_destroy(i);
No reversing or random access allowed either; should be much simpler.
One could combine keyiter_create/keyiter_next in a similar fashion to
how strtok detects first v.s. subsequent invocations, but I think the
above API is a little clearer.
encode_for_posting needs to define who owns the memory returned, and how
to destroy it.
post_new_code and encode_for_posting check all the output/pointer
parameters against being NULL, but learn_from_remote doesn't.
The version number of the DLL should be increased to indicate that the
API changed incompatibly.
I'm not convinced that the Python bindings changes for verbose are the
correct way to go; they don't handle exceptions very well. It'd be best
if you removed the verbose part from the Python bindings, and I'll
work on a more automated and robust solution, and one that doesn't
require the host application to configure it, since I don't really want
to include that kind of debug logic in the production version of congruity.
Thanks!
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Patches for major update of IR code learning
Phil Dibowitz wrote: Yeah, I figure I'll probably sign up for a sourceforge project for the next release, or something like that, and use their web-space for that.= That works as well, but even a small index.html in the directory you have the downloads in works. Here it is: https://sourceforge.net/projects/congruity/ I'll get around to putting something trivial in the web page part soon, and upload a screenshot or two. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] Vacation
Just as an FYI, I'm going to be on vacation from this Monday through May 19th, probably without any email access. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Perl binding test problems
On Wed, April 23, 2008 2:56 pm, Phil Dibowitz wrote: On Wed, Apr 23, 2008 at 01:40:10PM -0400, Douglas E. Warner wrote: I'm trying to get concordance/libconcord 0.20 packaged for Fedora and am having some problems getting the perl bindings tests running; I'm getting the following error (after compiling libconcord and the bindings): I suspect you haven't actually installed libconcord, so the make-test for the perl bindings doesn't work. Ah. Perhaps setting LD_LIBRARY_PATH to something appropriate before running make test might help the situation within the package build script. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Sleep and Windows
Stephen Warren wrote:
Phil Dibowitz wrote:
FYI: I get the feeling that unistd.h may not be available on Windows - so
someone may want to test that and let me know...
Well, the attached patch fixes the compile failure.
However, it seems like there are some pretty serious issues with the
Windows USB code:
Ooops. Well, there was a nasty issue with my patch!
Windows' sleep is in milli-seconds, which my patch didn't account for.
So with my previous patch, concordance ended up not waiting long enough
for reset_remote to actually trigger the OS to see the device as having
gone away. Hence, enumeration found the device before the reset took
effect, but of course couldn't communicate with it.
See attached patch:
concordance/concordance.c
Fix Windows sleep() macro to wait seconds not milli-seconds.
This raises the question though: What happens if the current initial 5
second wait isn't long enough? It'd be nice if there was an event that
says your handle just died which we could wait for first. I can
certainly see a heavily loaded old machine take a long time to recognize
the USB device going away. Perhaps the loop should be more like
for number of attempts:
sleep
attempt to connect
fail - loop
attempt to set time
fail - loop
all ok, so exit loop
Or, perhaps:
while handle_still_seems_valid() {
// no sleep, so we're fast enough to catch device while it's gone
}
for number of attempts
sleep
attempt to reconnect
ok - exit loop
set_time
where handle_still_seems_valid can't actually communicate with the
remote, because after reset_remote it won't respond, but perhaps
re-performs enumeration to check if the device still exists. The problem
then is what if we aren't fast enough to see when the device is not there...
? concordance/win/Debug
? libconcord/win/Debug
? win/concordance.ncb
Index: concordance/concordance.c
===
RCS file: /cvsroot/concordance/concordance/concordance/concordance.c,v
retrieving revision 1.31
diff -u -p -r1.31 concordance.c
--- concordance/concordance.c 15 Apr 2008 05:45:40 - 1.31
+++ concordance/concordance.c 15 Apr 2008 05:58:03 -
@@ -36,7 +36,7 @@
#define strcasecmp stricmp
#define strncasecmp strnicmp
-#define sleep Sleep
+#define sleep(x) Sleep((x) * 1000)
/*
* Windows, in it's infinite awesomeness doesn't include POSIX things
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Firmware Upgrade 525
On Tue, April 15, 2008 9:35 am, Michael Frase wrote: Any Suggestions? Is it possible to log the usb transfer (firmware upgrade) in windows (like usbmon in linux)? Yes. Use SnoopyPro, available from: http://sourceforge.net/project/showfiles.php?group_id=34567 Once you have the captures in the tool, you'll want to perform an export operation to the XML format. You can then send in the XML files. If you're curious, the consnoop directory in CVS contains an application that can analyze these XML files. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Sleep and Windows
On Tue, April 15, 2008 12:18 am, Phil Dibowitz wrote: Stephen Warren wrote: This raises the question though: What happens if the current initial 5 second wait isn't long enough? What do you mean? If my 5 second sleep isn't enough, I sleep for another 5. And then another 5. And then 5 more. 5 more. 5 more. THEN I give up. I mean, what if, after the first 5 second sleep, the system hasn't noticed USB disconnect due to remote reboot. In this case (which I could easily imagine on a heavily swapping system), the code will enumerate the original pre-reset Harmony device, and then fail. I guess with the call to identify in the loop now, that's not an issue, because identify should fail, and cause the loop to loop again. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] congruity (libconcord GUI) version 6 released
Phil Dibowitz wrote: Stephen Warren wrote: As you may have noticed, congruity does this already at the application level. This whole process obviously takes some time, and could even fail (e.g. if user unplugs the remote.) This change probably requires reset_remote having a callback to indicate progress... reset_remote has no way of knowing progress, it sends a command and the remote disappears. I did a deinit_concord and then have a loop while we wait for it for a certain amount of time. If it doesn't come back, we report it as an error. Oops. For some reason, I assumed you'd made libconcord do the wait-for-reboot loop internally. Now that I actually read the code, I see concordance.c does this, which makes much more sense! - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] congruity (libconcord GUI) version 7 released
Version 7 of congruity is released. congruity is a Python/wxPython-based GUI for libconcord. It is intended to handle downloads from the Harmony website, program the remote, and communicate results back to the website - i.e. provide an open-source replacement for the website interaction portion of the existing proprietary GUI application. The download is available from: http://www.wwwdotorg.org/downloads/congruity/congruity-7.tar.bz2 NOTE: This release of congruity depends on libconcord release 0.20. The changes are as follows: * 2008-04-14 Stephen Warren [EMAIL PROTECTED] - congruity-7 - Switched license to GPLv3+ to be compatible with libconcord by default. Contact me if you want the code under a different license, but please note that you won't be able to use relicensed code with libconcord. - Added a Makefile for easy installation. Thanks to Phil Dibowitz for the contribution. - Added a manual page. - Added a few useful URLs to README.txt. - Fixed reliance on syntax specific to Python 2.5. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] congruity (libconcord GUI) version 6 released
Phil Dibowitz wrote:
Stephen Warren wrote:
Version 6 of congruity is released.
congruity is a Python/wxPython-based GUI for libconcord. It is intended
to handle downloads from the Harmony website, program the remote, and
communicate results back to the website - i.e. provide an open-source
replacement for the website interaction portion of the existing
proprietary GUI application.
I'm getting a syntax error - though I have made no attempt to debug it:
[EMAIL PROTECTED] congruity-6]$ congruity
File /usr/bin/congruity, line 58
finally:
^
SyntaxError: invalid syntax
Try the attached congruity script. I may have been relying on Python 2.5
syntax (I guess I should test with an older Python version sometime...)
#!/usr/bin/python
# This code NOT copyright Stephen Warren [EMAIL PROTECTED]
# This code is released into the public domain.
from ctypes import *
import os
import os.path
import sys
import thread
import time
import traceback
import wx
import wx.lib.dialogs
import libconcord
version = 6+
def program_callback_imp(count, current, total, cb_func):
if not cb_func:
return
try:
cb_func(False, (current * 100) / total)
except:
print
traceback.print_exc()
def exception_message():
msg = ''
if type(sys.exc_value) == libconcord.LibConcordException:
msg += sys.exc_value.result_str + '\n\n'
msg += traceback.format_exc()
return msg
def program(type, xml, xml_size, handler):
action_func = {
libconcord.LC_FILE_TYPE_CONNECTIVITY: program_body_connectivity,
libconcord.LC_FILE_TYPE_CONFIGURATION: program_body_configuration,
libconcord.LC_FILE_TYPE_FIRMWARE: program_body_firmware
}[type]
need_deinit = [False]
try:
try:
program_callback = libconcord.callback_type(program_callback_imp)
program_body_connect(program_callback, handler, need_deinit)
set_time = action_func(xml, xml_size, program_callback, handler)
need_deinit[0] = False
program_body_disconnect(program_callback, handler)
if set_time:
program_body_reconnect_set_time(program_callback, handler,
need_deinit)
handler.on_final_status(True, '')
except:
handler.on_final_status(False, exception_message())
finally:
try:
if need_de_init[0]:
program_disconnect(handler)
except:
pass
def program_body_connect(program_callback, handler, need_deinit):
if handler:
handler.on_requesting_id(False, 0)
libconcord.init_concord()
need_deinit[0] = True
if handler:
handler_f = py_object(handler.on_requesting_id)
else:
handler_f = None
libconcord.get_identity(
program_callback,
handler_f
)
sys.stdout.flush()
if handler:
handler.on_requesting_id(True, 100)
def program_body_connectivity(xml, xml_size, program_callback, handler):
handler.on_web_notify_final(False, 0)
libconcord.post_connect_test_success(xml, xml_size)
handler.on_web_notify_final(True, 100)
return False
def program_body_configuration(xml, xml_size, program_callback, handler):
handler.on_web_notify_init(False, 0)
libconcord.post_preconfig(xml, xml_size)
handler.on_web_notify_init(True, 100)
handler.on_prepare(False, 0)
bin_data = POINTER(c_ubyte)()
bin_size = c_uint()
libconcord.find_config_binary(
xml,
xml_size,
byref(bin_data),
byref(bin_size)
)
handler.on_prepare(False, 50)
libconcord.invalidate_flash()
handler.on_prepare(True, 100)
handler.on_erasing_flash(False, 0)
libconcord.erase_config(
bin_size,
program_callback,
py_object(handler.on_erasing_flash)
)
handler.on_erasing_flash(True, 100)
handler.on_writing_config(False, 0)
libconcord.write_config_to_remote(
bin_data,
bin_size,
program_callback,
py_object(handler.on_writing_config)
)
handler.on_writing_config(True, 100)
handler.on_verifying_config(False, 0)
libconcord.verify_remote_config(
bin_data,
bin_size,
program_callback,
py_object(handler.on_verifying_config)
)
handler.on_verifying_config(True, 100)
handler.on_web_notify_final(False, 0)
libconcord.post_postconfig(xml, xml_size)
handler.on_web_notify_final(True, 100)
libconcord.reset_remote()
return True
def program_body_firmware(xml, xml_size, program_callback, handler):
handler.on_prepare(False, 0)
# is_fw_update_supported returns error code; 0 OK, otherwise failure
if not libconcord.is_fw_update_supported(0):
is_direct = False
elif not libconcord.is_fw_update_supported(1):
is_direct = True
else:
raise Exception('Firmware update not supported on this remote
Re: [concordance-devel] Preparing for 0.20's release
On Fri, April 11, 2008 1:28 am, Phil Dibowitz wrote: Oh, another thing I was thinking about for the release: I was thinking of EITHER: A. Splitting the changelog and having one in libconcord/ and one in concord/ -- all the history would go in one (probably libconcord), but starting with 0.20, the right entries would go on the right place I guess I'd vote for this option. (I kinda dislike when projects have a large directory tree and a ChangeLog per directory in the tree, but in this case, concordance/libconcord really are 2 separate things, so it makes sense to me.) Just one question: What about the consnoop directory. I guess that could have its own too, if we ever make changes there. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Firmware Upgrade 525
On Thu, April 10, 2008 1:25 pm, Phil Dibowitz wrote: Michael Frase wrote: Hi Phil, thanks for your quick replies and changes in cvs. I'm back again and tested latest cvs with my harmony 555. ... Here's whats REALLY odd. I massaged the LatestUpdate.EZUp to be in the format we write out fw dumps in, and it's IDENTICAL (minus the magic bytes, of course) to his current fw dump: ... Meanwhile, there's drastic differences between his dump now and his dump from before. Are you sure this remote/arch has the correct firmware upgrade base? I.e are we writing to and dumping the wrong location? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Preparing for 0.20's release
Phil Dibowitz wrote: Anyone else have anything they think needs to be in 0.20? Well, since I've been using Doxygen a lot at work, I was contemplating writing a bunch of Doxygen comments in libconcord.h, so we could generate pretty looking doc pages etc., now that the API seems reasonably stable for a while. That said, I certainly wouldn't actually hold up any given release for this. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Preparing for 0.20's release
Phil Dibowitz wrote:
Stephen Warren wrote:
There is one cosmetic bug, in that print CTRL-H doesn't do a backspace
on Windows, so the percentage progress messages looks like turd. I'll
see if that's easy to fix...
Eh, what? That should never happen on windows:
#ifdef WIN32
GetConsoleScreenBufferInfo(con, sbi);
SetConsoleCursorPosition(con, sbi.dwCursorPosition);
#else
if (count != 0) {
printf(\b\b\b\b\b\b\b\b\b\b\b\b\b\b);
}
#endif
That code never gets executed if WIN32 is defined... something's very odd...
Yeah, I hadn't looked at the code, and was assuming that ^H wasn't
working. In fact, it the issue was that the WIN32 code branch is a no-op.
Attached is a patch that:
concordance.c:
Fix progress message formatting on WIN32 by actually adjusting
the cursor position.
Fix some trailing white-space.
Localize a variable declaration to where it's used.
Note: This is another Windows/Cygwin-based patch, so if it fails to
apply, maybe utod is required.
? concordance/win/Debug
? concordance/win/Release
? concordance/win/concordance.vcproj.ESK.Stephen Warren.user
? consnoop/win/consnoop.vcproj.ESK.Stephen Warren.user
? libconcord/win/Debug
? libconcord/win/Release
? libconcord/win/libconcord_libusb.vcproj.ESK.Stephen Warren.user
? libconcord/win/libconcord_winhid.vcproj.ESK.Stephen Warren.user
? win/concordance.ncb
? win/concordance.suo
Index: concordance/concordance.c
===
RCS file: /cvsroot/concordance/concordance/concordance/concordance.c,v
retrieving revision 1.24
diff -u -p -r1.24 concordance.c
--- concordance/concordance.c 11 Apr 2008 05:05:26 - 1.24
+++ concordance/concordance.c 11 Apr 2008 05:50:18 -
@@ -50,7 +50,6 @@ char* basename(char* file_name)
}
HANDLE con;
-CONSOLE_SCREEN_BUFFER_INFO sbi;
#else
/* NON-Windows */
@@ -106,13 +105,22 @@ void cb_print_percent_status(uint32_t co
{
int is_bytes;
#ifdef WIN32
- GetConsoleScreenBufferInfo(con, sbi);
- SetConsoleCursorPosition(con, sbi.dwCursorPosition);
-#else
+ CONSOLE_SCREEN_BUFFER_INFO sbi;
+#endif
+
if (count != 0) {
+#ifdef WIN32
+ GetConsoleScreenBufferInfo(con, sbi);
+ sbi.dwCursorPosition.X -= 14;
+ if (sbi.dwCursorPosition.X 0) {
+ sbi.dwCursorPosition.X = 0;
+ }
+ SetConsoleCursorPosition(con, sbi.dwCursorPosition);
+#else
printf(\b\b\b\b\b\b\b\b\b\b\b\b\b\b);
+#endif
}
-#endif
+
is_bytes = 0;
if (arg) {
is_bytes = (int)(arg);
@@ -123,7 +131,7 @@ void cb_print_percent_status(uint32_t co
} else {
printf(%3i%% , curr*100/total);
}
- fflush(stdout);
+ fflush(stdout);
}
/*
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] Latest Python bindings
Attached is the latest libconcord.py file, to match recent libconcord.h
changes.
Also included is a setup.py file, to go in the same directory. This is
essentially an install script; a standard thing to include when
distributing any Python module.
# This code NOT copyright Stephen Warren [EMAIL PROTECTED]
# This code is released into the public domain.
from ctypes import *
import platform
import sys
# Internal DLL handle
if platform.system() == 'Windows':
_dll = cdll.LoadLibrary('libconcord.dll')
else:
_dll = cdll.LoadLibrary('libconcord.so.0')
# This exception may be raised by any function that returns an LC_ERROR_*.
class LibConcordException(Exception):
def __init__(self, func, result):
self.func = func
self.result = result
try:
self.result_str = c_char_p(_dll.lc_strerror(c_int(self.result))).value
except:
self.result_str = 'Unknown'
def __str__(self):
return 'libconcord function %s failed with error code %s (%s)' % (
repr(self.func),
repr(self.result),
repr(self.result_str)
)
# Internal function result checking functionality
class _CheckRetCode(object):
def __init__(self, func_name):
self.func_name = func_name
def __call__(self, *args):
result = args[0]
if result != 0:
raise LibConcordException(self.func_name, result)
# Internal ctypes function wrapper creation
def _create_func(
func_name,
error_checker,
*args
):
ftype = CFUNCTYPE(*args)
f = ftype((func_name, _dll))
if error_checker:
f.errcheck = error_checker(func_name)
return f
# typedef void (*lc_callback)(uint32_t, uint32_t, uint32_t, void*);
callback_type = CFUNCTYPE(None, c_uint, c_uint, c_uint, py_object)
# const char *get_mfg();
get_mfg = _create_func(
'get_mfg',
None,
c_char_p
)
# const char *get_model();
get_model = _create_func(
'get_model',
None,
c_char_p
)
# const char *get_codename();
get_codename = _create_func(
'get_codename',
None,
c_char_p
)
# int get_skin();
get_skin = _create_func(
'get_skin',
None,
c_int
)
# int get_fw_ver_maj();
get_fw_ver_maj = _create_func(
'get_fw_ver_maj',
None,
c_int
)
# int get_fw_ver_min();
get_fw_ver_min = _create_func(
'get_fw_ver_min',
None,
c_int
)
# int get_fw_type();
get_fw_type = _create_func(
'get_fw_type',
None,
c_int
)
# int get_hw_ver_maj();
get_hw_ver_maj = _create_func(
'get_hw_ver_maj',
None,
c_int
)
# int get_hw_ver_min();
get_hw_ver_min = _create_func(
'get_hw_ver_min',
None,
c_int
)
# int get_flash_size();
get_flash_size = _create_func(
'get_flash_size',
None,
c_int
)
# int get_flash_mfg();
get_flash_mfg = _create_func(
'get_flash_mfg',
None,
c_int
)
# int get_flash_id();
get_flash_id = _create_func(
'get_flash_id',
None,
c_int
)
# const char *get_flash_part_num();
get_flash_part_num = _create_func(
'get_flash_part_num',
None,
c_char_p
)
# int get_arch();
get_arch = _create_func(
'get_arch',
None,
c_int
)
# int get_proto();
get_proto = _create_func(
'get_proto',
None,
c_int
)
# const char *get_hid_mfg_str();
get_hid_mfg_str = _create_func(
'get_hid_mfg_str',
None,
c_char_p
)
# const char *get_hid_prod_str();
get_hid_prod_str = _create_func(
'get_hid_prod_str',
None,
c_int
)
# int get_hid_irl();
get_hid_irl = _create_func(
'get_hid_irl',
None,
c_int
)
# int get_hid_orl();
get_hid_orl = _create_func(
'get_hid_orl',
None,
c_int
)
# int get_hid_frl();
get_hid_frl = _create_func(
'get_hid_frl',
None,
c_int
)
# int get_usb_vid();
get_usb_vid = _create_func(
'get_usb_vid',
None,
c_int
)
# int get_usb_pid();
get_usb_pid = _create_func(
'get_usb_pid',
None,
c_int
)
# int get_usb_bcd();
get_usb_bcd = _create_func(
'get_usb_bcd',
None,
c_int
)
SERIAL_COMPONENT_1 = 1
SERIAL_COMPONENT_2 = 2
SERIAL_COMPONENT_3 = 3
# char *get_serial(int p);
get_serial = _create_func(
'get_serial',
None,
c_char_p,
c_int
)
# int get_config_bytes_used();
get_config_bytes_used = _create_func(
'get_config_bytes_used',
None,
c_int
)
# int get_config_bytes_total();
get_config_bytes_total = _create_func(
'get_config_bytes_total',
None,
c_int
)
# int get_time_second();
get_time_second = _create_func(
'get_time_second',
None,
c_int
)
# int get_time_minute();
get_time_minute = _create_func(
'get_time_minute',
None,
c_int
)
# int get_time_hour();
get_time_hour = _create_func(
'get_time_hour',
None,
c_int
)
# int get_time_day();
get_time_day = _create_func(
'get_time_day',
None,
c_int
)
# int get_time_dow();
get_time_dow = _create_func(
'get_time_dow',
None,
c_int
)
# int get_time_month();
get_time_month
[concordance-devel] congruity (libconcord GUI) version 5
Version 5 of congruity is released. congruity is a Python/wxPython-based GUI for libconcord. It is intended to handle downloads from the Harmony website, program the remote, and communicate results back to the website - i.e. provide an open-source replacement for the website interaction portion of the existing proprietary GUI application. The download is available from: http://www.wwwdotorg.org/downloads/congruity/congruity-5.tar.bz2 NOTE: congruity relies on libconcord from the latest CVS. The changes are as follows: * 2008-04-07 Stephen Warren [EMAIL PROTECTED] - congruity-5 - This release solely operates using libconcord; screen-scraping the output from the concordance application is no longer supported. - Implement firmware upgrade. - Minor tweaks for operation on MS-Windows. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] API to identify file type
Phil Dibowitz wrote: Stephen Warren wrote: OK. Here's a complete version, with concordance.c integration. It works for all the files in harmony_usb_logs, and a file of each type that I got from the Website. I applied it, but with a few changes - see the CVS list for the actual diff, but here's the list: - cleaned up the switch a bit You forgot to add break statements to the switch cases. Also, spaces crept into the indentation on line 341 of libconcord.cpp; I swore I checked that using visible spaces, but I guess not... - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] RFC: Changing the usb read/writes
Here's an updated version of the USB patch that works with WinHID on
Windows. I had to fix:
HID_WriteReport: MS compiler won't allow creation of a variable-sized
array on the stack, so I made the code new/delete it instead.
HID_ReadReport: tmp wasn't being allocated, and assigning to data
function parameter had no effect. I made the code read into the regular
return data location, then shift it down by 1 byte. Note that the dw
return parameter from ReadFile is always 0, so that can't be used.
I think that's it functionally. I did fix some formatting issues in a
couple places too.
Oh, and the diff was made using Cygwin, so you may have to run dos2unix
on it.
I tested:
-v -i
-k
-K
Connectivity file
Config update file
Firmware update file
Index: libconcord/hid.h
===
RCS file: /cvsroot/concordance/concordance/libconcord/hid.h,v
retrieving revision 1.5
diff -u -p -r1.5 hid.h
--- libconcord/hid.h3 Apr 2008 07:01:46 - 1.5
+++ libconcord/hid.h4 Apr 2008 07:05:50 -
@@ -40,6 +40,6 @@ void ShutdownUSB();
int FindRemote(THIDINFO hid_info);
int HID_WriteReport(const uint8_t *data);
-int HID_ReadReport(uint8_t *data, unsigned int timeout=500);
+int HID_ReadReport(uint8_t *data, unsigned int timeout = 500);
#endif
Index: libconcord/libconcord.cpp
===
RCS file: /cvsroot/concordance/concordance/libconcord/libconcord.cpp,v
retrieving revision 1.24
diff -u -p -r1.24 libconcord.cpp
--- libconcord/libconcord.cpp 4 Apr 2008 05:21:03 - 1.24
+++ libconcord/libconcord.cpp 4 Apr 2008 07:05:51 -
@@ -1055,12 +1055,19 @@ int finish_firmware()
return LC_ERROR;
} else {
data[0] = 0x02;
- if ((err = rmt-WriteRam(0, 1, data)))
+ if ((err = rmt-WriteRam(0, 1, data))) {
+ debug(Failed to write 2 to RAM 0);
return LC_ERROR_WRITE;
- if ((err = rmt-ReadRam(0, 1, data)))
+ }
+ if ((err = rmt-ReadRam(0, 1, data))) {
+ debug(Failed to from RAM 0);
return LC_ERROR_WRITE;
- if (data[0] != 2)
+ }
+ if (data[0] != 2) {
+ printf(byte is %d\n,data[0]);
+ debug(Finalize byte didn't match);
return LC_ERROR_VERIFY;
+ }
}
return 0;
Index: libconcord/remote.cpp
===
RCS file: /cvsroot/concordance/concordance/libconcord/remote.cpp,v
retrieving revision 1.29
diff -u -p -r1.29 remote.cpp
--- libconcord/remote.cpp 3 Apr 2008 07:01:46 - 1.29
+++ libconcord/remote.cpp 4 Apr 2008 07:05:51 -
@@ -68,7 +68,7 @@ void make_serial(uint8_t *ser, TRemoteIn
int CRemote::Reset(uint8_t kind)
{
- uint8_t reset_cmd[] = { 0, COMMAND_RESET, kind };
+ uint8_t reset_cmd[] = { COMMAND_RESET, kind };
return HID_WriteReport(reset_cmd);
}
@@ -84,7 +84,7 @@ int CRemote::GetIdentity(TRemoteInfo ri
int err = 0;
uint32_t cb_count = 0;
- const uint8_t qid[] = { 0x00, COMMAND_GET_VERSION };
+ const uint8_t qid[] = { COMMAND_GET_VERSION };
if ((err = HID_WriteReport(qid))) {
debug(Failed to write to remote);
@@ -100,31 +100,31 @@ int CRemote::GetIdentity(TRemoteInfo ri
/*
* See specs/protocol.txt for format
*/
- const unsigned int rx_len = rsp[1] 0x0F;
+ const unsigned int rx_len = rsp[0] 0x0F;
- if ((rsp[1] 0xF0) != RESPONSE_VERSION_DATA ||
+ if ((rsp[0] 0xF0) != RESPONSE_VERSION_DATA ||
(rx_len != 7 rx_len != 5)) {
debug(Bogus ident response: %02X, rsp[1]);
return LC_ERROR_INVALID_DATA_FROM_REMOTE;
}
- ri.fw_ver_major = rsp[2] 4;
- ri.fw_ver_minor = rsp[2] 0x0F;
- ri.hw_ver_major = rsp[3] 4;
- ri.hw_ver_minor = rsp[3] 0x0F;
- ri.flash_id = rsp[4];
- ri.flash_mfg = rsp[5];
- ri.architecture = rx_len 6 ? 2 : rsp[6] 4;
- ri.fw_type = rx_len 6 ? 0 : rsp[6] 0x0F;
- ri.skin = rx_len 6 ? 2 : rsp[7];
- ri.protocol = rx_len 7 ? 0 : rsp[8];
+ ri.fw_ver_major = rsp[1] 4;
+ ri.fw_ver_minor = rsp[1] 0x0F;
+ ri.hw_ver_major = rsp[2] 4;
+ ri.hw_ver_minor = rsp[2] 0x0F;
+ ri.flash_id = rsp[3];
+ ri.flash_mfg = rsp[4];
+ ri.architecture = rx_len 6 ? 2 : rsp[5] 4;
+ ri.fw_type = rx_len 6 ? 0 : rsp[5] 0x0F;
+ ri.skin = rx_len 6 ? 2 : rsp[6];
+ ri.protocol = rx_len 7 ? 0 : rsp[7];
setup_ri_pointers(ri);
- //printf(Reading Flash... );
uint8_t rd[1024];
if ((err=ReadFlash(ri.arch-config_base, 1024, rd, ri.protocol,
Re: [concordance-devel] RFC: Changing the usb read/writes
On Fri, April 4, 2008 3:19 am, Phil Dibowitz wrote: Stephen Warren wrote: Here's an updated version of the USB patch that works with WinHID on Windows. I had to fix: HID_WriteReport: MS compiler won't allow creation of a variable-sized array on the stack, so I made the code new/delete it instead. You changed if (Write...) to an ret = Write(..); if (err), which seemed odd to me, so I changed it back. Oops. I originally had the delete[] call between those two lines, but of course that broke, because the code uses asynchronous IO, so the delete needs to happen after the event wait. I evidently forgot revert the change when I did that. Did you also remove the ret variable? I added that just for that change, I think. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] API to identify file type
Stephen Warren wrote:
On Wed, April 2, 2008 2:36 am, Phil Dibowitz wrote:
Stephen Warren wrote:
In congruity, I have some code to identify the action to take for a
specific EzHex/EZUp file, without relying on any facet of the filename.
I'm curious as to what you use to figure it out... there are some tells
like firmware has 'TYPEFirmware_Main/TYPE' ... but not all
of them are so straight forward - did you just pick a unique option
from each file?
...
I can post more details (e.g. a patch to just add the libconcord function)
when I'm back home and have access to the code, since that part is already
working, except for IR learn.
Here's an early version of the patch. It's not yet suitable for merging;
it doesn't yet do IR learn stuff, and I haven't tested it since the
latest CVS updates. That said, it should give an idea where I'm going if
you want to comment on it.
? concordance/.deps
? concordance/.libs
? concordance/Makefile
? concordance/Makefile.in
? concordance/aclocal.m4
? concordance/autom4te.cache
? concordance/concordance
? concordance/config.guess
? concordance/config.h
? concordance/config.h.in
? concordance/config.log
? concordance/config.status
? concordance/config.sub
? concordance/configure
? concordance/depcomp
? concordance/dummy.c
? concordance/install-sh
? concordance/libtool
? concordance/ltmain.sh
? concordance/missing
? concordance/stamp-h1
? libconcord/.deps
? libconcord/.libs
? libconcord/Makefile
? libconcord/Makefile.in
? libconcord/aclocal.m4
? libconcord/autom4te.cache
? libconcord/binaryfile.lo
? libconcord/config.guess
? libconcord/config.h
? libconcord/config.h.in
? libconcord/config.log
? libconcord/config.status
? libconcord/config.sub
? libconcord/configure
? libconcord/depcomp
? libconcord/install-sh
? libconcord/libconcord.la
? libconcord/libconcord.lo
? libconcord/libtool
? libconcord/libusbhid.lo
? libconcord/ltmain.sh
? libconcord/missing
? libconcord/remote.lo
? libconcord/remote_z.lo
? libconcord/stamp-h1
? libconcord/usblan.lo
? libconcord/web.lo
Index: libconcord/libconcord.cpp
===
RCS file: /cvsroot/concordance/concordance/libconcord/libconcord.cpp,v
retrieving revision 1.22
diff -u -p -r1.22 libconcord.cpp
--- libconcord/libconcord.cpp 3 Apr 2008 02:28:20 - 1.22
+++ libconcord/libconcord.cpp 3 Apr 2008 06:04:17 -
@@ -320,6 +320,98 @@ void delete_blob(uint8_t *ptr)
delete[] ptr;
}
+int identify_file(uint8_t *in, uint32_t size)
+{
+ int err;
+
+ /*
+ * Validate this is a remotely sane XML file
+ */
+ uint8_t *start_info_ptr;
+err = GetTag(INFORMATION, in, size, start_info_ptr);
+ if (err == -1) {
+ return TYPE_UNKNOWN;
+ }
+
+ uint8_t *end_info_ptr;
+err = GetTag(/INFORMATION, in, size, end_info_ptr);
+ if (err == -1) {
+ return TYPE_UNKNOWN;
+ }
+
+ /*
+ * Determine size of binary data following /INFORMATION
+ */
+ uint32_t data_len = size - (end_info_ptr - in);
+ /*
+ * Account for CRLF after /INFORMATION
+ * But, don't screw up if it's missing
+ */
+ if (data_len = 2) {
+ data_len -= 2;
+ }
+
+ /*
+ * Search for tag only in connectivity test files
+ */
+ bool found_get_zaps_only = false;
+ uint8_t *tmp_data = in;
+ uint32_t tmp_size = size - data_len;
+ while (1) {
+ uint8_t *tag_ptr;
+ string tag_s;
+ err = GetTag(KEY, tmp_data, tmp_size, tag_ptr, tag_s);
+ if (err == -1) {
+ break;
+ }
+ if (!stricmp(tag_s.c_str(), GETZAPSONLY)) {
+ found_get_zaps_only = true;
+ break;
+ }
+ tmp_data = tag_ptr + tag_s.length();
+ tmp_size = end_info_ptr - tmp_data;
+ }
+
+ /*
+ * Search for tag only in firmware files
+ */
+ bool found_firmware = false;
+ tmp_data = in;
+ tmp_size = size - data_len;
+ while (1) {
+ uint8_t *tag_ptr;
+ string tag_s;
+ err = GetTag(TYPE, tmp_data, tmp_size, tag_ptr, tag_s);
+ if (err == -1) {
+ break;
+ }
+ if (!stricmp(tag_s.c_str(), Firmware_Main)) {
+ found_firmware = true;
+ break;
+ }
+ tmp_data = tag_ptr + tag_s.length();
+ tmp_size = end_info_ptr - tmp_data;
+ }
+
+ /*
+ * Check tag search results for consistency, and deduce the file type
+ */
+ if (found_get_zaps_only !data_len !found_firmware) {
+ return TYPE_CONNECTIVITY;
+ }
+ if (!found_get_zaps_only (data_len = 16) !found_firmware) {
+ return TYPE_CONFIGURATION;
+ }
+ if (!found_get_zaps_only !data_len found_firmware) {
+ return TYPE_FIRMWARE;
+ }
+
+ /*
+ * Findings didn't match a single file type; indicate a problem
+ */
+ return TYPE_UNKNOWN;
+}
+
/*
* Common routine to read contents of file named *file_name into
* byte buffer **out. Get size from file and return out[size]
Index: libconcord/libconcord.h
===
RCS file: /cvsroot/concordance/concordance/libconcord/libconcord.h,v
retrieving revision 1.15
diff -u -p -r1.15 libconcord.h
--- libconcord/libconcord.h 3 Apr 2008 02:28:20 - 1.15
+++ libconcord/libconcord.h 3 Apr 2008 06:04:17 -
@@ -152,6
Re: [concordance-devel] API for the blob
Phil Dibowitz wrote: What about passing around a void* like I suggested with the size and all hidden inside of but an export_blob() API that dumps it to something easy - such as our uint8_t* with a size, and of course an import_blob() to go with? Initially this will be kinda of silly because the internal representation will be identical, but it gives us the freedom to change at will and the flexibility to let users hack on stuff. FURTHER, it means they'll never screw with OUR copy of the data - they have to *ask* us to take it via import_blob(), so we can do some sanity checking and such if we'd like. Yeah, I guess that would work. So I guess we'd end up with something very roughly like: // could read() or mmap() read_blob_from_file(filename, out_blob) // create blob referencing (or taking copy of) user-supplied data make_blob_from_data(data, size, out_blob) // copy data from blob into new buffer copy_data_from_blob(blob, out_data, out_size) // must know which API created it, to know how to destroy it; // kinda like a virtual destructor destroy_blob() erase_config() write_config_to_remote(blob) erase_firmware() write_firmware_to_remote(blob) In other words, extract_firmware_binary would be folded into the internal implementation of write_firmware_to_remote, and similar for find_config_binary/write_config_to_remote? - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Patch: vi modelines for all source files
On Wed, April 2, 2008 2:22 am, Phil Dibowitz wrote: Stephen Warren wrote: Phil Dibowitz wrote: Stephen Warren wrote: Attached is a patch that adds the following line to the end of all This doesn't seem to actually work for me. The weird thing is I've been playing with it for a while and I can't seem to make it work. I have perl files where I have similar modelines and when I type longer than 78 or 80 characters (with spaces in the line), it breaks the line after I reach that point, but this doesn't. I'm not entirely sure why. Huh. I tested the expandtab and shiftwidth settings on libconcord.h, and those worked for me (at least before I moved them to the top of the file) (I have different defaults than those in .vimrc), but not the wrapping option. I'll take a look at what's up tonight/tomorrow. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] API to identify file type
On Wed, April 2, 2008 2:36 am, Phil Dibowitz wrote:
Stephen Warren wrote:
In congruity, I have some code to identify the action to take for a
specific EzHex/EZUp file, without relying on any facet of the filename.
I'm curious as to what you use to figure it out... there are some tells
like firmware has 'TYPEFirmware_Main/TYPE' ... but not all
of them are so straight forward - did you just pick a unique option
from each file?
Yes, pretty much. The algorithm will be the same as the current Python
code in congruity, with the addition of validating that there really is an
INFORMATION tag, and IR learn detection, which congruity didn't have.
I can post more details (e.g. a patch to just add the libconcord function)
when I'm back home and have access to the code, since that part is already
working, except for IR learn.
Looks good to me. Obviously we'll have to read in the file significantly
earlier inside of concordance. I don't think that's a problem, but
exactly where is interesting. We could do it in parse_options *if* we
happen to be in auto_mode (where we currently do the filename matching
stuff), but then we have to know if we've read it in or not and read it
in later as necessary. That's sub-optimal.
Yes, I hacked it in place of the file name munging code in concordance.c
for testing, but certainly wouldn't advocate checking that change in.
Your code flow suggestions sound good.
In fact, we could even use the appropriate MODE_* defines as the
filetype defines if we want (obviously we wouldn't use them all, just
MODE_WRITE_* and MODE_LEARN_IR).
Well, we'd need to be careful that application operation mode definitions
don't creep into libconcord.h, so (from memory of the code) I imagine that
we'd end up with libconcord.h only defining the file types, and
concordance.c having a switch to map them.
So as I've worked on the XS perl wrappers (finally got everything working
tonight I think, now I'm just cleaning stuff up),
From my limited knowledge of XS, I jokingly suggest it would have been
easier to port Python's ctypes module to Perl and use that instead, rather
than suffering XS:-) [Actually, all joking aside, I'm sure the Perl
community would love a ctypes module, but that's a whole other project].
I've been thinking about the API, and I'm starting to think more and
more that all our uint8_t* and uint32_t* stuff really should just be a
void* blob which is internally a structure with the uint8_t* and the
size inside of it. Not only do I think of that array as a opaque blob
to the user, but I don't want our API/ABI to have to change when we
make it into an mmap pointer or some other thing.
Well, on all platforms, mmap (or the equivalent) will always map the file
to some memory location, so we can always have a pointer and size. What is
different, is that we may need extra information to manage the mapping.
Equally, I do believe we want the client app to be able to access (read)
the raw file data (or parsed binary data etc.) directly, if for no other
reason than e.g. writing an app that uses libconcord to load/parse a file,
then the app can hexdump/disassemble/... the binary data, or something
like that.
So, what I would suggest is this:
APIs use a public structure:
struct Data {
uint8_t *data;
uint32_t data_size;
};
and we pass Data* to in-to/out-from APIs (no doubt we'd pick a better
name).
However, internally, we would allocate something like:
struct DataInternal {
Data public;
// Internal only information follow
#if defined(WIN32)
HANDLE h; // or whatever, for Win32
#else
int fd; // Unix mmap fd handle, or whatever
#endif
};
Then, our APIs work like this:
int func1(Data **data)
{
DataInternal *dataint = (DataInternal *)malloc(sizeof(DataInternal));
*data = (Data*)dataint;
dataint-member = whatever;
...
}
int func2(Data *data)
{
DataInternal *dataint = (DataInternal *)data;
...
}
This allows us to hide arbitrary hidden/internal information in the same
handle that the client app sees, whilst still allowing the app simple
access to what it might care about.
We can always expand DataInt (outside the Data part) to add new internal
information without breaking binary compatibility.
We can even expand Data by simply adding fields, although this will
obviously break client binary compatibility.
Alternatively, we could do this:
struct Data {
uint8_t *data;
uint32_t data_size;
void *priv;
};
... and allocate a separate priv structure and point the public structure
at it. I like this a little less because:
a) We have to make 2 allocations
b) The client can see the priv member, which it doesn't care about.
c) The client could screw with the priv member, and point it somewhere else.
Actually, I'd also like to consider the case of an app that internally
creates an EZHex file in memory and passes this into libconcord. I guess
to support this, all we would need to add is an API like
create_Data_struct_from_memory_region, that remembers
Re: [concordance-devel] RFC: Changing the usb read/writes
Phil Dibowitz wrote: ... So I plan to switch this. Everywhere a USB message is constructed I'll NOT include the extra 0-byte and then I'll ADD a 0-byte in the Windows code. Does anyone have any objections to this or concerns? Sounds like a great idea to me - I was a little confused by the extra bytes at first. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] Request for EZHex files
I'm writing some code to identify what to do with EZHex/EZUp files downloaded from the Logitech website. I just realized I've never seen a learn IR command file (I have connectivity, config update, and firmware all working). Does anyone have any learn IR files for various remotes they could mail to me, or let me download? Thanks. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Build failure with latest CVS
On Sun, March 30, 2008 11:41 pm, Phil Dibowitz wrote: And again, you missed what I said about declarations not at the top. This is why we use -ansi -pedantic-errors: [EMAIL PROTECTED] tmp]$ gcc -std=c99 foo.c [EMAIL PROTECTED] tmp]$ gcc -std=c99 -pedantic-errors foo.c [EMAIL PROTECTED] tmp]$ gcc -ansi -pedantic-errors foo.c foo.c: In function 'main': foo.c:9: error: ISO C90 forbids mixed declarations and code [EMAIL PROTECTED] tmp]$ It's the ONLY combination that seems to catch that error. Yes, but: a) There's no reason to care about this, because like I said, I believe we can fix the Windows build issues by building concordance.c as C++ instead of C. b) Those gcc options cause gcc (some versions, e.g. 4.1.x, 4.3.x) to fail to build concordance. Do we really want to prevent compilation on Linux just so it works on Windows? - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] Patches: Windows build fixes
I built libconcord under Windows in preparation for testing congruity
there, and found some issues. Attached are the fixes:
1) When I changed libconcord.h, I didn't update the Windows .def file.
The attached concordance-win-def.patch does this.
2) Marco should comment on this:
Both libconcord_winhid and concordance (and possibly other Window
projects I didn't build) attempt to link against odbc32.lib and
odbccp32.lib. I don't have either of these in Visual C++ Express 2005.
So, I removed them from the link line, and everything appears to link
fine (have not tested execution yet). Hopefully, these libraries are
there just because default projects are set up this way? Since ODBC is a
database access library, I can't see why libconcord would need it... See
attached concordance-win-odbc.patch (which should probably be expanded
to the other vcproj files too)
Index: concordance/win/concordance.vcproj
===
RCS file: /cvsroot/concordance/concordance/concordance/win/concordance.vcproj,v
retrieving revision 1.4
diff -u -p -r1.4 concordance.vcproj
--- concordance/win/concordance.vcproj 26 Mar 2008 01:30:46 - 1.4
+++ concordance/win/concordance.vcproj 30 Mar 2008 06:32:11 -
@@ -1,7 +1,7 @@
?xml version=1.0 encoding=Windows-1252?
VisualStudioProject
ProjectType=Visual C++
- Version=8,00
+ Version=8.00
Name=concordance
ProjectGUID={472FC1A1-C379-4F65-AFD1-41996F052726}
@@ -160,7 +160,7 @@
/
Tool
Name=VCLinkerTool
- AdditionalDependencies=./Debug/libconcord.lib
ws2_32.lib odbc32.lib odbccp32.lib
+ AdditionalDependencies=./Debug/libconcord.lib
ws2_32.lib
OutputFile=.\Debug/concordance.exe
LinkIncremental=2
SuppressStartupBanner=true
Index: libconcord/win/libconcord_winhid.vcproj
===
RCS file:
/cvsroot/concordance/concordance/libconcord/win/libconcord_winhid.vcproj,v
retrieving revision 1.4
diff -u -p -r1.4 libconcord_winhid.vcproj
--- libconcord/win/libconcord_winhid.vcproj 26 Mar 2008 01:30:46 -
1.4
+++ libconcord/win/libconcord_winhid.vcproj 30 Mar 2008 06:32:12 -
@@ -1,7 +1,7 @@
?xml version=1.0 encoding=Windows-1252?
VisualStudioProject
ProjectType=Visual C++
- Version=8,00
+ Version=8.00
Name=libconcord_winhid
ProjectGUID={0665485E-2249-4FD8-BE9C-CCC0C3BBF3A8}
@@ -72,7 +72,7 @@
/
Tool
Name=VCLinkerTool
- AdditionalDependencies=ws2_32.lib odbc32.lib
odbccp32.lib
+ AdditionalDependencies=ws2_32.lib
OutputFile=Debug/libconcord_winhid/libconcord.dll
LinkIncremental=2
SuppressStartupBanner=true
Index: libconcord/win/libconcord.def
===
RCS file: /cvsroot/concordance/concordance/libconcord/win/libconcord.def,v
retrieving revision 1.5
diff -u -p -r1.5 libconcord.def
--- libconcord/win/libconcord.def 14 Mar 2008 05:01:26 - 1.5
+++ libconcord/win/libconcord.def 30 Mar 2008 06:32:12 -
@@ -68,11 +68,9 @@ read_config_from_remote
write_config_to_remote
read_config_from_file
write_config_to_file
-verify_xml_config
verify_remote_config
erase_config
-find_config_binary_size
-find_config_binary_start
+find_config_binary
; SAFEMODE FIRMWARE INTERACTIONS
;
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] New feature that we should probably have
Phil Dibowitz wrote: Stephen Warren wrote: I've sent the logs to you directly off-list, due to size. Thanks. A few questions - your tarball had log2 and log3 (with 3 being empty), but no log1 - was that on purpose? Also, is this writing a config, or firmware? It looks like config. Seems simple, though... TOO simple. Write config. When the USB sniffer starts up, it starts capturing log1, but automatically creates a new log when you plug/replug the device, so log2 started when I actually plugged in the Harmony, and log3 due to the reboot that the Logitech software does at the end of the programming. My *suspicion* (which is purely a guess) is that libconcord attempts to always acquire a ton of information at attach time, some of which may be impossible to acquire if the config is invalid, but the Logitech application probably only doesn't bother with getting all that info (probably, a bunch of it is only useful for concordance -v -i, and not a simple action like config programming?) - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Patches: Windows build fixes
Phil Dibowitz wrote: Stephen Warren wrote: Both libconcord_winhid and concordance (and possibly other Window projects I didn't build) attempt to link against odbc32.lib and odbccp32.lib. I don't have either of these in Visual C++ Express 2005. No apply: Hunk #1 FAILED at 1. Hunk #2 FAILED at 160. Hunk #1 FAILED at 1. Hunk #2 FAILED at 72. Must be some CRLF/LF issue with CVS under Cygwin on Windows I guess. I'll see if I can work up patch in a saner format. I need a separate Windows machine instead of rebooting all the time... - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Patches: Windows build fixes
Stephen Warren wrote: Phil Dibowitz wrote: Stephen Warren wrote: Both libconcord_winhid and concordance (and possibly other Window projects I didn't build) attempt to link against odbc32.lib and odbccp32.lib. I don't have either of these in Visual C++ Express 2005. No apply: It looks like CVS diffs from Windows won't apply on Linux, and vice-versa, due to end-of-line issues. So, attached are: 1) I manually edited the files on Linux and made the patch there. Probably this will apply OK for you. However, I can't apply it on my Windows machine, so this patch is untested. 2) Verbatim copies of the 3 modified vcproj files that I have built on Windows just fine. You can just copy these over the top of the relevant files in your CVS tree and check in; it looks like this is how you get files from Marco anyway... ? concordance/.deps ? concordance/.libs ? concordance/Makefile ? concordance/Makefile.in ? concordance/aclocal.m4 ? concordance/autom4te.cache ? concordance/concordance ? concordance/config.guess ? concordance/config.h ? concordance/config.h.in ? concordance/config.log ? concordance/config.status ? concordance/config.sub ? concordance/configure ? concordance/depcomp ? concordance/install-sh ? concordance/libtool ? concordance/ltmain.sh ? concordance/missing ? concordance/stamp-h1 ? concordance/win/.concordance.vcproj.swp ? consnoop/USBLog2.txt ? consnoop/USBLog2.usblog ? consnoop/USBLog2.xml ? consnoop/USBLog3.txt ? consnoop/USBLog3.usblog ? consnoop/USBLog3.xml ? consnoop/consnoop ? consnoop/recovery.tbz2 ? libconcord/.deps ? libconcord/.libs ? libconcord/Makefile ? libconcord/Makefile.in ? libconcord/aclocal.m4 ? libconcord/autom4te.cache ? libconcord/binaryfile.lo ? libconcord/config.guess ? libconcord/config.h ? libconcord/config.h.in ? libconcord/config.log ? libconcord/config.status ? libconcord/config.sub ? libconcord/configure ? libconcord/depcomp ? libconcord/install-sh ? libconcord/libconcord.la ? libconcord/libconcord.lo ? libconcord/libtool ? libconcord/libusbhid.lo ? libconcord/ltmain.sh ? libconcord/missing ? libconcord/remote.lo ? libconcord/remote_z.lo ? libconcord/stamp-h1 ? libconcord/usblan.lo ? libconcord/web.lo ? libconcord/win/.libconcord_libusb.vcproj.swp ? libconcord/win/.libconcord_winhid.vcproj.swp Index: concordance/win/concordance.vcproj === RCS file: /cvsroot/concordance/concordance/concordance/win/concordance.vcproj,v retrieving revision 1.4 diff -u -p -r1.4 concordance.vcproj --- concordance/win/concordance.vcproj 26 Mar 2008 01:30:46 - 1.4 +++ concordance/win/concordance.vcproj 30 Mar 2008 19:03:22 - @@ -69,7 +69,7 @@ / Tool Name=VCLinkerTool - AdditionalDependencies=./Release/libconcord.lib ws2_32.lib odbc32.lib odbccp32.lib + AdditionalDependencies=./Release/libconcord.lib ws2_32.lib OutputFile=.\Release/concordance.exe LinkIncremental=1 SuppressStartupBanner=true @@ -160,7 +160,7 @@ / Tool Name=VCLinkerTool - AdditionalDependencies=./Debug/libconcord.lib ws2_32.lib odbc32.lib odbccp32.lib + AdditionalDependencies=./Debug/libconcord.lib ws2_32.lib OutputFile=.\Debug/concordance.exe LinkIncremental=2 SuppressStartupBanner=true Index: libconcord/win/libconcord_libusb.vcproj === RCS file: /cvsroot/concordance/concordance/libconcord/win/libconcord_libusb.vcproj,v retrieving revision 1.4 diff -u -p -r1.4 libconcord_libusb.vcproj --- libconcord/win/libconcord_libusb.vcproj 26 Mar 2008 01:30:46 - 1.4 +++ libconcord/win/libconcord_libusb.vcproj 30 Mar 2008 19:03:22 - @@ -72,7 +72,7 @@ / Tool Name=VCLinkerTool - AdditionalDependencies=ws2_32.lib odbc32.lib odbccp32.lib + AdditionalDependencies=ws2_32.lib OutputFile=Release/libconcord_libusb/libconcord.dll LinkIncremental=1 SuppressStartupBanner=true @@ -169,7 +169,7 @@ / Tool Name=VCLinkerTool - AdditionalDependencies=ws2_32.lib odbc32.lib odbccp32.lib + AdditionalDependencies=ws2_32.lib OutputFile=Debug/libconcord_libusb/libconcord.dll
[concordance-devel] Build failure with latest CVS
Latest libconcord.h contains:
static inline void debug(const char *str) {}
This causes a build failure because inline isn't a valid keyword in
standard ANSI C. Simply removing inline seems to fix the problem.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Build failure with latest CVS
Phil Dibowitz wrote:
Stephen Warren wrote:
Latest libconcord.h contains:
static inline void debug(const char *str) {}
This causes a build failure because inline isn't a valid keyword in
standard ANSI C. Simply removing inline seems to fix the problem.
Already fixed...
I still get this:
gcc -DHAVE_CONFIG_H -I.-Wall -ansi -pedantic-errors -ggdb
-I../libconcord -MT concordance-concordance.o -MD -MP -MF
.deps/concordance-concordance.Tpo -c -o concordance-concordance.o `test
-f 'concordance.c' || echo './'`concordance.c
In file included from concordance.c:21:
../libconcord/libconcord.h:47:19: error: anonymous variadic macros were
introduced in C99
[EMAIL PROTECTED] concordance]$ gcc --version
gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)
(Fedora 8 with all updates)
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Build failure with latest CVS
Stephen Warren wrote:
Phil Dibowitz wrote:
Stephen Warren wrote:
Latest libconcord.h contains:
static inline void debug(const char *str) {}
This causes a build failure because inline isn't a valid keyword in
standard ANSI C. Simply removing inline seems to fix the problem.
Already fixed...
I still get this:
../libconcord/libconcord.h:47:19: error: anonymous variadic macros were
introduced in C99
This, and the missing strdup prototype, are both direct fallouts of
using the -ansi -pedantic-errors compiler flags.
We only do this to ensure we don't use C99 constructs, so we can build
with Microsoft compilers that don't support C99.
I propose we replace -ansi -pedantic-errors with -std=c99. I believe
we can solve any subsequent Windows build problems by forcing
concordance.c to be built as C++ instead of C when compiling on Windows,
since most of C99 is in C++.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Build failure with latest CVS
Stephen Warren wrote: I propose we replace -ansi -pedantic-errors with -std=c99. Sorry, just remove -ansi -pedantic-errors and don't add -std=c99; the variadic macro works with -std=c99, but the strdup prototype still isn't present unless we just remove all the standard-selection options. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] Patch Python bindings for libconcord
Phil,
Attached is a file that exposes Python bindings for libconcord, up to
date with the latest CVS, and (partially) tested using congruity.
I propose we place it into libconcord/bindings/python/libconcord.py.
Unfortunately, I can't send a cvs diff, because I can't cvs add the file
because I don't have write access to the repository, and even the -N
option to cvs diff will only see cvs add'd files!
Re: The license. I suppose since this file is essentially derived from
libconcord.h, it must be GPL 3? If so, are you OK with it being LGPL 3
instead of full GPL 3, to allow non-GPL applications to use it? Either
way, feel free to replace the license header as needed for you to commit it.
Hopefully if the file is in the concordance repository, changes to
libconcord.h will be reflected there too (or at least, I'll send you
patches before header updates make it into an official release.)
# This code NOT copyright Stephen Warren [EMAIL PROTECTED]
# This code is released into the public domain.
from ctypes import *
import platform
import sys
# Internal DLL handle
if platform.system() == 'Windows':
_dll = cdll.LoadLibrary('libconcord.dll')
else:
_dll = cdll.LoadLibrary('libconcord.so.0')
# This exception may be raised by any function that returns an LC_ERROR_*.
class LibConcordException(Exception):
def __init__(self, func, result):
self.func = func
self.result = result
try:
self.result_str = c_char_p(_dll.lc_strerror(c_int(self.result))).value
except:
self.result_str = 'Unknown'
def __str__(self):
return 'libconcord function %s failed with error code %s (%s)' % (
repr(self.func),
repr(self.result),
repr(self.result_str)
)
# Internal function result checking functionality
class _CheckRetCode(object):
def __init__(self, func_name):
self.func_name = func_name
def __call__(self, *args):
result = args[0]
if result != 0:
raise LibConcordException(self.func_name, result)
# Internal ctypes function wrapper creation
def _create_func(
func_name,
error_checker,
*args
):
ftype = CFUNCTYPE(*args)
f = ftype((func_name, _dll))
if error_checker:
f.errcheck = error_checker(func_name)
return f
# typedef void (*lc_callback)(uint32_t, uint32_t, uint32_t, void*);
callback_type = CFUNCTYPE(None, c_uint, c_uint, c_uint, py_object)
# const char *get_mfg();
get_mfg = _create_func(
'get_mfg',
None,
c_char_p
)
# const char *get_model();
get_model = _create_func(
'get_model',
None,
c_char_p
)
# const char *get_codename();
get_codename = _create_func(
'get_codename',
None,
c_char_p
)
# int get_skin();
get_skin = _create_func(
'get_skin',
None,
c_int
)
# int get_fw_ver_maj();
get_fw_ver_maj = _create_func(
'get_fw_ver_maj',
None,
c_int
)
# int get_fw_ver_min();
get_fw_ver_min = _create_func(
'get_fw_ver_min',
None,
c_int
)
# int get_fw_type();
get_fw_type = _create_func(
'get_fw_type',
None,
c_int
)
# int get_hw_ver_maj();
get_hw_ver_maj = _create_func(
'get_hw_ver_maj',
None,
c_int
)
# int get_hw_ver_min();
get_hw_ver_min = _create_func(
'get_hw_ver_min',
None,
c_int
)
# int get_flash_size();
get_flash_size = _create_func(
'get_flash_size',
None,
c_int
)
# int get_flash_mfg();
get_flash_mfg = _create_func(
'get_flash_mfg',
None,
c_int
)
# int get_flash_id();
get_flash_id = _create_func(
'get_flash_id',
None,
c_int
)
# const char *get_flash_part_num();
get_flash_part_num = _create_func(
'get_flash_part_num',
None,
c_char_p
)
# int get_arch();
get_arch = _create_func(
'get_arch',
None,
c_int
)
# int get_proto();
get_proto = _create_func(
'get_proto',
None,
c_int
)
# const char *get_hid_mfg_str();
get_hid_mfg_str = _create_func(
'get_hid_mfg_str',
None,
c_char_p
)
# const char *get_hid_prod_str();
get_hid_prod_str = _create_func(
'get_hid_prod_str',
None,
c_int
)
# int get_hid_irl();
get_hid_irl = _create_func(
'get_hid_irl',
None,
c_int
)
# int get_hid_orl();
get_hid_orl = _create_func(
'get_hid_orl',
None,
c_int
)
# int get_hid_frl();
get_hid_frl = _create_func(
'get_hid_frl',
None,
c_int
)
# int get_usb_vid();
get_usb_vid = _create_func(
'get_usb_vid',
None,
c_int
)
# int get_usb_pid();
get_usb_pid = _create_func(
'get_usb_pid',
None,
c_int
)
# int get_usb_bcd();
get_usb_bcd = _create_func(
'get_usb_bcd',
None,
c_int
)
SERIAL_COMPONENT_1 = 1
SERIAL_COMPONENT_2 = 2
SERIAL_COMPONENT_3 = 3
# char *get_serial(int p);
get_serial = _create_func(
'get_serial',
None,
c_char_p,
c_int
)
# int get_config_bytes_used();
get_config_bytes_used = _create_func(
'get_config_bytes_used',
None,
c_int
)
# int
Re: [concordance-devel] Build failure with latest CVS
Phil Dibowitz wrote: Stephen Warren wrote: Stephen Warren wrote: I propose we replace -ansi -pedantic-errors with -std=c99. Sorry, just remove -ansi -pedantic-errors and don't add -std=c99; the variadic macro works with -std=c99, but the strdup prototype still isn't present unless we just remove all the standard-selection options. Nope, -ansi is an alias for -std=c99 which DOES NOT error on stuff like variables not at the top. -pedantic-errors is required. -ansi is NOT -std=c99. ANSI C (1989) was standardized way before C99 (1999). See the build logs below. See http://en.wikipedia.org/wiki/C_%28programming_language%29 [EMAIL PROTECTED] concordance]$ gcc -DHAVE_CONFIG_H -I.-Wall -ansi -pedantic-errors -ggdb -I../libconcord -MT concordance-concordance.o -MD -MP -MF .deps/concordance-concordance.Tpo -c -o concordance-concordance.o concordance.c In file included from concordance.c:21: ../libconcord/libconcord.h:47:19: error: anonymous variadic macros were introduced in C99 concordance.c: In function ‘parse_options’: concordance.c:589: warning: implicit declaration of function ‘strdup’ [EMAIL PROTECTED] concordance]$ gcc -DHAVE_CONFIG_H -I.-Wall -std=c99 -pedantic-errors -ggdb -I../libconcord -MT concordance-concordance.o -MD -MP -MF .deps/concordance-concordance.Tpo -c -o concordance-concordance.o concordance.c concordance.c: In function ‘parse_options’: concordance.c:589: warning: implicit declaration of function ‘strdup’ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Patch: Add size parameters to *all* APIs
Phil Dibowitz wrote: Stephen Warren wrote: Phil Dibowitz wrote: One comment on ** vs *. The code tends to use * in any non-public API, and ** only for public functions since C requires that. You converted various private APIs to **, and I prefer to leave them * to be consistent with the entire rest of the codebase. Only the actual libconcord.h API gets **, and that header file is in fact the dividing line. So I'd like that reversed. But but you let me get away with it for GetTag :-) :-) Anyway, I've reverted those changes. Well, you reverted MOST of them. I reverted GetTag for you. Oh, I thought you'd previously said you were OK with GetTag working that way. I guess you meant the separation of in/out parameters rather than *-** change. Never mind! - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] concordance configure question
Is it possible to add a --with-libconcord=/path/to/it option to concordance's configure script? The reason is that I typically build, but don't install, libconcord, then build concordance against it, using a configure command like this: CFLAGS=-ggdb -I../libconcord LDFLAGS=-L../libconcord/.libs ./configure It'd be a little simpler to do this instead: CFLAGS=-ggdb ./configure --with-libconcord=../libconcord or something like that to tell it to go grovel in the source directory. This would also help with actual installs in non-standard locations (I'd probably install into ~/something to avoid polluting system directories during development) - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] -ansi and strdup prototype
Under Fedora 8 at least (and I'm sure others), compiling concordance.c gives this warning: concordance.c: In function ‘parse_options’: concordance.c:589: warning: implicit declaration of function 'strdup' Theoretically, strdup is prototyped by the include of string.h. However, since concordance is built with -ansi, this prevents string.h prototyping strdup, since it isn't actually an ANSI standard function. It looks like one can define things like _SVID_SOURCE to request SVID extensions, (or other macros for other extensions that also define strdup), to request a prototype of the function. Or, perhaps switch -ansi to something else. The warning isn't a big deal, but I think gcc 4.3 will error in this situation instead of warning, which will fail concordance builds for Fedora 9... - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] concordance configure question
Phil Dibowitz wrote: Stephen Warren wrote: Is it possible to add a --with-libconcord=/path/to/it option to concordance's configure script? I'd be happy to. I gotta remember how to do that with autoconf, shouldn't be hard. Keep in mind that you won't be able to do --with-libconcord=../libconcord since it puts stuff in .libs - you'd have to do a make install into /tmp/libconcord or something, and then do --with-libconcord=/tmp/libconcord. The --with-something options to autoconf assume that dir/lib is where the library will be and dir/include is where the header files will be... Maybe we could also have a --with-developer-tree option that knows it's ../libconcord and .libs for LDFLAGS? I have no idea if that's hard/possible to do with autoconf or not. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] Patch: Fix GetTag issue due to ref v.s. ptr change
GetTag has an issue because it checks whether found is NULL before
assigning to it, but now it's a reference, so that check doesn't make
sense, and this renders the found value invalid, which breaks a lot of
things. The attached patch fixes this.
? concordance/.concordance.c.swp
? concordance/.deps
? concordance/.libs
? concordance/Makefile
? concordance/Makefile.in
? concordance/aclocal.m4
? concordance/autom4te.cache
? concordance/concordance
? concordance/config.guess
? concordance/config.h
? concordance/config.h.in
? concordance/config.log
? concordance/config.status
? concordance/config.sub
? concordance/configure
? concordance/depcomp
? concordance/install-sh
? concordance/libtool
? concordance/ltmain.sh
? concordance/missing
? concordance/stamp-h1
? consnoop/USBLog2.txt
? consnoop/USBLog2.usblog
? consnoop/USBLog2.xml
? consnoop/USBLog3.txt
? consnoop/USBLog3.usblog
? consnoop/USBLog3.xml
? consnoop/consnoop
? consnoop/recovery.tbz2
? libconcord/.deps
? libconcord/.libconcord.cpp.swp
? libconcord/.libconcord.h.swp
? libconcord/.libs
? libconcord/.remote_info.h.swp
? libconcord/.web.cpp.swp
? libconcord/Makefile
? libconcord/Makefile.in
? libconcord/aclocal.m4
? libconcord/autom4te.cache
? libconcord/binaryfile.lo
? libconcord/config.guess
? libconcord/config.h
? libconcord/config.h.in
? libconcord/config.log
? libconcord/config.status
? libconcord/config.sub
? libconcord/configure
? libconcord/depcomp
? libconcord/install-sh
? libconcord/libconcord.la
? libconcord/libconcord.lo
? libconcord/libtool
? libconcord/libusbhid.lo
? libconcord/ltmain.sh
? libconcord/missing
? libconcord/remote.lo
? libconcord/remote_z.lo
? libconcord/stamp-h1
? libconcord/usblan.lo
? libconcord/web.lo
Index: libconcord/web.cpp
===
RCS file: /cvsroot/concordance/concordance/libconcord/web.cpp,v
retrieving revision 1.18
diff -u -p -r1.18 web.cpp
--- libconcord/web.cpp 29 Mar 2008 21:53:26 - 1.18
+++ libconcord/web.cpp 30 Mar 2008 04:29:39 -
@@ -183,9 +183,7 @@ int GetTag(const char *find, uint8_t* da
// Point past , at tag content
search += find_len + 1;
- if (found) {
-found = search;
- }
+ found = search;
/*
* If a string pointer was passed in, then add the
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Patch: Add size parameter to all non-firmware APIs
On Thu, March 27, 2008 11:03 pm, Phil Dibowitz wrote: Stephen Warren wrote: On Wed, March 26, 2008 11:55 pm, Phil Dibowitz wrote: Stephen Warren wrote: That was easy - I'd just accidentally included the hunk that fixed the C++ v.s. C comment at the end of libharmony.h, which you already committed separately, which caused the conflict. So, here's the updated version, attached. OK, some more comments. extract_firmware_binary() I thought the whole _point_ of this patch was to do this dynamically, but yet you're still assuming FIRMWARE_SIZE This change was just to fix all the APIs for data other than the firmware blob itself. A second pass could be made to fix up all the firmware related APIs. That can't be, because before my recent patch (i.e. when you first purposed this patch) the firmware API *only* returned a blob. And it returned a blob of FIRMWARE_SIZE and that's _specifically_ what you objected to. I objected to two separate length-related issues: 1) All the XML parsing use NULL-terminated blobs instead of an explicit length of the blob. 2) The firmware-related APIs didn't have a length parameter. From what I recall, you seemed OK fixing the first of these issues, pending review of the code for such a fix. As such, I worked up the patch I provided. For the second issue, you initially weren't sure the API should be changed, but then later agreed. So, I worked on the patch for issue 1 separately, because I started it first, and because it initially looked like we weren't going to address issue 2. My plan was to fix (1), then quickly work up the fix to (2) following that, to keep the amount of merge issues lower during development. verify_xml_config() You removed the size-check - why? It got moved into find_config_binary, since it's a common check for both functions. Hmm. I see. But we expect the user to call verify_xml_config() and then find_config_binary()... yet, in your code, verify_xml_config() calls find_config_binary _as_ _well_! This seems silly. Yes. I was tempted to simply remove one function or the other, and make a single uber-function that performed both the complete validation, and located the binary firmware. It's true such a function would seemingly do quite a lot, but it's probably easiest for an application to use. Are you OK with that? - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Patch: Add size parameter to all non-firmware APIs
Stephen Warren wrote: I'll commit to adding a size parameter to the firmware APIs too, within a day (probably less) of this being in CVS to diff against. Never mind; I have it done already. I'll follow up with the patch and comments/explanations in a few moment.s - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] Patch: Add size parameter to all non-firmware APIs
On Wed, March 26, 2008 11:55 pm, Phil Dibowitz wrote:
As I mentioned, I'd like the for(;;)s to be while(1)s.
Here you go; attached.
Index: concordance/concordance.c
===
RCS file: /cvsroot/concordance/concordance/concordance/concordance.c,v
retrieving revision 1.11
diff -u -p -r1.11 concordance.c
--- concordance/concordance.c 26 Mar 2008 01:33:31 - 1.11
+++ concordance/concordance.c 28 Mar 2008 03:08:36 -
@@ -157,7 +157,7 @@ int dump_config(struct options_t *option
return err;
}
- if ((err = write_config_to_file(config, file_name, size,
+ if ((err = write_config_to_file(config, size, file_name,
(*options).binary))) {
return err;
}
@@ -196,31 +196,23 @@ int upload_config(char *file_name, struc
uint8_t *data;
uint32_t size = 0;
- uint8_t *place_ptr;
- uint32_t binsize;
+ uint8_t *binary_data;
+ uint32_t binary_size;
read_config_from_file(file_name, data, size);
- place_ptr = data;
- binsize = size;
+ binary_data = data;
+ binary_size = size;
if (!(*options).binary) {
-
if ((err = verify_xml_config(data, size)))
return LC_ERROR;
- if ((err = find_config_binary_size(data, binsize)))
- return LC_ERROR;
-
- /* We no longer need size, let it get munged... */
- if ((err = find_config_binary_start(place_ptr, size)))
- return LC_ERROR;
-
- if (size binsize)
+ if ((err = find_config_binary(data, size, binary_data, binary_size)))
return LC_ERROR;
if (!(*options).noweb)
- post_preconfig(data);
+ post_preconfig(data, size);
}
/*
@@ -238,14 +230,14 @@ int upload_config(char *file_name, struc
* erase the flash (to 1) in order to write the flash.
*/
printf(Erasing Flash: );
- if ((err = erase_config(binsize, cb, (void *)0))) {
+ if ((err = erase_config(binary_size, cb, (void *)0))) {
delete_blob(data);
return err;
}
printf( done\n);
printf(Writing Config: );
- if ((err = write_config_to_remote(place_ptr, binsize, cb,
+ if ((err = write_config_to_remote(binary_data, binary_size, cb,
(void *)1))) {
delete_blob(data);
return err;
@@ -253,7 +245,7 @@ int upload_config(char *file_name, struc
printf( done\n);
printf(Verifying Config:);
- if ((err = verify_remote_config(place_ptr, binsize, cb, (void *)1))) {
+ if ((err = verify_remote_config(binary_data, binary_size, cb, (void *)1))) {
delete_blob(data);
return err;
}
@@ -261,7 +253,7 @@ int upload_config(char *file_name, struc
if (!(*options).binary !(*options).noweb) {
printf(Contacting website: );
- if ((err = post_postconfig(data))) {
+ if ((err = post_postconfig(data, size))) {
delete_blob(data);
return err;
}
@@ -297,6 +289,7 @@ int upload_firmware(char *file_name, str
{
int err;
uint8_t *firmware;
+ uint32_t firmware_size;
uint8_t *firmware_bin;
err = 0;
@@ -322,38 +315,48 @@ int upload_firmware(char *file_name, str
}
if ((err = read_firmware_from_file(file_name, firmware,
- (*options).binary))) {
+ firmware_size, (*options).binary))) {
delete_blob(firmware);
return err;
}
- if ((err = extract_firmware_binary(firmware, firmware_bin))) {
- delete_blob(firmware);
- delete_blob(firmware_bin);
- return err;
+ if ((*options).binary) {
+ firmware_bin = firmware;
+ } else {
+ if ((err = extract_firmware_binary(firmware, firmware_size, firmware_bin))) {
+ delete_blob(firmware_bin);
+ delete_blob(firmware);
+ return err;
+ }
}
if (!(*options).direct) {
if ((err = prep_firmware())) {
printf(Failed to prepare remote for FW update\n);
+ if (firmware_bin != firmware) {
+delete_blob(firmware_bin);
+ }
delete_blob(firmware);
- delete_blob(firmware_bin);
return err;
}
}
printf(Invalidating Flash: );
if ((err = invalidate_flash())) {
+ if (firmware_bin != firmware) {
+ delete_blob(firmware_bin);
+ }
delete_blob(firmware);
- delete_blob(firmware_bin);
return err;
}
printf( done\n);
printf(Erasing Flash: );
if ((err = erase_firmware((*options).direct, cb, (void *)0))) {
+ if (firmware_bin != firmware) {
+ delete_blob(firmware_bin);
+ }
delete_blob(firmware);
- delete_blob(firmware_bin);
return err;
}
printf( done\n);
@@ -361,13 +364,18 @@ int upload_firmware(char *file_name, str
printf(Writing firmware:);
if ((err = write_firmware_to_remote(firmware_bin, (*options).direct, cb,
cb_arg))) {
+ if (firmware_bin != firmware) {
+ delete_blob(firmware_bin);
+ }
delete_blob(firmware);
return err;
}
printf( done\n);
/* Done with this... */
- delete_blob(firmware_bin);
+ if (firmware_bin != firmware) {
+ delete_blob(firmware_bin);
+ }
if (!(*options).direct) {
if ((err = finish_firmware())) {
@@ -379,7 +387,7 @@ int upload_firmware(char *file_name, str
if (!(*options).binary !(*options).noweb) {
printf(Contacting website: );
- if ((err =
Re: [concordance-devel] Patch: Add size parameter to all non-firmware APIs
That was easy - I'd just accidentally included the hunk that fixed the
C++ v.s. C comment at the end of libharmony.h, which you already
committed separately, which caused the conflict.
So, here's the updated version, attached.
? libconcord/.libconcord.h.swp
Index: concordance/concordance.c
===
RCS file: /cvsroot/concordance/concordance/concordance/concordance.c,v
retrieving revision 1.11
diff -d -u -r1.11 concordance.c
--- concordance/concordance.c 26 Mar 2008 01:33:31 - 1.11
+++ concordance/concordance.c 27 Mar 2008 04:22:57 -
@@ -157,7 +157,7 @@
return err;
}
- if ((err = write_config_to_file(config, file_name, size,
+ if ((err = write_config_to_file(config, size, file_name,
(*options).binary))) {
return err;
}
@@ -196,31 +196,23 @@
uint8_t *data;
uint32_t size = 0;
- uint8_t *place_ptr;
- uint32_t binsize;
+ uint8_t *binary_data;
+ uint32_t binary_size;
read_config_from_file(file_name, data, size);
- place_ptr = data;
- binsize = size;
+ binary_data = data;
+ binary_size = size;
if (!(*options).binary) {
-
if ((err = verify_xml_config(data, size)))
return LC_ERROR;
- if ((err = find_config_binary_size(data, binsize)))
- return LC_ERROR;
-
- /* We no longer need size, let it get munged... */
- if ((err = find_config_binary_start(place_ptr, size)))
- return LC_ERROR;
-
- if (size binsize)
+ if ((err = find_config_binary(data, size, binary_data, binary_size)))
return LC_ERROR;
if (!(*options).noweb)
- post_preconfig(data);
+ post_preconfig(data, size);
}
/*
@@ -238,14 +230,14 @@
* erase the flash (to 1) in order to write the flash.
*/
printf(Erasing Flash: );
- if ((err = erase_config(binsize, cb, (void *)0))) {
+ if ((err = erase_config(binary_size, cb, (void *)0))) {
delete_blob(data);
return err;
}
printf( done\n);
printf(Writing Config: );
- if ((err = write_config_to_remote(place_ptr, binsize, cb,
+ if ((err = write_config_to_remote(binary_data, binary_size, cb,
(void *)1))) {
delete_blob(data);
return err;
@@ -253,7 +245,7 @@
printf( done\n);
printf(Verifying Config:);
- if ((err = verify_remote_config(place_ptr, binsize, cb, (void *)1))) {
+ if ((err = verify_remote_config(binary_data, binary_size, cb, (void *)1))) {
delete_blob(data);
return err;
}
@@ -261,7 +253,7 @@
if (!(*options).binary !(*options).noweb) {
printf(Contacting website: );
- if ((err = post_postconfig(data))) {
+ if ((err = post_postconfig(data, size))) {
delete_blob(data);
return err;
}
@@ -297,6 +289,7 @@
{
int err;
uint8_t *firmware;
+ uint32_t firmware_size;
uint8_t *firmware_bin;
err = 0;
@@ -322,38 +315,48 @@
}
if ((err = read_firmware_from_file(file_name, firmware,
- (*options).binary))) {
+ firmware_size, (*options).binary))) {
delete_blob(firmware);
return err;
}
- if ((err = extract_firmware_binary(firmware, firmware_bin))) {
- delete_blob(firmware);
- delete_blob(firmware_bin);
- return err;
+ if ((*options).binary) {
+ firmware_bin = firmware;
+ } else {
+ if ((err = extract_firmware_binary(firmware, firmware_size, firmware_bin))) {
+ delete_blob(firmware_bin);
+ delete_blob(firmware);
+ return err;
+ }
}
if (!(*options).direct) {
if ((err = prep_firmware())) {
printf(Failed to prepare remote for FW update\n);
+ if (firmware_bin != firmware) {
+delete_blob(firmware_bin);
+ }
delete_blob(firmware);
- delete_blob(firmware_bin);
return err;
}
}
printf(Invalidating Flash: );
if ((err = invalidate_flash())) {
+ if (firmware_bin != firmware) {
+ delete_blob(firmware_bin);
+ }
delete_blob(firmware);
- delete_blob(firmware_bin);
return err;
}
printf( done\n);
printf(Erasing Flash: );
if ((err = erase_firmware((*options).direct, cb, (void *)0))) {
+ if (firmware_bin != firmware) {
+ delete_blob(firmware_bin);
+ }
delete_blob(firmware);
- delete_blob(firmware_bin);
return err;
}
printf( done\n);
@@ -361,13 +364,18 @@
printf(Writing firmware:);
if ((err = write_firmware_to_remote(firmware_bin, (*options).direct, cb,
cb_arg))) {
+ if (firmware_bin != firmware) {
+ delete_blob(firmware_bin);
+ }
delete_blob(firmware);
return err;
}
printf( done\n);
/* Done with this... */
- delete_blob(firmware_bin);
+ if (firmware_bin != firmware) {
+ delete_blob(firmware_bin);
+ }
if (!(*options).direct) {
if ((err = finish_firmware())) {
@@ -379,7 +387,7 @@
if (!(*options).binary !(*options).noweb) {
printf(Contacting website: );
- if ((err = post_postfirmware(firmware))) {
+ if ((err = post_postfirmware(firmware, firmware_size))) {
delete_blob(firmware);
return err;
}
Index: libconcord/libconcord.cpp
===
RCS file:
Re: [concordance-devel] Windows harmony users...
On Fri, March 14, 2008 11:09 am, Phil Dibowitz wrote: Stephen Warren wrote: On Fri, March 14, 2008 2:23 am, Phil Dibowitz wrote: That said, it appears that variables declared not at the top was in fact not part of the c89 spec. But there was definitely pre-ANSI C. I'm annoyed that gcc doesn't get angry about that stuff. It really should. Ah well, I'll fix it up next time I have a few minutes, won't take long. I seem to recall gcc supported inline variable declarations as a gcc extension to non-c99 C. Using -ansi might not be enough to get it not to. Isn't there a -strict or -strict-ansi or -c89/90 flag that does that? Yeah - I mentioned it in a later email, -Wdeclaration-after-statement The problem is, that just generates a warning, which can easily be missed unless one really pays attention to build logs. I was thinking of an option to completely remove the concept of inline declarations from gcc's knowledge of syntax, thus forcing an error. It looks like the combination of -ansi -pedantic does that. However, enabling -pedantic might cause lots of build failures due to gcc being extremely picky... Unfortunately, I don't see any other option that seems to do this. I guess alternatively -Werror might do the trick, together with the -W you mentioned. That also has some potential for other negative fallout though. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
[concordance-devel] Firmware FF patterns replacements
The following is extracted purely from firmware files and USB logs, from both Kevin's zip and my upgrade attempts: remote, arch, fw version, d/l pattern, write pattern 550 9 2.2.3 8xFF 3a8d4847 628 7 3.04xFF 234d4847 659 7 4.14xFF ad8d4847 670 7 4.14xFF b4de4847 676 7 4.14xFF ee344847 688 7 3.04xFF b8244847 745 ? 1.0other Just *insert* 0x47 before? 748 3 1.94xFF e4e74847 768 3 1.94xFF 83074847 880 8 4.0.13 6xFF fb854847 880 8 4.4.2 6xFF d8f84847 890 10 4.2? 11ab4847 ? I haven't quite worked out the download format of this, but the USB logs I think I interpreted correctly... So, I guess the rules are: Bytes 0,1 == checksum/whatever-it-is Bytes x,x+1 == 0x48 0x47 Arch 3,7:x=2 Arch 8,9,10: x=4 745 is weird. Was that the first remote? 890 needs more investigation. Now, if only I could work out what the heck the checksum algorithm is (watch some Logitech employee be reading this and laughing at its simplicity:-) I wonder how hard reverse-engineering PIC assembly is. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
Re: [concordance-devel] My failing 880 firmware file
Phil Dibowitz wrote: Stephen - here's what I need, if you don't mind: upgrade to the latest firmware using the official software, then dump the firmware using our software (CVS latest, please), and send that file to me. Let me see the magic bits there, compared to the file, and I can compare that to *my* firmware's magic bits compared to my firmware file itself. If I can use your magic bits to make your file work, then I know I'm write and I just have to figure out how to generate the magic bits. If that doesn't work, I'm wrong, and I go look somewhere else. But I'm pretty sure I'm right. Emailed off-list. One thing I noticed; if I force the remote into safe-mode, it shows a couple values on the display: A.85FB B.09DE The 85FB value is bytes 1 and 2 (0-based) of the firmware dump. So, I guess that's a checksum of some kind. No idea what the other bytes are yet though. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
