Use upstream libsigrokdecode to avoid breakages

[fornellas]

I'm not sure the circunstances behind having forked libsigrokdecode into libsigrokdecode4DSL, but it is causing a lot of headaches:

• Original protocol decoders that "just worked" such as UART were substituted by 2 replacements, one which is broken and the other that removes the ability to see RX from TX (why?).
• Codebase here lags behind upstream and peolpe are trying to backport stuff as the fork lags behind and breaks things.
• Protocol decoders added here don't make upstream.
• Protocol decoders added upstream don't make it here.
• The interface of self.matched is broken
  • This breaks some decoders at libsigrokdecode4DSL.
  • This prevents any upstream decoders from working here (unless patched: Add libsigrokdecoder uart decoder #429).

I'm after using a simple UART decoder, to develop another decoder on top. What should be simple, is becoming a huge pain.

Can't we have libsigrokdecode used here? It can work fine as a Git submodule.

[abougouffa]

Totally agree! 👍🏼

[fornellas]

I did a "proof of concept" on how hard it'd be to make use of ustream libsigrokdecode it turns out it is somewhat simple: https://github.com/fornellas/DSView/tree/drop_libsigrokdecode4DSL.

It shouldn't be too hard fixing the problems below, though I'm not sure if there will be willingness to merge such PR by @DreamSourceLab, so I'm not gonna wrap this up for now.

[DreamSourceLab]

@fornellas
This is an important performance improvement, not destruction.
Take the following data file as an example.
uart.zip
On the same computer, it takes more than 620 seconds to parse this data file using pulseview's UART decoder, which occupies more than 3 gigabytes of memory.
For the same data, using DSView's 0: UART decoder, the parsing time is only 120 seconds, which is only 1 / 5 of the original, and the memory occupied is only more than 300 m, which is only 1 / 10 of the original.
There is no reason for us to abandon this better decoder implementation.

[fornellas]

@DreamSourceLab I believe your previous comment was miwed up with discussions from #427 and #429. Let's keep those discussions there.

This issue here is regarding the fact that DSView forked & patched Sigrok libraries (libsigrokdecode), in a way that's incompatible with Sigrok decoders. These changes created a phethora of issues, which made my life a LOT harder when attempting to develop for DSView.

As I poked around the code, it seems the changes were minimal, and potentially, something reversible, so we can use standard libsigrokdecode (and all current & future decoders there).

PS: not sure how I can import this uart.sr into DSView, as DSView seems to expect a .dsl...

[DreamSourceLab]

@fornellas
uart.sr file is prepared for pulseview, so you can test the result.
The following file is dsl with same data.
uart_dsl.zip

We have never declared any compatibility, the open source license allows any modification, not to mention the improvement of performance and user experience
We just want to give customers a better experience, not to struggle with compatibility with some APIs.

[fornellas]

We just want to give customers a better experience, not to struggle with compatibility with some APIs.

Unfortunately my experience was exactly the opposite: the incompatible API changes pushed, while 100% within what the license allows, created a much worse user experience for me. As DSView does not provide full in depth documentation for its decoder API interface, and I had to rely on Sigrok's, which caused all the confusion, due to the breaking changes. Also, there were bugs at DSView codebase resulting from API changes, that I followed as examples to my code, and were actually broken. It seem these have been fixed (self.matched changes).

By the end of the day, you can do whatever you prefer with DSView decoder API. My suggestion (and from various other users who thumbed up here) is to keep the API compatible with Sigrok. You can take it or leave it.